| > Fair enough. But the strange syntax | > | > class alias Num a = Eq a => (Additive a, Multiplicative a) | > | > *does* seem so say that the (Eq a) behaves in a superclass way, and | > (Additive a, Multiplicative a) behave in a class-alias way, as it | > were. That seems inconsistent with the design goal you describe | > above. | | Wolfgang suggested the alternate syntax | | class alias Eq a => Num a = (Additive a, Multiplicative a) where .... | | The correct reading being: | | if 'Eq a' then 'Num a' is an alias for (Additive a,Multiplicative a) | | I think I am coming around to his point of view, do you think this makes | it clearer? I am not arguing about syntax! You say "class aliases are orthogonal to superclasses", but then you allow this "Eq a" thing in the above alias, which is very like a superclass. I think that if you allow the "Eq a =>" part, you should also allow new methods to be declared in the alias (as I originally thought you did). And if not, then you shouldn't allow superclasses. It's precisely that you allow superclasses (Eq a =>) that makes your feature non-orthogonal to ordinary superclasses. Maybe you can't make them orthogonal, but it quite hard to explain this definition to me. Incidentally, you say that your proposal is just syntactic sugar: if so, can you give the desugaring translation? Simon