proposal #3335: make some Applicative functions into methods,
and split off Data.Functor
Ross Paterson
ross at soi.city.ac.uk
Wed Jul 1 07:23:40 EDT 2009
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 (<$).
More information about the Libraries
mailing list