🚀 go-pugleaf

In article <1992Dec15.173324@aifh.ed.ac.uk> williamc@aifh.ed.ac.uk
(William Chesters) asks:

| What is a monad?

Well, since I'm responsible for starting the conversations about monads in
recent posts, I guess I'd better give you a reply!

The concept of a monad comes from category theory; I'll spare you the
full details since you can find these in standard text books on the
subject.  Much of the recent interest in monads in functional programming
is the result of a couple of papers written by Philip Wadler which show
how monads can be used to describe all kinds of different programming
language features -- for example, I/O, manipulation of state, continuations
and exceptions -- in a purely functional language like Haskell.

Here's a brief summary of how this looks in Haskell.  A monad is given by
a unary type constructor M and two operations:
    unitM :: a -> M a
    bindM :: M a -> (a -> M b) -> M b
One simple way to understand what is going on here is to think of M a as
a type of computations that return values of type a.  With this in mind,
an expression of the form  unitM e  behaves like a trivial computation which
just returns e.  An expression  m `bindM` f  represents a computation which
runs the computation m, takes the result and passes that as an argument
to f.  Every monad has unit and bind operators.  The thing that makes
individual monads more interesting is the additional structure that they
provide.  For example, the ability to update a state or to generate an
exception.

You'll find all of this is better explained in the papers that I mentioned
above:

 o Phil Wadler, Comprehending Monads (from the ACM conference on LISP &
   functional programming, Nice, France, 1990),

 o Phil Wadler, The Essence of Functional Programming (from ACM POPL 1992).

To try and explain how this relates to my earlier message, I'm currently
working with an extended form of overloading.  This doesn't really have
anything to do with monads, except that this approach to overloading turns
out to be particularly convenient for programming with monads.

The following definitions are a simplified version of the way that monads
(and functors) are defined in the prelude for my system.  If you are familiar
with the use of type classes in Haskell, you should be able to follow what
is going on here, except that whereas a type class corresponds to a set of
types, the following declarations correspond more closely to sets of type
constructors:

    class Functor f where
        map :: (a -> b) -> (f a -> f b)

    class Functor m => Monad m where
        return    :: a -> m a
        bind      :: m a -> (a -> m b) -> m b

(I happened to be using the name `unit' for something else, so I use the
name `return' here instead of `unit' as I did above (and as Phil does in
his papers)).

Hope this helps,
Mark