Proposal: Add Compositor class as superclass of Arrow

[apfelmus]

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