Am Montag, 11. Februar 2008 14:57 schrieb Michael Reid:
Now it should be easier to see that this is simply associativity. It's easy enough to violate, if you want to - but I don't have any nice simple examples to hand.
I have recently been reading a tutorial or paper where a Monad that violated this law was presented. The authors shrugged it off as not important, that the notation gained by implementing the operation as a Monad was worth it, but what is not clear is what the consequences of violating such associativity are.
Does violating this law introduce the potential that your program will not do what you think it should?
/mike.
Other libraries might (and probably will) expect Monad instances to satisfy the monad laws and will not work as intended or even make sense if the monad laws aren’t satisfied. Sometimes it looks as if people think that monads are special in that they have to satisfy certain laws. But this isn’t the case. Practically every Haskell type class has some laws (informally) attached to it which instances should satisfy. For example, the following should hold for instances of the Ord class: a < b = compare a b = LT a == b = compare a b = EQ a > b = compare a b = GT a <= b = a < b || a == b a >= b = a > b || a == b a < b = b > a a < b && b < c => a < c If an Ord instances doesn’t obey these laws than it’s likely to make Set and Map behave strangely. Best wishes, Wolfgang