proposal #3335: make some Applicative functions into methods, and split off Data.Functor

[Edward Kmett]

(*>) and (<*) could be used to apply recognizing parsers for the discarded
half. This makes a huge gain for uu-parsinglib. uu-parsinglib's P_m monad
could be extended just as it has done with P_f and P_h to also wrap its
existing R monad, which would let it apply the parser as a recognizer
efficiently.

And for parsimony it allows me to treat that side of the alternative grammar
as a right seminearring ignoring the argument, this increases sharing
opportunities for my grammar fragments, because pure nodes in recognizers
can be treated as epsilons in the grammar and safely elided.

-Edward Kmett
On Wed, Aug 19, 2009 at 11:40 AM, Ross Paterson <ross at soi.city.ac.uk> wrote:

> On Mon, Jun 29, 2009 at 01:45:45PM +0100, Ross Paterson wrote:
> > The proposal is that the following functions
> >
> >     (<$) :: Functor f => a -> f b -> f a
> >     (*>) :: Applicative f => f a -> f b -> f b
> >     (<*) :: Applicative f => f a -> f b -> f a
> >     some :: Alternative f => f a -> f [a]
> >     many :: Alternative f => f a -> f [a]
> >
> > are moved into the corresponding classes, with the existing
> implementations
> > as default definitions.
>
> Henning asked for concrete examples (i.e. code) where this would give
> a substantial performance win while still defining the same function,
> including termination properties.  (But it seems reasonable not to rely
> on RULES to improve the asymptotic complexity.)
>
> I gave an example for (<$).  Does anyone have concrete examples for
> the others?
>  _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090819/ce52243b/attachment.html