[Haskell-cafe] Monad laws

[Richard Eisenberg]

On Jun 25, 2014, at 12:52 AM, John Lato <jwlato at gmail.com> wrote:

> 
> The compiler makes assumptions about associativity when de-sugaring do-notation.  If the monad laws aren't followed, it's possible for these two blocks to show different behavior (given that a,b,c are all values of the misbehaved Monad instance):
> 
> > do { a; b; c }
> 
> > a >> b >> c
> 
> I think everyone can agree that this is surprising, at the very least.  Although it's not the compiler that's generating bad code here.

As far as I know, GHC makes no assumptions about associativity, or any class-based laws. The effect John observes above is accurate, but it is a direct consequence of the design of Haskell in the Haskell 2010 Report, not any assumptions in the compiler.

Specifically, Section 3.14 (https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.14) says that `do { e; stmts }` desugars to `e >> do {stmts}`. In the case of `do { a; b; c }`, that means we get `a >> (b >> c)`. However, in Table 4.1 in Section 4.4.2 (under https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-800004.4), we see that (>>) is *left*-associative, meaning that `a >> b >> c` means `(a >> b) >> c`.

Are the different meanings here an "assumption" of associativity? I suppose one could construe it that way, but I just see `do { a; b; c}` and `a >> b >> c` as different chunks of code with different meanings. If the monad in question upholds the associativity law, then the chunks evaluate to the same result, but they're still distinct.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140625/4f8ec2ba/attachment.html>