A futures library solves the case where, in an imperative programming language, the programmer writes a block to compute A, a block to compute B, then combines

A futures library solves the case where, in an imperative programming language, the programmer writes a block to compute A, a block to compute B, then combines A and B. Pure FP works fine in that case, since writing (+ (compute-A) (compute-B)) does the same ordering. It seems to me pure FP is fine unless computations for A and B have interdependencies, which would result in duplicate computation in pure FP unless you can refactor to a different algorithm. I'm not sure I understand what you mean by wanting to control ordering at a "the individual functional level", unless you mean interdependencies between computations done in "monolithic units". A->(loop B until done)->C A->(loop D until done)->E C-\ +-> F E-/ Something like that. Am I one the right track? No, because I can still express that in pure FP: (let [(A (compute-A))] (let [(C (compute-C A) (E (compute-E A)] (compute-F C E))) Trying again ... A->(loop B until (valid B D))->C A->(loop D until (valid D B))->E C-\ +-> F E-/ Is that better? Care to help me understand what you're getting at?