> In Haskell A could be an expression that produce a value and that value is used in expression B. In both cases A have to be "done" before B and you need to ke

> In Haskell A could be an expression that produce a value and that value is used in expression B. In both cases A have to be "done" before B and you need to keep this in mind while writing the code. Yes, and no. For example B(A(x)), haskell can call A(x), get result, then call B passing result as argument. Or it can call B, passing closure as argument, and when it comes to a point, when calculation of B cannot be continued if we do not know value of A(x) only then A(x) would be calculated. In some sense A(x) was done before B -- before B was finished, but from other hand calculation of A(x) was started after starting calculation of B. > My question was about "sequence of things to do", which is different concept than "imperative programming". I'm not sure, that I can see a difference, but nevertheless, in example above there is not sequence of operations. There is almost declarative definition of a quicksorted list. There are multiple ways to linearize it into sequence of operations and even if there was single way I don't mind. It is the task of a compilator to make this linearization, not mine.