RE [Haskell-cafe] Monad Description For Imperative

[ok]

I wrote:
But please, let's keep one foot in the real world if possible.
Monads were invented to solve the "how do I do imperative programming
in a pure functional language" problem.

On 2 Aug 2007, at 7:05 pm, Greg Meredith wrote:
> This is more than a little revisionist. Monads have been the  
> subject of mathematical study before people had an inkling that  
> they might apply to problems in computer science. Moggi didn't  
> invent them, but noticed that they might have an application to  
> issues of composition in computation. It is really intriguing that  
> they do such a remarkable job of organizing notions of update and  
> were not invented with this application in mind. So, revising  
> history thus would be a real loss.

I apologise for the unclarity of what I wrote.
I should have said something like "Monads-in-computing were adopted  
to solve..."

It is considerably more than a little revisionist to identify Haskell
monads with Category Theory monads.

Quoting the Wikipedia article on monads:

   "If F and G are a pair of adjoint functors, with F left adjoint to G,
    then the composition G o F will be a monad.
    Note that therefore a monad is a functor from a category to itself;
    and that if F and G were actually inverses as functors the  
corresponding
    monad would be the identity functor."

So a category theory monad is a functor from some category to itself.
How is IO a a functor?  Which category does it operate on?  What does it
do to the points of that category?  What does it do to the arrows?

Let's turn to the formal definition:

   "If C is a category, a monad on C consists of a functor T : C → C
    together with two natural transformations: η : 1 → T (where 1
    denotes the identity functor on C) and μ : T2 → T (where T2 is
    the functor T o T from C to C). These are required to fulfill
    [some] axioms:"

What are the natural transformations for the IO monad?  I suppose there
is a vague parallel to return and >>=, but that's about all you can  
claim
for it.

If we are not to be revisionist, then we must admit that Haskell monads
were *inspired* by category theory monads, but went through a couple of
rounds of change of notation before becoming the Monad class we know and
love today.  What we have *was* invented for functional programming and
its category theory roots are not only useless to most programmers but
quite unintelligible.  We cannot (and I do not) expect our students to
*care* about monads because of their inspiration in category theory but
because they WORK for a problem that had been plaguing the functional
programming community for a long time.

This is why I say you must consider your audience.  One of the unusual
things about Haskell is the strength and breadth of its links to theory
and the number of people who are *interested* in that theory as an aid
to finding ways to make new kinds of programming thinkable.  I don't
suppose we'd have had Arrows without this kind of background.  But few
students in most Computer Science departments take category theory,
and those people need monads explained in terms they will be able to
understand and to grasp the *practical* significance of.  Once they
catch the Haskell "spirit" they may well become interested in the  
theory,
but that stuff doesn't belong in tutorials.