[Haskell-cafe] Monad laws
Richard Eisenberg
eir at cis.upenn.edu
Wed Jun 25 18:14:04 UTC 2014
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>
More information about the Haskell-Cafe
mailing list