[Haskell-cafe] Re: Numeric type classes

[Jacques Carette]

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