Hello Brian and others,
On 2006-08-22, Brian Hulley
I wouldn't like it because I'd like to eventually make the class namespace separate from the tycon namespace so that I could write:
class Object a where ...
data Object = forall a. Object a => Object a
I like the idea of separating class and type constructor namespaces, and then being able to use existentials as in your example (although the latter would also belong in the category "not nice to beginners struggling with discriminating type constructors, data constructors and classes"). On the other hand, I find Bulat's proposal also very attractive, especially when considering the important example of the list type. The question is essentially: what do we want to express when writing things like: f :: Object -> Object g :: Object -> Object -> Ordering h :: Object -> Object -> Object i :: Int -> Object ? Is the argument of 'f' an 'Object' of the same concrete type as the result (Bulat's proposal)? Or do we only demand that they are both an object, possibly implemented in different ways (using sloppy OO language)? Putting it this way, I think I tend to prefer the latter. It is easier somehow if the meaning of "Object" does not depend on other parts of the type signature. Consider the following example: k :: Garage -> Car type Garage = Car -> Car Bulat's proposal (if suitably extended to apply to type synonyms as well) would not allow you to substitute the definition of 'Garage' (which would then be equivalent to 'type Garage = forall a. (Car a) => a -> a') in the type signature of 'k' (because then the 'Car' of the 'Garage' definition would suddenly be unified with the result type of 'k'). Greetings, Arie -- Mr. Pelican Shit may be Willy. ^ /e\ ---