Whenever people start discussing the Numeric type classes, the true scope of what a refactoring can (and should?) be is frequently under-estimated. The 'structure' of algebraic objects in mathematics has been studied quite a lot (in mathematics and in CS, but not so much by programming language people it seems). So I point out work like http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html/ which already has a richer set of "type classes", and that's just Aldor's "prelude". When you get going, you get the Algebra library (http://www-sop.inria.fr/cafe/Manuel.Bronstein/algebra/) which is _huge_. And most of the discussion on Numeric has been around the algebraic (Monoid, Ring, Normed, etc) structures that Numeric right now 'hides'. [Hopefully this answers your 'relevance' question].
Computer programming is of course extremely nominal to provide abstraction and seperation of concerns. Yes, anonymous functions are handy, but I could give them up if I had named local functions. Yes, you can even go to unlambda and only use combinators. Practically we find names extremely useful.
I am NOT arguing for no names! I also like names. What I am arguing for is to a) be able to use names whenever convenient and more importantly b) be able to provide _renamings_ when previously chosen names are _inconvenient_. In many ways, this is what ML's "with type foo = bar" qualifiers allow you to do to a certain extent when putting together modules/functors. It is also the basic idea behind the Adaptor and the Proxy patterns in OO. All these solve the same problem: how do you get around the issue that names in a module/class/whatever have been chosen in one way, and you need to use them in another.
Various algebraic specification languages have thus adopted this too, so that you are not forced to give unique names to all your concepts, you can in fact give them meaningful names 'in context', and use a remapping when you want to say that you obey a particular interface.
This sounds neat, but I'd be worried about how cumbersome it was in practice.
In practice, name clashes do not appear that often, so unique names are quite common. Name clashes tend to appear only for the most basic concepts that are highly polymorphic (like Monoid and Group!). But the same happens with generalized Container data-structures too (you can 'push' onto both a Stack and a Queue, but might want to use different names even though the concepts are essentially the same). It appears to work quite well. See Specware http://www.specware.org/index.html and many of the splendid papers available at http://www.kestrel.edu/home/publications/ Another line of work is Maude (http://maude.cs.uiuc.edu/), with explicit renamings http://maude.cs.uiuc.edu/maude2-manual/html/node78.html and more importantly VIEWs http://maude.cs.uiuc.edu/maude2-manual/html/node81.html (which have been talked about a lot on the various Haskell mailing lists, but Maude has had it implemented for quite some time). There are plenty of others, like CASL (http://www.cofi.info/CASL.html) and the OBJ family (http://cseclassic.ucsd.edu/~goguen/sys/obj.html) with similar features. In other words, the "specification language" people have been down this road quite some time ago, and seem to have worked out a fair bit of it. PL people should now liberally borrow all these good ideas IMNSHO.
Thanks. The ML interface paper looks quite interesting. Are you aware of any implementations?
No - but pressure is slowly building to do so. It is not an easy task, but as the Ocaml developers themselves are discovering as they are heavily 'functorising' some of their legacy code, there is a real need. I would be willing to believe that if there was a real push to use common type classes across GHC/Hugs/nhc/etc, the same phenomenon would 'appear'. Jacques