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

[Ross Paterson]

On Tue, Jun 30, 2009 at 01:37:05PM +0200, Henning Thielemann wrote:
> On Mon, 29 Jun 2009, 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.  This gives people creating instances the option of
>> defining specialized implementations of these functions, though they should
>> be equivalent to the default definitions.
>
> This sounds like a rather ad-hoc extension of the already complicated  
> hierarchy of those category classes. Are there particular examples where  
> the specialisation is needed and where it cannot be done by optimizer  
> rules? In case the specialised functions differ semantically from the  
> default implementations - are there generic algorithms that rely on these 
> semantic exceptions? Otherwise specialised functons can well be  
> implemented as plain functions and don't need to be type class methods.

I think this is a fair point: each proposed method should be justified by
a concrete example (i.e. code) of an equivalent definition that achieves a
significant performance improvement that one could not reasonably expect
from an optimizer.  I've given one for (<$).