# Arrow Classes

**Ross Paterson
**
ross@soi.city.ac.uk

*Thu, 10 Jul 2003 14:33:25 +0100*

On Thu, Jul 10, 2003 at 02:00:37AM -0700, Ashley Yakeley wrote:
>* In article <20030630150455.GA8927@soi.city.ac.uk>,
*>* Ross Paterson <ross@soi.city.ac.uk> wrote:
*>*
*>* > The point about symmetry is a fair one, but unfortunately the Haskell class
*>* > system imposes a cost on fine-grained class hierarchies,
*>*
*>* It does?
*
There are more instances and methods for people to define, even if some
of them imply others.
As it happens, I would like yet another intermediate class:
class BiFunctor a where
bimap :: (b' -> b) -> (c -> c') -> a b c -> a b' c'
(and I have a client for the class: a useful subset of the arrow notation
needs only this, in fact only the contravariant part.)
Clearly any arrow is also an instance of this class:
bimap b c f = arr b >>> f >>> arr c
but you still have to define bimap even if the type is also an arrow.
Subclasses in Haskell cover a range of relationships, including this
sense where things in the subclass automatically belong to the superclass.
Other examples include Eq => Ord and Functor vs Monad. In such cases it
would be handy if the subclass could define defaults for the superclass
methods (e.g. Ord defining (==)), so that the superclass instance could
be optional.