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