Philip Wadler wrote:
| 1. zero >>= k = zero
| 2. m >>= \x -> zero = zero
| 3. (m ++ n) >>= k = m >>= k ++ n >>= k
| 4. m >>= \x -> k x ++ h x = m >>= k ++ n >>= k.
|
| But the fourth law does not hold for lists, and the second law does
| not hold if we consider the case where m is bottom.
This has two implications: The Haskell report specifies a law that does
not always hold (namely law 2), and there is a law that holds, but is not
in the Haskell report (namely law 3).
I argue for completely removing law 2, because of its strong analogy with
law 4, which indeed clearly doesn't always have to hold. Law 1 and law 3
should hold, and should therefore be both in the report.
This means that the IO monad can have a "proper" zero now.
Maybe it is silly to argue about such theoretical things (we are not even
talking about changing the language implementation or the libraries!), but
maybe it is also silly to require all these laws to hold for future
functions defined by users. Maybe they should come as a suggestion.
... or does specifying the Monad Laws in the report mean that compilers
can use them to transform monadic programs? Even if the programmer
specified a "monad" for which these laws don't hold?
Regards,
Koen.
--
| Koen Claessen, [EMAIL PROTECTED] |
| http://www.cse.ogi.edu/~kcclaess/ |
|------------------------------------------------------|
| Visiting student at OGI, Portland, Oregon, USA. |
