A general question about the use of classes in defining interfaces

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