John Meacham <john@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