Re: [Haskell-cafe] Monad laws

If the monad in question upholds the associativity law, then the chunks evaluate to the same result, but they're still distinct.

Distinct with respect to what equivalence relation? Also, an object isn't a monad if it isn't associative. On Wed, Jun 25, 2014 at 11:14 AM, Richard Eisenberg wrote:

On Jun 25, 2014, at 12:52 AM, John Lato 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.1...) 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....), 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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe