Proposal: Add Compositor class as superclass of Arrow
apfelmus
apfelmus at quantentunnel.de
Sun Oct 14 08:51:51 EDT 2007
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
More information about the Libraries
mailing list