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