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.