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