| > 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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Reply via email to