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