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

[John Meacham]

On Tue, Jun 30, 2009 at 04:58:13PM +0100, Ross Paterson wrote:
> On Tue, Jun 30, 2009 at 11:45:50AM -0400, Edward Kmett wrote:
> > I've been burned by this myself as well. I also have a set of parser
> > combinators that I've been working on that could currently greatly
> > benefit from these asymptotically in some places and in the case of a
> > bottom up monoidal parser I've been working with, the availability of
> > these makes the difference between termination and non-termination
> > in some cases.
> 
> Ah, but that's changing the meaning, which isn't what these are supposed
> to be for.

I don't see why not. As long as your versions follow whatever rules are
specified for the class. frisby also cannot use Applicative as is
because these methods arn't able to be overridden and the default
implementations lead to pessimal (to the point of unusabality, or even
non-termination) performance. However frisby can provide perfectly valid
implementations of them that follow the Applicative laws and have no
such issues. 

Actually, 'Alternative' doesn't have any rules as to its meaning, which
is probably why the broken 'many' and 'some' ended up there in the first
place. Personally, I'd prefer just to drop 'many' and 'some' (and
perhaps 'Alternative' itself) completely since it isn't clear meaningful
definitions exist for what we might consider members of 'Alternative'.

But making them members of the class is an acceptable compromise if
people don't want to drop Alternative. Without a clear meaning, it is
basically just a syntax reuse class.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/