[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