Quo vadis, GPC?
samiam at moorecad.com
samiam at moorecad.com
Wed Jul 28 04:16:12 CEST 2010
Some brief notes on your presentation "Quo vadis, GPC" (Where is GPC
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
for my compiler. I rejected this idea because, primarily, of the very
between the front and back ends of GCC. This is in contrast to the well
intermediate code coupled systems outside of GCC.
The other issue is the, frankly, hostile attitude of the GCC folks
Fortran and other compilers are distributed with GCC and get better
from the GCC group. I can't help but think that this comes from the C
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
way to insure that GPC dies quietly. Virtually all of the "cascade"
including Cfront, had severe difficulties, including becoming
coupled to one particular backend, and angering users by giving errors
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
with wide implementation. However, you detail well the unseen costs of
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
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
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
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
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
I looked at templates for Pascaline, and I used your exact example to
evaluate it, that is, general handlers for list structures. However, I
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
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
you would both be independent of GCC and much farther along on your
goal of a GPC rewritten in its own language.
More information about the Gpc