Hello Arie, Tuesday, August 22, 2006, 8:24:17 PM, you wrote:
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)?
my proposal is modeled after real situations. i found than in most cases when some class is used two times or more in function signature, it should be the same type. existential types, suggested by Brian, rather rarely used in Haskell. may be it's just because there is no good syntax, but i think than in most cases polymorphic types are just enough
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').
you are right here -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com