Quo vadis, GPC?

[samiam at moorecad.com]

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