hmm, i thought i understood what class aliases were about,
but the recent discussion about superclasses and fixpoints
has me confused again.
may i suggest that the updated proposal page follows this
outline (in particular, providing 1 and 2 before diving into 3):
1. general idea + one simple example to confirm intuition
(if there are obvious misinterpretations, it might be
useful to list and discard them here)
2. translation scheme (formal enough to run all examples)
3. concrete examples to highlight difficult issues and
special cases
4. syntactic sugar to make typical uses easier
the way i thought i understood them (and the way i encoded
them in the example i sent), class aliases consist of two parts:
A aliasing of constraints/classes
(this is the semantic part that could also be explained by
reduction, or by simple mutual implication encodings)
B aliasing of syntax, especially instance definitions
(this syntactic part is hard to encode, and simple in
terms of syntactic macro expansion)
so, in writing
class alias A x = (B x,C x)
we'd get
from A: the semantic equivalence of the constraints,
which we usually encode roughly like this
class (B x,C x) => A x
instance (B x,C x) => A x
from B: the syntactic equivalence of different ways
of defining instances of A,B, and C, which
is best understood by expanding all instance
definitions for A into instance definitions of
B and C
defining instances of B x and C x is equivalent to
defining an instance of A x (so defining an instance
of A x if either B x or C x already exist leads to
duplicate instances)
everything else is syntactic sugar, such as having methods
or constraints in A that are not present in B or C.
if this is wrong somewhere, could you please correct it?
otherwise, i'll wait for the updated proposal page to
explain the details.
claus
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
