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

[Henning Thielemann]

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.