Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell
XML Toolbox Version 9.0.0
gcross at phys.washington.edu
Tue Oct 12 17:01:27 EDT 2010
On 10/12/10 1:22 PM, Dan Doel wrote:
> On Tuesday 12 October 2010 4:02:06 pm Gregory Crosswhite wrote:
>> Hughes himself said that when your arrow is an instance of ArrowApply,
>> you are better off just sticking with monads.
> Well, this is not necessarily good advice. It is true that ArrowApply will
> preclude some sort of static analysis. But, this does not mean that you cannot
> do the static analysis on the pieces of code that *can* be written using less
> powerful arrow combinators.
Okay, you make a good point here; it might be the case that it is worth
implementing an Arrow interface in order to provide a set of combinators
that can do static analysis and hence confer some sort of benefit such
as improved performance.
> The same can be said about Applicative, Monad, etc. The combinators in the
> former could be implemented in ways that allow some extra analysis to be done,
> while those in the latter are still available when absolutely necessary. I
> believe the Utrecht parsing library does this, and encourages parsers to be
> written in applicative style as much as possible for this reason.
Darnit, you are using my own arguments against me here. ;-) I say this
because earlier in this forum I personally argued that it there are
times when it is beneficial to have the Applicative instance not
directly follow the Monad instance so that you do interesting things
that you can't do with the Monad instance, such as running computations
in parallel. Thus, likewise I am forced to see your point and conclude
that it might be useful sometimes to define an Arrow instance in
addition to a Monad instance so that the Arrow instance can take
advantage of the Arrow structure to do interesting things.
This has definitely given me food for thought; thank you.
> If you have nothing like that to gain, though, it may make sense to jettison
> arrows due merely to syntactic considerations and the like, though.
Yes, I agree, and in fact this the point that I have been trying to make
More information about the Haskell-Cafe