At 20:50 97/05/08, Koen Claessen wrote:
>.. Just as Functor
>is theoretically a superclass of Monad.
I do not there is any theoretical reason forcing you to implement the
monad functor part as a class derivation, because the relation between
class derivation and logical property inheritance is weak. (Etc.)
But, regardless how you want to implement it, I think a strengthening of
the monad definition should end up (from the logical point of view) with
something like:
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.
The ideal would be if you could choose which Monad multiplication variation
you want to define, and get the other one automatically instantiated: As
Koen Claessen points out, this only works, if you also have the functor
property with the monad. (It is also crucial that the unit and
multiplications are natural transformations, that is, acting on morphisms
yield commutative diagrams.)
Further, I was able to translate some of the Haskell example monads into
(mathematical) category theory. Then, this mathematical model acts an
interface relative the computer implementation, so that for example
different styles of exceptions (Haskell or C++) will have the same monad. I
find this pretty interesting.
So, without going into much of the details, it looks as though closing in
on the categorical monad concept is purely an advantage from the
theoretical point of view. If you have found some stripped down monads
practically useful, these could be called something else, pre-monads,
semi-monads, semids, or something. (A step beyond this, might be to
introduce a concept of a category in Haskell.)
Hans Aberg
