Brian Brunswick wrote:
g f ??? g ??? f
application a a->b flip ($) b monad bind m a a->m b >>= m b comonad cobind w a w a->b =>> w b arrow arr a b arr b c >>> arr a c
Kim-Ee Yeoh wrote:
Fmap's missing: m a, a->b, flip fmap, m b. You might want to throw in Applicative there too: m a, m (a->b), flip (<*>), m b.
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 ---------------------------------------------------------------------- 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.
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. In my case, I have started to formulate my own idea for what a monad tutorial should be; I might attempt to write one, too. I read several monad tutorials, but I could not understand them at first. Monad transformers are even worse. I had to sit, *think*, draw diagrams, *think* some more, review several advanced tutorials, and *think* even more. I also looked up comonads, arrows, and category theory. Finally, monads (and monad transformers) started to make sense for me. I still don't understand monads just yet; but that's because my self-test for understanding something is whether I feel I could explain it to someone else and have it make sense. I suppose that in order to understand monads, I need to actually *use* some monads, and see them in action on something real (like an actual algorithm) that I can relate to. Learning feels like climbing a mountain; much time and hard work is spent on the ascent, but new understanding is achieved in the process. Once I reach the top of the mountain, the question is how to make the mountain easier to climb for the next person. My thinking is that the ultimate goal is to /invert/ the mountain, such that the people can /ride/ the mountain (which still requires some work) and gain new understanding in the process. What I obtain on the way up the mountain, future people would obtain, far more efficiently, on the way /down/ the (inverted) mountain. What I would like to see in a monad tutorial are some good real-use examples that demonstrate /just/ monads. I found it extremely helpful to see an example of monads being used to compute probabilities and drug test false-alarm rates. This application seemed to used /just/ monads, without a lot of extra programming complexity on top, and it provided a "real" example. This is the sort of thing, combined with the background of "what is a monad", that I think would make a really good tutorial. The "monadic lovers" story, in my opinion, provides an example that's too contrived and simplistic. On the other extreme, I found an example of arrows being used in a digital circuit simulator. As a tutorial on arrows, I would find this too complex because there is too much "stuff" built up on top of the arrows. The concept of an arrow is lost in the complexity of "special" classes like the ArrowCircuit class that was actually used to simulate a circuit. (Note: The circuit used in the example was trivial, moreover my background is electrical engineering with a focus on digital circuits.) I found an example of a comonad being used to simulate a cellular automaton; I found this example helpful, although it might be a little too complex. I think that what would make a truly great tutorial would be a tutorial (or a series of tutorials) that starts with a "real" area of exploration and proceeds to incrementally develop programs. Each increment would incorporate a new "bite" from the area of exploration, which would cause an increase in complexity. As the programs get complicated, the monad (or comonad, or arrow) is introduced by factoring the appropriate pattern out the code and then simplifying. The tutorial might (1) state the monad laws and say "this is what defines a monad", (2) say something like "let's look for this pattern in the code" and find the pattern very easily because the example would be designed to make the pattern fairly obvious, and (3) define a special monad and use it to simplify the code. If I think of something, I'll attempt to write it up and see what happens. Brian Brunswick wrote:
The full title of this is really 'Explaining monads by comparison with comonads and arrows' ...
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. ---------------------------------------------------------------------- Foo a = Foo { runFoo :: a } -- Functor State s a = State { runState :: s -> (a, s) } -- Monad Context c a = Context { runContext :: (a, c) -> a } -- Comonad Thing s a b = Thing { runThing :: (a, s) -> (b, s) } -- Arrow??? ---------------------------------------------------------------------- An exceptional tutorial (it would probably have to be a series) would use a "real" area of exploration and introduce all four structures by incrementally developing programs (in the area of exploration) at just the right level of program complexity for each structure to make sense and fit into its surroundings without being either too simple or too complicated. If (or when) I ever make that leap of understanding, I might make an attempt to write that tutorial. Until then, I guess I'm still climbing the mountain now, hoping I'll get to ride the mountain later. -- Ron