A general question about the use of classes in defining interfaces

S. Doaitse Swierstra doaitse at swierstra.net
Wed Oct 8 08:07:50 EDT 2008


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





More information about the Libraries mailing list