[Haskell] PROPOSAL: class aliases
Malcolm.Wallace at cs.york.ac.uk
Thu Oct 13 06:31:57 EDT 2005
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
More information about the Haskell