[Haskell] PROPOSAL: class aliases

[Malcolm Wallace]

John Meacham <john at repetae.net> writes:

> = Class Aliases =
> 
> This is a proposal for a language extension which will hopefully mitigate
> the issues holding back evolution of the standard prelude as well as provide
> useful class abstraction capabilities in general.

I like your proposal a lot.  Do you have an implementation of it in jhc?

> >  class Foo a where
> >    foo :: a -> Bool
> >    foo x = False
> >
> >  class Bar b where
> >    bar :: Int -> b -> [b]
> 
> >  class alias (Foo a, Bar a) => FooBar a where
> >    foo = ...
> >    bar = ...

One thought: how will class aliases interact with type inference?
e.g. if a declaration contains only a call to 'foo', should we infer
the constraint Foo a, or FooBar a?  Can there ever be a situation where
choosing the more specific dictionary could leave us without a 'bar'
method at some later point in the computation?  (cf. up-casting and
down-casting in OO languages).

If I declare a function

    baz :: Bar a => ...

and then pass it a value which actually has a FooBar dictionary rather
than just a Bar, will the implementation be able to find the right
offset in the dictionary for the 'bar' method?  How?  (I know jhc
eliminates dictionaries at compile-time, but other implementations
do not.)

Regards,
    Malcolm