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 (<$).