David Barton wrote:
> Hmmm. *If* you believe that monads are a useful construct, and
> understand them to an extent, then it is not clear to me why you would
> have that much difficulty here. (Sorry, that came out as very
> negative --- I just mean that the concepts are so similar that an
> understanding of one would seem to me to carry over fairly easily to
> an understanding of the other. I meant no disparagement.)
No disparagement taken. :) I guess I don't have any real problem with
the whole concept. <some handwaving to signify the abstractness of the
"concept"> But for me, personally, the devil was in the details.
It could be my lack of profound comfort with first class functions. I
have no real problem with them at their basic level, such as passing in
a function to 'map' or 'fold*'. But when routines start passing around
partially evaluated curried functions, my brain starts to melt when it
tries to figure out what the "value" of the variable is.
The point in the paper that really got my goat was the definition of
'eval' on page 15. The arrow definition was passing around partially
evaluated functions in the most casual way and I was performing mental
acrobatics in order to keep up with what exactly was going on there.
Then, when the next line reads, "the arrow code is by no means more
awkward than the monadic code," I thought to myself, "You CAN'T be
serious!"
Yes, I can see how the arrow paradigm would work very well for things
such as parsing LL(1) grammars, but I could not see how such a scheme
could become a _replacement_ for monads in general purpose programming.
Perhaps I was expecting the wrong thing from the concept...
- Michael Hobbs
