"class " proposal Re: [Haskell-cafe] One thought: Num to 0as
? to list?
ariep at xs4all.nl
Tue Aug 22 12:24:17 EDT 2006
Hello Brian and others,
On 2006-08-22, Brian Hulley <brianh at metamilk.com> wrote:
> 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
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').
Mr. Pelican Shit may be Willy.
More information about the Haskell-Cafe