D (was: Quo vadis, GPC?)

[Frank Heckenbach]

Rugxulo wrote:

> Frank, I would be curious what you think of Ada or Modula-2, esp.
> since both of those have (official or unofficial) GCC support. And
> there are already (weak) converters from Pascal to Ada, Oberon,
> Modula-2, etc. (But no GNU Oberon, only OO2C.)

Since you ask me specifically: I've never programmed in any of those
languages myself (outside of University), and I haven't followed
their development in recent years.

Since most of these languages are not widely used, I wouldn't
consider them attractive targets for a converter. Ada may be an
exception, but it's still less widely used than C++, and at least I
know C++ much better than Ada -- though if there's a number of Ada
programmers here (whom I don't know yet :-) it might make it
interesting to consider as a target.

Weak converters are IMHO of not much use, since turning them into
full converters is probably as difficult, if not more so, than
writing one from scratch. As the saying goes, the first 90% take the
first 90% of time, the remaining 10% take the other 90%. In this
case even worse, since e.g. parsing 90% of a language or
implementing 90% of semantics can be drastically easier than
(almost) 100%, if the problematic cases are simply left out (or
mishandled). (Furthermore, I suspect they each support only one
Pascal dialect, in contrast to GPC.)

As an example, the GPC frontend was originally devrived from the C
frontend (note, I'm not talking about the backend issues here, but
the actual frontend responsible for handling Pascal). Initially,
this provided some success quickly, as many Pascal features map more
or less roughly to C features (e.g. arrays to arrays, [variant]
records to structs/unions, for/while/repeat loops to for/while/do
loops, Integer to int, mod to %, procedures/functions to functions
etc.). But the devil is in the details, and that's a damn big devil
here (e.g., C arrays are 0-based, Pascal arrays don't have to, C
arrays convert to pointers automatically, Pascal arrays don't,
variant records have an invariant part (unlike unions) and special
semantics (though many Pascal compilers, including BP, ignore them),
Pascal for-loops evaluate their bounds once before execution, mod
behaves differently in Pascal and C for negative arguments, function
parameters in (esp. K&R) C are not checked, etc. etc.). Each of
those points (and many more) have caused us much work in the
frontend later on in order to fix them and for that it didn't help,
but actually hurt, that the frontend handled them somehow, but wrong
(i.e., in the C way), and without any warning or indication where to
look for errors. E.g., simply calling a routine with a large number
for an integer parameter would give no compile-time error, but wreak
havoc at runtime with early GPC versions (until about 1997) because
they would be passed as "LongInt" or so, the routine expected
"Integer", no checks were done, and as the result, all "following"
parameters (i.e., left of and, depending on endianness and stack
direction, including) the actual one were read completely wrong in
the routine). Also, for a long time the frontend carried a lot of
ballast necessary in C, but not used in Pascal, until I spent quite
some time cleaning (most of) it up. In retrospect, I suppose writing
the frontend from scratch would have been less work in total.

Frank

-- 
Frank Heckenbach, f.heckenbach at fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8