I'm the one responsible for adding the Monad laws to the Haskell
report - so perhaps I should explain why I wanted to add them.

The main reason I wanted to add them was so that I could (informally)
appeal to them when documenting code or optimising code.  For example, 
the Monad library documentation says this

  The when and unless functions provide conditional execution of monadic
  expressions. For example,

    when debug (putStr "Debugging\n")

  will output the string "Debugging\n" if the Boolean value debug is
  True, and otherwise do nothing.

But this wouldn't be true for just any Monad instance - only those
where "return ()" "does nothing".  That is, for which:

  m >> return () = m

Lesser motivations include:

o library programmers might like to use the monad laws in justifying the
  correctness of their program or the justifying the correctness of an
  optimisation.

o both forms of monad syntax (do and comprehensions) encourage you to
  think of (>>) as an associative operator.

o a Haskell compiler might want to use the laws to optimise monadic
  code.  I don't know of anyone doing this at the moment - but
  it could certainly be useful if combined with a little inlining
  and, perhaps, some laws about the primitives in certain built-in
  monads (eg writeVar v x >> writeVar v y = writeVar v y)


I think the report should give a complete list of laws (with any 
appropriate corrections).  

It would be possible to merely list the monad laws but not require
that all instances satisfy them.  The immediate effect of such a
change would be to require the addition of some sort disclaimer to the
documentation for all monad-related code.  The disclaimer would say
that the documentation assumes that the monad laws hold and that
you'll need to examine the code itself if the laws don't hold for some
monad instance.

It would be nice to give laws for all the standard classes.  The
problem is that the numeric instances satisfy very few laws (eg "+" is
not commutative and not associative for most numeric types found on
real machines).  For monads, things seem much simpler.

--
Alastair Reid              Yale Haskell Project Hacker
[EMAIL PROTECTED]  http://WWW.CS.Yale.EDU/homes/reid-alastair/










Reply via email to