Proposal: Add Compositor class as superclass of Arrow
Twan van Laarhoven
twanvl at gmail.com
Sat Oct 13 07:03:25 EDT 2007
> 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.
More information about the Libraries