[Haskell-cafe] Re: Numeric type classes
carette at mcmaster.ca
Wed Sep 20 10:56:54 EDT 2006
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
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
which is _huge_. And most of the discussion on Numeric has been around
the algebraic (Monoid, Ring, Normed, etc) structures that Numeric right
[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
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
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
and many of the splendid papers available at
Another line of work is Maude (http://maude.cs.uiuc.edu/), with explicit
and more importantly VIEWs
(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
More information about the Haskell-Cafe