J. David Bryan wrote:
This raises a point of interest to me. When GPC development stalled, I had to decide whether to continue with GPC as it was, switch to another Pascal compiler, or switch languages. I have programmed in Pascal for thirty years; it was my fifth language, after BASIC, Algol 60, FORTRAN IV, and SNOBOL, and of those, it is the only one in which I have continued to develop new programs. This was due primarily to the existance of GPC, and especially its good support for ISO 10206.
For a number of reasons, I elected to switch to Ada, as implemented by the GNU Ada compiler (GNAT). I had studied the language shortly after it was introduced in 1983 but did not use it seriously until a GCC version became available. I found the transition from Pascal to Ada to be quite easy, because many of the implementation concepts are similar. For several years, I've done all of my new work in Ada instead of Pascal.
I would think that translating from Pascal to Ada would have some advantages over C++. For example, Ada inherently supports scalar subrange types and range checking. I'm not that familiar with C++, but I don't believe that subranges are supported.
No, not directly. However, range-checks are a rather minor issue -- for comparison, it took me a few days to implement them in GPC, while the object models took weeks or months (I'm not sure exactly how much work Peter and Waldek spent on them), exceptions implemented from scratch would take weeks, and templates probably much longer. So it's these "big things" that matter most. You might think checked subranges are more important because they're more fundamental (which they are), but they're just not so difficult to implement. For the 3 big things I mentioned, I know C++ has them already. I don't know if Ada does, perhaps you can give us some information here, e.g., is its object model comparable to those GPC supports or that of C++; does Ada supported exception handling and how; does it support something like templates (IOW, how can one implement, say, a generic list, applicable to any given type, with strong type-checking).
Other examples would be nested procedures, packed arrays and records, and string slice access, all of which are inherently supported by Ada.
Nested routines are the only serious lack in C++ I see so far. Packed arrays/records and array slices can be implemented in C++ code with moderate effort (much easier than the current TREE_NODE implementation in GPC, which is messy and inefficient, as you note below).
In short, I would expect that the closer mapping of Pascal to Ada constructs would result in a simpler translator than if the target language differed more significantly from Pascal. In many cases, the emitted Ada code could be nearly identical to the Pascal code.
I fear this might only be true for more traditional Pascal, while I stated that I'm particularly interested in more "modern" features that I know from C++. Of course, if Ada also supports them, it would make it more interesting.
GNAT is well supported by AdaCore Technologies, whose large customers (e.g., Boeing, Lockheed) drive compiler improvements and bug fixes back into the GCC code base. So the compiler is in good shape, and it maintains compatibility with the current GCC release. (One metric that I considered when switching from GPC to GNAT was that a packed array access that generated about 175 instructions in GPC generated only 15 for the equivalent code in GNAT.) GNAT is also well-supported by GDB.
I don't doubt any of that, and for manually porting your code, Ada was probably the better choice than C++ for you, and might be for many other users.
Kevan Hashemi wrote:
I agree that a Pascal to C++ translater would be just fine. But on the other hand, that means that we need people who enjoy programming in both Pascal and C++ to support the project. Anyone who fits that description is not going to have much use for the product, because they might as well program in C++ in the first place.
That may be the case. So far it looks I might be almost the only one, and in this case it's probably indeed easiest if I just port my programs to C++.
The people who are dedicated to GPC are people who greatly prefer to program in Pascal. Most such people dislike programming in C++.
I'd speculate that most of them actually don't know C++ too well (neither did I until a few years ago). C has a bad name here, partly for good reasons, and partly for historical competition. C++ seems to inherit this bad name mostly because of its similar name, indeed. Yes, it contains all of C's misfeatures, but as I said before, so does GPC in the form of "BP extensions". Let's do a quick check (note: not all of the listed points I consider pure misfeatures, some of them have their use, though I think they're often overused, in both languages, when better alternatives are available):
- Untyped pointers: check
- Untyped memory operations (e.g., memory copy, fill): check
- Untyped files: check
- Arbitrary type casts: check
- Hidden type casts by abusing unions (variant records): check
(Plus hidden type casts by "absolute" variables, a BP misfeature that even C doesn't have.)
- Zero-based, manually memory-managed strings with clumsy support functions: check ("PChar" and the "Strings" unit)
- Mixup between arrays and pointers: check (if only for "PChar")
- Always-0-based arrays: check ("open array" parameters)
- Unchecked array ranges: check (by turning off range-checking, which BP allows locally, and which is sometimes used intentionally for "dirty stuff")
- goto: check (even in standard Pascal)
So, yes, one can write dirty C-style programs in C++, but so can one do in BP and therefore GPC. However, high-level C++ looks quite different. E.g., there's a string type (which is internally a template in C++, while it's a compiler built-in in GPC, which is a difference mostly invisible to the programmer) which similar string operations as in Pascal (from "+" to "substr" to various find operations), range-safe and with dynamic memory management (so you can have strings of unbounded length, which GPC can't do yet -- at best you can have "^String", but then you have to manage its allocation yourself).
The C++ object model is a little higher-level than the various Pascal models (I explained the automatic con-/destructors which are easier to use and less error-prone than Pascal's explicit calls).
And of course, a simple list (using the STL template) is no comparison to a hand-made list in Pascal (or a general list abusing type-casts or other dirty tricks).
The only major drawback I see is the lack of modules.
Of course, the syntax is quite different from Pascal (and quite similar to C), but for me that's just not an issue -- it just looks different, and I can't even say GPC's syntax is much cleaner in total (with all the BP mess mixed in).
So who is going to write this translator? Not me. Is Frank going to write it on his own?
I'd like to, but someone would have to pay my bills for the next several years. ;-)
It may be ten times as much work to re-write the compiler in Pascal, but we may find that we have a hundred times as much developer time available.
One way to proceed is for Frank to estimate how many developer hours are required for a Pascal compiler in Pascal, and for a Pascal to C++ translator, then we poll the list to see how many hours people are prepared to dedicate to each project. If only one of them gets enough hours, then we have only one practical solution.
What exactly do you mean by "Pascal compiler in Pascal"? What would its output be?
John L. Ries wrote:
The more I think about it, the clearer it is to me that the Pascal to C++ translator is the option discussed that I like the least. I actually would prefer a Pascal to Ada translator more than Pascal to C++, because if I had to abandon Pascal, I think I'd be much more comfortable programming in Ada than in C/C++
That's not quite what I was talking about. I meant a converter as a compiler replacement, i.e. you would write your source in Pascal, and to build it, convert to C++ and compile it (so C++ is just a mostly invisible intermediate step, like assembler code is now).
You seem to mean a permanant conversion to another language, so you'd maintain your code in the new language afterwards. For this purpose, Ada or Modula-2 might be more suitable for many Pascal programmers. (For me probably it would probably still be C++, if only because I know it better now, and such code could integrate better with my other recently-written C++ code. But for this purpose, I wouldn't write a complete converter -- it's not worth the effort -- maybe a small tool for the most boring parts of the conversion, perhaps just a sed script for some obvious syntax changes.)
Frank