Editing Comparing class alias proposals (section)

== Instances of class aliases ==

One of John Meacham's main reasons for his proposal is the lack of possibilities for abstraction in the current class system: "there is no way to hide the fact that you changed a class hierarchy", he writes. Therefore, he introduces the possibility of writing instances of ''class aliases'':

 class alias Num a = (Additive a, AdditiveNegation a, Multiplicative a, FromInteger a)
 
 instance Num a where
   zero        = ...
   (+)         = ...
   (-)         = ...
   negate      = ...
   one         = ...
   (*)         = ...
   fromInteger = ...

'''Motivation''': Class designers can now later split up a class in smaller classes if they redefine the initial class as a class alias for the new, smaller type classes. More specifically, this could solve the Num hierarchy problem: how to redefine the Num-related type classes in the prelude while maintaining backwards compatibility?

John's example above introduces new functions <code>zero</code> and <code>one</code> which conflicts with the idea of splitting up Num in strict subclasses. However, this problem is (supposedly?) solved by overriding superclass defaults; see below. Also, <code>signum</code> and <code>abs</code> are not present in the example, but they may be added to the appropriate subclasses.

John's proposal can be decomposed into two smaller steps:
* being able to write one instance header for several instances at the same time
* then replacing the several type classes by a class alias.

'''Q''': What if an instance header expands to several instances of the same class?

For example, a class alias instance could expand to:

 instance (Functor [], Functor Maybe) where
   ...

Then multiple <code>fmap</code>s need to be defined. Which is which?

'''Q''': What if an instance is made of several classes with overlapping function names?

Currently function definitions in a class may not be qualified; only the class name in instance header may be qualified. Being able to write several instances under one header introduces naming problems in this case.

'''Q''': What if a class alias expands to many classes, of which one already has an instance in scope?

Should we forbid such an instance and force the programmer to expand the class alias manually to all classes except the one of which there is an instance of already?

Or should such an instance still be allowed, but the implementation of the violating class be forbidden? It seems like a bad idea to allow this without making such an omission clear and explicit in the syntax.

=== Class alias or context synonym? ===

Can class aliases as used above be read as "context synonyms"?

Clearly there are many differences between the two. Their intended uses are originally different. Should they be two different things instead?

Class aliases (in the case of writing instances of them) seem like a strict subset of context synonyms. If class aliases are to piggyback on context synonyms, then we need to think carefully about what form such a context synonym should have for instances to make sense.