[Haskell] PROPOSAL: class aliases

Simon Peyton-Jones simonpj at microsoft.com
Thu Oct 13 07:21:41 EDT 2005


| 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.

A short summary would be "type synonyms for class constraints".   You'd
definitely want the syntax to look as much like a type synonym decl as
possible.

I've considered this before, but never done anything about it because
superclasses are so close.  Specifically, what is the difference between

(i)	class (C a, D a) => CD a
and
(ii)	class alias CD a = (C a, D a)

Note that (i) is Haskell 98.

* In both cases one can write
	f :: (CD a) => ...
   instead of the more voluminous
	f :: (C a, D a)

* However with (i), for each type T one must write
	instance C T where { ...meths for C... }
	instance D T where { ...meths for D... }
	instance CD T where {}

whereas with (ii) one can write
	instance CD T where { ...meths for C...
				  ...meths for D... }

I believe that this latter is the sole difference.  Am I right?
[Implementation aspects aside.... with (i) GHC will pass one dictionary
CD containing a pair of dictionaries, one for C and one for D.]


If so, than rather than invent a whole new mechanism, why not simply
extend the existing superclass mechanism to allow a single instance decl
to declare instances for several classes?  For example, one add to
Haskell 98 the following:
	an instance declaration for a class CD with superclasses C and D
may 
	give the instances for its superclasses C and D

[One could quibble about details.  E.g Should the class decl for CD
*say* whether the instance decl *must* contain decls for the superclass
methods?  Or can one vary it on a instance-by-instance basis, which
might be more flexible?]


Anyway, my main point it: would a smaller change not suffice?

Simon


More information about the Haskell mailing list