Michael Hobbs writes:
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...
I agree, and (not to speak for John Hughes, but I will anyway) I
suspect John would as well. The arrows are, in some sense, "more
basic" and therefore more powerful. A monad combines concepts that
arrows take apart, so where they can be usefully combined we should
keep on using monads. Where they cannot --- where we need to take
explicit notice of input types for one reason or another --- then the
arrows are a useful alternative.
One of the nice things about the paper is that there is no (or little)
penalty for beginning with monads and moving to arrows if we have to.
This is because any monad is also an arrow (see John's definitions)
and, where needed, we can make any set of arrows for which choice and
apply are defined into monads. Thus, if we started using combinators
that are defined with monads and move to those defined with arrows,
the user code does not change (the definition code has to, of
course).
This breaks down when the type of the combinator changes: check out
Swierstra and Duponcheel's type for <*> versus that usually used.
This is a radical change, and a lot of the parser expressions would
have to be recalculated. But the arrows can help us avoid this in
some cases, or at least to reduce the change to a global regular
expression search and replace.
Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.averstar.com/~dlb
