Lambda the Ultimate

inactiveTopic A Comparative Study of Language Support for Generic Programming
started 12/24/2003; 8:00:16 AM - last post 12/27/2003; 3:13:52 AM
Ehud Lamm - A Comparative Study of Language Support for Generic Programming  blueArrow
12/24/2003; 8:00:16 AM (reads: 7097, responses: 4)
A Comparative Study of Language Support for Generic Programming
Ronald Garcia, Jaakko Järvi, Andrew Lumsdaine, Jeremy G. Siek, and Jeremiah Willcock. A Comparative Study of Language Support for Generic Programming. In Proceedings of the 2003 ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA'03), October 2003.

I am a fan of generic programming, so I should be the first to celebrate papers of this nature. In this case, I am not sure I can.

Perhaps I can't get over the the fact that Ada isn't mentioned (and it was one of the first languages to offer industrial strength generic programming facilities). Perhaps the problem is that I got used to papers with better theoretical grounding. I am not sure.

Be that as it may, the subject is quite important, and seems to grow in importance daily (hooray, hooray). I suggest you read the paper and make up your own minds.

Please share your take on the subject in the discussion group.


Posted to Software-Eng by Ehud Lamm on 12/24/03; 8:03:00 AM

Isaac Gouy - Re: A Comparative Study of Language Support for Generic Programming  blueArrow
12/24/2003; 7:44:55 PM (reads: 482, responses: 0)
can't get over the the fact that Ada isn't mentioned
Tempting to ask the authors...

papers with better theoretical grounding
Well, I appreciate the variety, thanks for it.

Ehud Lamm - Re: A Comparative Study of Language Support for Generic Programming  blueArrow
12/25/2003; 3:09:23 AM (reads: 449, responses: 0)
Well, I appreciate the variety, thanks for it.

Sure. You don't want only theory, but when theory is called for, then let's have it.

Ehud Lamm - Re: A Comparative Study of Language Support for Generic Programming  blueArrow
12/25/2003; 4:45:06 AM (reads: 447, responses: 0)
When discussing language features that add expressiveness it is important not to forget the impact they might have on implenentation techniques and run time behaviour. As far as I can tell this issue wasn't dealt with by the authors.

Consider the Ada experience. Two major techniques exist from implementing generic units: macro expansion and code sharing. Obviously each technique has its pros and cons, and the Ada language designers worked quite hard to leave the choice up to each implementation (i.e., compiler). This implied various choices about the way generic units behave (consider issues like separate compilation). More so: these implementation choice reflect on other features of the language, since constructs can be nested, objects are passed as arguments etc. (all these are normal language design issues: it is not trivial to isolate language features). See, for example, the discussion of Downward closures for access to subprogram types (search for "sharing" to find the relevant sections).

Now, maybe Ada's attempt to enable both implementation techniques was a mistake, and maybe the impact this had on the language design is unfortunate. It may also be the case that the decision that tried to support the two implementation techniques were simply wrong. But to analyze these issues you have to expolore the implementation aspects of different designs, and see how language featues interact with one another.

John Skaller - Re: A Comparative Study of Language Support for Generic Programming  blueArrow
12/27/2003; 3:13:52 AM (reads: 310, responses: 0)
This paper is quite interesting, but unfortunately flawed. The authors, being too strongly influenced by C++, fail to properly distinguish two key features of C++ templates:

(1) parametric polymorphism (2) 'macro expansion' <g>

The very first example turned me off:

template <class T> const T& pick(const T& x, const T& y) {if (better(x, y)) return x; else return y; }

Any functional programmer would know that the 'better' function should be an argument, not resolved by macro expansion.

Consequently the authors get very confused by the notion of abstraction, and the argument for the notion of 'concepts' really shows their confusion:

"the formalization of an abstraction as a set of requirements on a type (or on a set of types)"

Anyone knowing any basic theory knows this is bogus: the very notion of abstraction implies types are meaningless points with no properties, and no relations between them...

What abstraction means is representation of types by *functions*, and the constraints must be imposed on the functions. [Cf. category theory]

It is very unfortunate this bogus model is followed by Stroustrup and is almost certain to be incorporated in the next ISO C++ Standard.

Despite this, the paper is interesting and worth reading, for the feature comparisons...even if they didn't get it quite right.

Of course, they missed the *important* concerns by concentrating on a bogus view of type constraints. Most programming languages only support data polymorphism, not functorial polymorphism, and this is one area where progress is needed. Crudely, higher order functions like 'map' have to be redefined for all data structures. Yet clearly, map is 'parametric' in the data functor, list, tree, or whatever. See Barry Jay's paper on Functorial ML:

http://www-staff.it.uts.edu.au/~cbj/Publications/functorial_ml.ps.gz

for a way to specify data functors so that map, fold, et al, are functorially polymorphic.