Frank,
Some brief notes on your presentation "Quo vadis, GPC" (Where is GPC going).
I'd of sent it direct, but I note your email is not working.
First, I also considered, and was strongly suggested, to use GCC as a backend for my compiler. I rejected this idea because, primarily, of the very tight coupling between the front and back ends of GCC. This is in contrast to the well developed intermediate code coupled systems outside of GCC.
The other issue is the, frankly, hostile attitude of the GCC folks towards Pascal. Fortran and other compilers are distributed with GCC and get better support from the GCC group. I can't help but think that this comes from the C group perception of Pascal as a rival, which it used to be but is no longer.
As for making GPC a front end for another compiler, I can't think of a better way to insure that GPC dies quietly. Virtually all of the "cascade" compilers, including Cfront, had severe difficulties, including becoming unnaturally coupled to one particular backend, and angering users by giving errors from the underlying compiler that the front end didn't catch. C++ became a success because Stroustrup moved quickly away from Cfront and onto a true compiler for C++.
GPC started out with a big advantage due to having a high quality back end with wide implementation. However, you detail well the unseen costs of that, including a moving target back end specification, inability to write the compiler in its own language, etc.
Pascal scores low as a common implementation language, but as you detail, most of this is because of a movement to interpreters and away from true compilers. Although this is stated to be "because of ease of development", I believe in large part this is a reaction to the difficulties of C/C++ development, which is directly traceable to the complexity of the language and the difficulties with debugging a language totally lacking in basic type security. I think nothing underlines this more than Anders' move to Microsoft and C#: Anders went from taking a language designed around type security (Pascal) and tearing away its type security, to taking a language designed around a lack of type security (and proud of it) C, and adding type security to that.
I completely agree with your diatribe on automatic destructors. I choose automatic (and anonymous) constructors and destructors for the language Pascaline (a highly extended version of Pascal) because I believed it was necessary for the compiler to both control when, and in what order, the constructors and destructors are called.
I also believe (as shown in Java and C#) that classes should be treated as code structuring constructs and NOT as "extended records", and that both static and dynamic objects have their uses. In Pascaline, classes are expressed as modules which can be instantiated, and fit within modules in program structure (programs are a series of modules which may contain classes). For more on that, I invite you to look over the Pascaline specification:
http://www.standardpascal.org/standards.html
I looked at templates for Pascaline, and I used your exact example to evaluate it, that is, general handlers for list structures. However, I came to the conclusion that this was also the paramount example for classes, and in fact classes are an example of a highly structured system of typing that reduces the need for the highly unstructured method offered by templates (which by the way, Wirth is on record as saying was not such a hot idea).
Although I am not sure I see the sense of your basic argument (interest in GPC is falling off, so lets rewrite it). I would say it makes equal sense to simply start moving parts of GPC into its own language and away from C. If you were to write a code generator to replace the back end, in Pascal, you would both be independent of GCC and much farther along on your goal of a GPC rewritten in its own language.
Cheers,
Scott Moore