[Haskell] PROPOSAL: class aliases

John Meacham john at repetae.net
Thu Oct 13 06:56:50 EDT 2005

On Thu, Oct 13, 2005 at 12:46:21PM +0200, Andres Loeh wrote:
> > 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.)
> The way I understand the proposal, there are no FooBar dictionaries
> ever. John said that this can be translated by a source-to-source
> translation, so internally, a FooBar dictionary *is* a Foo and a
> Bar dictionary.

This is correct. perhaps 'class synonym' might be a better name? 
FooBar a and (Foo a,Bar a) are actually equivalent as if it were
replaced via a textual macro substitution. the only place they are treated
differently is in instance heads as declaring an instance for an alias
will declare instances for all of its components. 

> How much static checking can be done before desugaring the code? Will
> it be possible to give sensible error messages, or will those mention
> the "internal" classes that the alias is supposed to hide?

A simple implementation would mention all the 'internal' classes. but
ghc already knows to replace [Char] with String, it could do something
similar looking for when a bunch of constraints can be simplified into
a shorter alias and printing that.

It also might be useful to have a pragma for the Haskell 98 names
saying error messages should always be in terms of them when possible in
haskell 98 mode so people learning from haskell 98 books arn't confused.

perhaps something looking at the current names in scope could also be
done, like if you only have the aliased names in scope, print errors in
terms of those rather than the internal ones. 

How much this will be an issue in practice we will have to see. we
might have to experiment some to find the best method for producing
error messages.


John Meacham - ⑆repetae.net⑆john⑈ 

More information about the Haskell mailing list