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