Stimulated by remarks made during the discussion on the future of Haskell at the last Haskell Symposium, I have started to convert my new parsing library (constructed for the Lernet summerschool in Uruguay) into Cabalised form. In this library I have amongst others the class: class Applicative p where (<*>) :: p (b -> a) -> p b -> p a (<|>) :: p a -> p a -> p a (<$>) :: (b -> a) -> p b -> p a pReturn :: a -> p a pFail :: p a f <$> p = pReturn f <*> p which extends/deviates from the standard class Applicative, since I think these functions more or less belong together. I am happy to factor out <|> into a separate class. The problem which arises now is when I want to use the class Applicative as it is now defined in Control.Applicative. Functions like <$>, <$, <* and many have standard implementations in terms of the basic function pure and <*>. Although this looks fine at first sight, this is not so fine if we want to give more specialised (optimised, checking) implementations, as I am doing in my library. An example of this is e.g. in many, where I want to check that the parameter parser does not recognise the empty sequence since thi is non-sense, etc. Of course we can describe <* by p <* q = pure const <*> p <*> q but this is also rather inefficient; why first building a result if you are going to throw it away anyway? My life would be simpler if the extensions would either be incorporated in the class Applicative, with default definitions, and were not defined at top level, or in a class Extend_Applicative. More in general I think it is preferred to place common patterns in classes with a default implementation, so they can be redefined instead of defining them at top level. 1) Does everyone agree with this observation, and if not what am I missing? 2) Can we change the module Applicative to reflect my view? I think it can be done without implying heavy changes to other modules. Doaitse