<span style="font-family: courier new,monospace;">On 11/08/07, </span><b style="font-family: courier new,monospace;" class="gmail_sendername">Ronald Guida</b><span style="font-family: courier new,monospace;"> <<a href="mailto:ronguida@mindspring.com">
ronguida@mindspring.com</a>> wrote:</span><div style="font-family: courier new,monospace;"><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Here's my interpretation of the table:<br><br>----------------------------------------------------------------------<br> Structure | Subject | Action | Verb | Result<br> ------------+----------+------------+------------+----------
<br> function | a | a->b | flip ($) | b<br> Functor | f a | a->b | <$> | f b<br> Applicative | f a | f (a->b) | flip <*> | f b<br> Monad | m a | a->m b | >>= | m b
<br> Comonad | w a | w a->b | =>> | w b<br> Arrow | a b c | a c d | >>> | a b d<br>----------------------------------------------------------------------</blockquote>
<div><br><br>Nice <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Kim-Ee Yeoh wrote:<br> > ... I think you'll find that each of those structures have their
<br> > privileged place in your code.<br><br>Agreed. I'm still a beginner; I'm not sure how to choose one<br>structure over another, at least not yet. But that's because ...<br><br> > Monads are undoubtedly more pervasive, and that could be because there
<br> > aren't as many arrow and comonad tutorials, atomic ones or otherwise.</blockquote><div><br>And I'm trying to say that these shouldn't be separate tutorials at all - its<br>much more instructive to compare and contrast.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Moreover, Comonad isn't even in the standard libraries (Hoogle returns<br>
no results for it).<br><br>When I searched for tutorials on monads, I found lots of them. In<br>fact, I have heard that writing (yet another) monad tutorial is part<br>of standard Haskell initiation.</blockquote><div><br>
<br>Thats what I was doing above :-)<br><br>.... <br></div><br><br></div>One thing that I keep seeing people say (not you), is that monads /sequence/ side effects. This is wrong, or at<br>least a limited picture.<br><br>/All/ of the above structures are about combining compatible things things together in a row.
<br>/None/ of them force any particular order of evaluation - that all comes from the particular instance. So its<br>only a particular feature of IO that it sequences the side effects. Others don't - we can have a lazy State
<br>monad that just builds up big thunks.<br><br>IO could be implemented as any of the above structures, and still be perfectly able to keep<br>things in order. Indeed, uniqueness types as in clean, are arguably just the first one - function composition
<br><br>functor IO would be really boring - we could just perform a sequence of actions with no choices at all.<br>(But the whole sequence could be repeated, and I guess the Structure could be nested for fixed loops)<br><br>
The key to the choice of IO as a Monad comes back the the argument about 'simplicity' or what ever we<br>want to call it - I agree its rather context dependent, and indeed I was rather flippant at the end of my first message
<br><br>But lets look at the nature of the actual things being sequenced, the actions above.<br><br>In only 3 cases are the actions simple enough to take a single /a/ argument.<br>Function a->b; Functor a->b; Monad a->m b
<br><br>In function and functor, the action takes no part in the complexity, doesn't know about it.<br>In function application the action gets used (possibly) once, in functor and monad possibly many times.<br>Only in Monad does the action have a say in the complexity, by returning an possibly non-trivial m b.
<br><br>So thats the reason Monads are so handy - the combined actions are simple, but they can<br>at least participate - influence the flow of control if we are talking about a IO-like Monad.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, arrows are supposed to be more general than both monads and<br>comonads. If I could just figure out what each structure (functor,<br>monad, comonad, arrow) is doing, and compare and contrast them, then I<br>probably will have made leaps of understanding. I have a sense that
<br>tells me that the table above and the data structures below probably<br>start to scratch the surface of understanding.<br><br>----------------------------------------------------------------------<br><br>
</blockquote><br>Arrows are most general because they have full access to the complexity going on in the<br>structure. Each arrow can do arbitrarily complex (possibly bidirectional) negotiation with its<br>input, and possibly asynchronously arbitrarily complex negotiation with its output. Any sort of
<br>data can flow any way at any time, the only restriction is that for an 'Arrow a b' object, the<br>input side uses a's and the output b's.<br><br>Compare a monad - the input must be single, simple a's. All that can happen is that the function gets called multiple times.
<br><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">-- </span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">Brian_Brunswick____brian@ithil.org
____Wit____Disclaimer____!Shortsig_rules!
</span>