proposal #3335: make some Applicative functions into methods,
and split off Data.Functor
Henning Thielemann
lemming at henning-thielemann.de
Tue Jun 30 07:37:05 EDT 2009
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.
More information about the Libraries
mailing list