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

[Ross Paterson]

On Tue, Jun 30, 2009 at 06:24:57PM -0700, John Meacham wrote:
> On Tue, Jun 30, 2009 at 04:58:13PM +0100, Ross Paterson wrote:
> > 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.

The rules specified in this case are that the specialized version defines
the same function as the default definition.

> 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. 

Something doesn't add up here: things that don't terminate are not equal
to things that do.

> 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'.

It's true that Alternative is loosely specified, requiring only a
monoid, but it's still very useful (like MonadPlus).  In my opinion,
the compelling application is "Parsing Permutation Phrases", by Arthur
Baars, Andres Loeh and S. Doaitse Swierstra, Haskell Workshop 2001 (see
the action-permutations package).  It does seem that your application
doesn't fit the class, but it's not clear how dropping it would help.