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.