Evaluation order of side effect within let bindings

[finnteegen]

I wondered if there is any way to guarantee an evaluation order of side effects within let bindings in an expression like [let {i = 1; _ = putStrLn "Name?"; name = getLine } in name]. Currently, the getLine is executed before the putStrLn (which was not what I intended ^^).

[Ziharrk]

At the moment, the plugin re-orders let-expressions. This is sometimes required, as can be seen by the following example:

test :: ()
test = let x = print i
               i = (let _ = putStrLn "i" in 1)
          in x

What would you expect for the effect order here?

For simpler cases however, we could make sure that the effect order is top to bottom.
However, that requires a little bit of work.

[finnteegen]

My example originated from the list comprehension example (where the order is hopefully left-to-right as soon as list comprehensions work). Having top-to-bottom for some cases and for others not seems not better to me. I wonder what is the right way to sequence computations then? Singleton let expressions?

[Ziharrk]

In List comprehensions, at least each let would be its own statement. So it should work left-to-right (except for the fact that ListCompr don't work at all :P).
Sequencing with single-lets would work, but seems a bit tedious.
Maybe we should use top-to-bottom for let whenever possible and emit an error if reordering took place.

[finnteegen]

As long as there is a possiblity to enforce a certain evaluation order, perhaps we do not need to put extra effort into this matter. Also, I do not know how a transformation of let expressions to achieve a certain order of evaluation would effect other Language-Plugins. Since we want a somehow genera approach, it seems sufficient for me to be able to use single-lets (at least I could live with it). We already state that we do have to make sacrifices regarding the syntax. ;)

[Ziharrk]

We decided to forbid a user from writing let-expressions with either

• (conservative approach) multiple bindings
• (user-friendly approach) multiple bindings that were re-ordered due to dependencies between those bindings