3 ms·

My question was about "sequence of things to do", which is different concept than "imperative programming". Sequence means A should happen before B and this is

My question was about "sequence of things to do", which is different concept than "imperative programming". Sequence means A should happen before B and this is something that you will have to keep in mind and then encode in the target language. For example: in C language A could be a statement that modify some data and B could be another statement that uses the updated data. 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. As far as imperative vs functional goes: Remove the assignment operator from an imperative language and you will end up with functional language without bell and whistles (then you will have to make conditionals as expressions and instead of loops you will need to use recursion).

ordu 8y ago
> 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.

ordu 8y ago

> 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.