proposal #3335: make some Applicative functions into methods,
and split off Data.Functor
ekmett at gmail.com
Wed Aug 19 13:04:13 EDT 2009
(*>) 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
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.
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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries