[Haskell-cafe] Proposal for restructuring Number classes

[Jacques Carette]

Andrew U. Frank wrote:
> should * always be
> commutative or is its use for non-commutative types acceptable? 
>   
This very question caused much agony in many design meetings for the CAS 
Maple.  The list of pros and cons on each side is quite large!

There are too many really nice optimizations that one can do with a 
commutative, associative function (like * over commutative rings), and 
these are expected to be performed if ``efficiency'' matters.  Hoping 
that the compiler will always be smart enough to tell that in case X or 
Y, such an optimization is valid, is quite optimistic.

Until there is a way to encode that a particular instance of * is 
commutative, and another is not, it is much safer to have two symbols.

Note that I would personally prefer a much larger set of classes, which 
would include encodings of *properties*, so that one could (easily, 
cheaply) declare some occurence of * as commutative by using the right 
signature.  That would really require some kind of class aliases to have 
a hope of success.  But such a large set of classes is understandably 
too ambitious, and better suited to Haskell''.  But for a taste of what 
you get if you follow that route, see
http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html/
and also
http://www-sop.inria.fr/cafe/Manuel.Bronstein/algebra/
for why the 'base' of the system needs to be complex to allow scaling.  
Note that the above libraries are NOT optimal, as the authors went part 
of the way to fully breaking down the algebraic hierarchy, but were not 
prescient enough 10 years ago when the basic design was being laid down 
to break it down all the way.

Jacques