Haskell' - class aliases

[Jacques Carette]

In all honesty what I want is a solution to the problems clearly 
outlined in the first two sections of his proposal. 

People may not be clamouring for this (yet), but that maybe simply 
because they've gotten used to the de facto Haskell style of giant type 
classes and never seriously asking themselves if maybe there was a 
better way to do things.  Certainly the issues that 1) Num needs broken 
up, and 2) Functor and Monad should be related, do come up relatively 
frequently.

John's example for 'Lattice' is really spot-on, that is exactly what
1) a developer for an advanced class wants
2) exactly what a developer would like to provide to users (ie the 
coarser Lattice and BoundedLattice).

In my mind that defines the problem to be solved quite nicely.  Which 
gets us to:

Simon Peyton-Jones wrote:
> I've just had another look, which threw up quite a few questions in my mind.   I wonder what would be a good list to discuss it.  Maybe this one is not bad, because it has people interested in Haskell innovation, regardless of whether it's a live Haskell' candidate?
>   
I wrote the above because there really are two very different kinds of 
questions: requirements and design.  If there is first a solid agreement 
on requirements, then it is much simpler to tweak the design.  
[Motherhood stuff, sorry, but sometimes a reminder of such things is 
useful].  So in what class are your questions?

Since we are talking requirements: to properly follow Parnas' ideas on 
good design, we should ask ourselves what are the likely future changes 
in this area.  I know of one extension which will definitely be wanted 
in the future: renamings.  For example, mathematicians frequently switch 
between additive and multiplicative notations for Groups.  So one would 
want to ``inherit'' from a class but allow for a name change at the same 
time.  In effect, one can already to this, ie
class Foo a where
    foo :: a
class Foo a => Bar a where
  bar :: a
  bar = foo
However the difference is that the equility bar = foo is not known 
intensionally, ie not available to the compiler as something that can be 
reasoned with.  I do believe that that will be an important future 
consideration.  [I could be wrong about how the status of such 
equalities in the language definition, but I must admit I would be 
surprised if it were otherwise]. 

Note that such 'renamings' are a common operation available in 
"algebraic specification languages" of various kinds.  And type classes 
really are much closer to (algebraic) specifications than anything else, 
so I do believe that one can learn what are the 'useful operations' from 
those languages.

Proper design then means that a current solution allows for a solution 
of the above in the future, and definitely does not make such a solution 
impossible.  The solution does not have to be done (either designed, 
much less implemented) now.  [Teaching SE does seem to infect one's 
mind, doesn't it?]

Jacques