Re: A general question about the use of classes in defining interfaces

On Wed, Oct 08, 2008 at 12:36:02PM +0200, S. Doaitse Swierstra wrote:
> 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.

This corresponds to Alternative, a subclass of Applicative (except for <$>
being a function instead of a method).  They certainly belong together
for parsers, but there are applicative functors that don't have the
extra monoidal structure.

> 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