Hacker News Reader

Comment by thirsteh | Hacker News Reader

It's not. Please check out Edward Kmett's comments:

http://blog.jorgenschaefer.de/2013/01/monads-for-normal-prog...

Edward talks about the monad laws, especially the associativity one. But that is kind of simplistic, because the domain over which the laws apply can be shaped quite complexly, leading, for example, to IO or State being "monads". I fail to see how the associativity law is very useful in reasoning about IO / State. All I can see is that, syntactically, the parse tree (a; b;) c; executes the same as a; (b; c;) under a left-most evaulation rule.

Associativity is very important in the case of IO. It guarantees that both

  (print a; print b;)print c;

and

  print a; (print b; print c;)

output abc.

Duh, blocks are evaluated in leftmost order. This is neither news, nor particularly profound in any number of popular curly brace languages. Rewritten with curly braces, so it's recognizable by most Blub programmers out there:

    { { print a; print b; } print c; }
    { print a; { print b; print c; } }

The distinction is not important in an eagerly evaluating language, which steps through its statements one by one and executes them as it finds them.

In a lazy, pure language it is of very great importance! With lazy evaluation you get no guarantees as to what order your expressions are evaluated in. Statements like "Blocks are evaluated in leftmost order" are just false in Haskell.

Monads give you the ability to sequence your I/O actions even though they are still lazily evaluated. This is why Haskell needs monads, and most other languages get by without them.

Another way to think of it is that monads are embedded into the operational semantics of eager languages, so you that the programmer doesn't need to be aware of them. After all, monads were initially used to formally describe the behaviour of ML, an eager language, before they were used in Haskell.

Reply on news.ycombinator.com