[longish proposal for class aliases]

== Notes ==

* class aliases are also able to introduce new superclass constraints, such as in the Num example we also want to enforce a (Eq a, Show a) superclass constraint. the interpretation is straightforward, Num in type signatures expands as if those were part of the alias and when declaring instances the existence of instances for the superclasses are checked, but not filled in automatically. I didn't show an example so as to not confuse the basic idea and because I have not come up with a syntax I am happy with. (suggestions welcome)

... * I had an earlier supertyping proposal you might know about, I feel this is a much better proposal even though it doesn't fully subsume my supertyping proposal, I feel it solves the problems it was meant to solve in a cleaner and easier to implement way.

* You may wonder why for the num example I put Additive a in the class alias even though it was already a superclass of AdditiveNegation. that is because class aliases do not change the meaning of superclasses, you need to explicitly list a class if you want instance declarations to propagate methods to it. superclasses are checked just like normal in class aliases.

* incidental but not earth-shattering benefits include being able to declare an instance for a class and all its superclasses at once, smarter defaults when you are combining related classes, and much nicer type signatures by being able to create your own aliases for common combinations of classes.