On 11/08/07, Ronald Guida < ronguida@mindspring.com> wrote:

Here's my interpretation of the table:

----------------------------------------------------------------------
Structure   | Subject  |  Action    |  Verb      |  Result
------------+----------+------------+------------+----------
function    |  a       |  a->b      |  flip ($)  |  b
Functor     |  f a     |  a->b      |  <$>       |  f b
Applicative |  f a     |  f (a->b)  |  flip <*>  |  f b
Monad       |  m a     |  a->m b    |  >>=       |  m b
Comonad     |  w a     |  w a->b    |  =>>       |  w b
Arrow       |  a b c   |  a c d     |  >>>       |  a b d
----------------------------------------------------------------------


Nice

Kim-Ee Yeoh wrote:
> ... I think you'll find that each of those structures have their
> privileged place in your code.

Agreed.  I'm still a beginner; I'm not sure how to choose one
structure over another, at least not yet.  But that's because ...

> Monads are undoubtedly more pervasive, and that could be because there
> aren't as many arrow and comonad tutorials, atomic ones or otherwise.

And I'm trying to say that these shouldn't be separate tutorials at all - its
much more instructive to compare and contrast.
 

Moreover, Comonad isn't even in the standard libraries (Hoogle returns
no results for it).

When I searched for tutorials on monads, I found lots of them.  In
fact, I have heard that writing (yet another) monad tutorial is part
of standard Haskell initiation.


Thats what I was doing above :-)

....


One thing that I keep seeing people say (not you), is that monads /sequence/ side effects. This is wrong, or at
least a limited picture.

/All/ of the above structures are about combining compatible things things together in a row.
/None/ of them force any particular order of evaluation - that all comes from the particular instance. So its
only a particular feature of IO that it sequences the side effects. Others don't - we can have a lazy State
monad that just builds up big thunks.

IO could be implemented as any of the above structures, and still be perfectly able to keep
things in order. Indeed, uniqueness types as in clean, are arguably just the first one - function composition

functor IO would be really boring - we could just perform a sequence of actions with no choices at all.
(But the whole sequence could be repeated, and I guess the Structure could be nested for fixed loops)

The key to the choice of IO as a Monad comes back the the argument about 'simplicity' or what ever we
want to call it - I agree its rather context dependent, and indeed I was rather flippant at the end of my first message

But lets look at the nature of the actual things being sequenced, the actions above.

In only 3 cases are the actions simple enough to take a single /a/ argument.
Function a->b; Functor a->b;  Monad a->m b

In function and functor, the action takes no part in the complexity, doesn't know about it.
In function application the action gets used (possibly) once, in functor and monad possibly many times.
Only in Monad does the action have a say in the complexity, by returning an possibly non-trivial m b.

So thats the reason Monads are so handy - the combined actions are simple, but they can
at least participate - influence the flow of control if we are talking about a IO-like Monad.

Also, arrows are supposed to be more general than both monads and
comonads.  If I could just figure out what each structure (functor,
monad, comonad, arrow) is doing, and compare and contrast them, then I
probably will have made leaps of understanding.  I have a sense that
tells me that the table above and the data structures below probably
start to scratch the surface of understanding.

----------------------------------------------------------------------


Arrows are most general because they have full access to the complexity going on in the
structure. Each arrow can do arbitrarily complex (possibly bidirectional) negotiation with its
input, and possibly asynchronously arbitrarily complex negotiation with its output. Any sort of
data can flow any way at any time, the only restriction is that for an 'Arrow a b' object, the
input side uses a's and the output b's.

Compare a monad - the input must be single, simple a's. All that can happen is that the function gets called multiple times.

--
Brian_Brunswick____brian@ithil.org ____Wit____Disclaimer____!Shortsig_rules!