[Haskell-cafe] Monad laws

[Alexander Solla]

> 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 <eir at cis.upenn.edu>
wrote:

> 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
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140625/e70c4afd/attachment-0001.html>