>Hans Aberg included in his mail:
>> class Monad m where
>> map :: (a -> b) -> (f a -> f b) -- Functor
>> return :: a -> m a -- Unit
>> (>>=) :: m a -> (a -> m b) -> m b -- Kleisli multiplication
>> or join :: m(m a) -> m a -- Monoid multiplication
>> -- Some axioms are missing here.
>
>I'm really worried about whether ordinary mortals (or at any rate
>programmers) will not be put off by these terms. (Not your fault Hans).
>It's all very well for mathematicians. Do we have to be mathematicians to
>make use of monoidal programming ideas?
Monads are indeed difficult to understand, but strengthening the logical
model makes it easier to program with it, as it does not put the burden on
the programmer on make sure, by hand, that the logical structure is correct
in each instance. And if the information that comes with a written monad is
more exact, it also helps the user of that written monad.
The join is in fact easier to describe the monad in some cases. (An even
easier way, is in terms of the monad algebra morphisms, see MacLane's book,
p135, ch 6.2.)
There are theoretical reasons, too: Monads (seem to) solve a certain
general type of code extension problem, but this is only true if the
implemented monads are close to the category theoretical ones.
Hans Aberg
