Proposal: Add Compositor class as superclass of Arrow

[Twan van Laarhoven]

apfelmus wrote:
> Yes, bring 'em in! But _only_ under their standard name :)
> 
>   class Category c where
>     id  :: c a a
>     (.) :: c b c -> c a b -> c a c

I think using these names is a good idea, it means that you can write 
generic code without it becoming an ugly mess of non-standard names.

> Unfortunately, the names  id  and (.) are already taken / give headache 
> to those that don't like  map :: Functor f => (a -> b) -> f a -> f b .

I don't see a problem here, if you don't want to use these functions 
then don't import Control.Category. This is similair to the situation 
with adding the arrow operators to Data.Tuple.

Also, these functions are likely to give less problems than the map 
function; I can't think of a case where they are not directly used as a 
function, which immediatly leads to c = (->).

I am not a category-theorist, but is Category c the right terminoligy? 
As I understand it 'c a b' is a morphism between the objects 'a' and 'b' 
from the category Hask. I don't think there even is a name for the type 
constructor c itself. When I wrote this exact class for myself a while 
ago I called it 'Morphism', which makes (some) sense, espacially since 
we also have the 'Arrow' class. But I realize that morphism is not the 
correct term either.

Twan