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.