Monads as adjunctions

Question

I\'ve been reading about monads in category theory. One definition of monads uses a pair of adjoint functors. A monad is defined by a round-trip using those functors. Appare

Answer 1

If you are interested,here's some thoughts of a non-expert on the role of monads and adjunctions in programming languages:

First of all, there exists for a given monad T a unique adjunction to the Kleisli category of T. In Haskell,the use of monads is primarily confined to operations in this category (which is essentially a category of free algebras,no quotients). In fact, all one can do with a Haskell Monad is to compose some Kleisli morphisms of type a->T b through the use of do expressions, (>>=), etc., to create a new morphism. In this context, the role of monads is restricted to just the economy of notation.One exploits associativity of morphisms to be able to write (say) [0,1,2] instead of (Cons 0 (Cons 1 (Cons 2 Nil))), that is, you can write sequence as sequence, not as a tree.

Even the use of IO monads is non essential, for the current Haskell type system is powerful enough to realize data encapsulation (existential types).

This is my answer to your original question, but I'm curious what Haskell experts have to say about this.

On the other hand, as we have noted, there's also a 1-1 correspondence between monads and adjunctions to (T-)algebras. Adjoints, in MacLane's terms, are 'a way to express equivalences of categories.' In a typical setting of adjunctions :X->A where F is some sort of 'free algebra generator' and G a 'forgetful functor',the corresponding monad will (through the use of T-algebras) describe how (and when) the algebraic structure of A is constructed on the objects of X.

In the case of Hask and the list monad T, the structure which T introduces is that of monoid,and this can help us to establish properties (including the correctness) of code through algebraic methods that the theory of monoids provides. For example, the function foldr (*) e::[a]->a can readily be seen as an associative operation as long as is a monoid, a fact which could be exploited by the compiler to optimize the computation (e.g. by parallelism). Another application is to identify and classify 'recursion patterns' in functional programming using categorical methods in the hope to (partially) dispose of 'the goto of functional programming', Y (the arbitrary recursion combinator).

Apparently, this kind of applications is one of the primary motivations of the creators of Category Theory (MacLane, Eilenberg, etc.), namely, to establish natural equivalence of categories, and transfer a well-known method in one category to another (e.g. homological methods to topological spaces,algebraic methods to programming, etc.). Here, adjoints and monads are indispensable tools to exploit this connection of categories. (Incidentally, the notion of monads (and its dual, comonads) is so general that one can even go so far as to define 'cohomologies' of Haskell types.But I have not given a thought yet.)

As for non-determistic functions you mentioned, I have much less to say... But note that; if an adjunction :Hask->A for some category A defines the list monad T, there must be a unique 'comparison functor' K:A->MonHask (the category of monoids definable in Haskell), see CWM. This means, in effect, that your category of interest must be a category of monoids in some restricted form (e.g. it may lack some quotients but not free algebras) in order to define the list monad.

Finally,some remarks:

The binary tree functor I mentioned in my last posting easily generalizes to arbitrary data type T a1 .. an = T1 T11 .. T1m | .... Namely,any data type in Haskell naturally defines a monad (together with the corresponding category of algebras and the Kleisli category), which is just the result of any data constructor in Haskell being total. This is another reason why I consider Haskell's Monad class is not much more than a syntax sugar (which is pretty important in practice,of course).