Twan van Laarhoven wrote:
apfelmus wrote:
class Category c where
id :: c a a (.) :: c b c -> c a b -> c a c
Unfortunately, the names id and (.) are already taken
I don't see a problem here, if you don't want to use these functions then don't import Control.Category. This is similar to the situation with adding the arrow operators to Data.Tuple.
Yes, except that these here are already in the Prelude. But hey, you can always import Control.Category import Prelude hiding (id,(.))
I am not a category-theorist, but is Category c the right terminology? 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, especially since we also have the 'Arrow' class. But I realize that morphism is not the correct term either.
Yeah, neither terminology is correct, but I'd opt for Category for the following reason: While a and b are objects in the category Hask, they may well be phantom types. For instance, c could implement a small stack based domain specific language and the types merely ensure that all stack operations are ok data C a b = Pop | Swap | Int Int | Float Float | Add data a :- b -- empty data Number -- empty pop :: C (a :- s) s swap :: C (a :- b :- s) (b :- a :- s) int :: Int -> C s (Number :- s) float :: Float -> C s (Number :- s) add :: C (Number :- Number :- s) (Number :- s) In the category Hask, those types Number and a :- b are empty but from the viewpoint of our category of stack operations, there are quite a lot of useful morphisms between them. Thus, in a sense, C can redefine the meaning of objects from Hask, so I think of it as more than a Morphism between objects in Hask. Regards, apfelmus