Kevan Hashemi wrote:
In order to create a GPC that compiles itself, we need run-time libraries that provide OS routines. I assume that every OS provides such libraries independent of GCC's existence or version in the system.
Again, we have the libraries (i.e., the basic runtime library, not including stuff like graphics, see my mail about GRX, but file handling etc., including everything that a compiler needs -- which is actually not much, as far as the envinronment in concerned). On every platform where GPC runs, almost by definition, its runtime library runs.
Given that GPC's Pascal is, in your own words, Turing Complete, I assume it is possible to write in the current version of GPC the code to implement any future version of GPC, regardless of the new features.
Yes, it's possible, but it's IMHO not conformtable. I know I'm repeating myself, but I'm really fed up with having to "reimplement the list", as I wrote. It's also a psychological thing IMHO -- if advanced data structures (objects, trees, hash tables) are readily available (as in C++), you tend you use them when useful; if they're not (as in Pascal, except for objects), you're much more likely to do quick ad-hoc work-arounds, which affect the efficiency, but also the design of your program, especially in the long run. GCC's TREE_NODEs are a particularly bad example of this, spreading all over the code, but also in my Pascal programs, I often find a lot of ad-hoc list (or other structures) handling code that obscures the actual purpose of my code and thus make it harder to understand later.
Thus, re-writing GPC in Pascal seems to me to be a Pascal programming job. If there are enough development hours available, it is an elegant and long-lasting solution to GPC's problems.
Unfortunately I think that's a big "if". Your offer is appreciated, but AFAICS, even in the optimistic case (no distractions will reduce the available time in the foreseeable future), we're still way short of the necessary "manpower" to create a new compiler.
I can program in Pascal. I could write a lexer, a parser, or any other part of the program.
One note: For any project that I'd be involved in, I'd insist that the parser is created by a tool, not hand-made. It doesn't necessarily have to be Bison, but it seems a good choice since we already have the GPC language grammar in Bison form -- as I wrote, the actions would have to be rewritten, but that's the easy stuff; the hard part, the grammar, could be kept essentially unchanged, including, e.g., the handling of near-ambiguities that arose from the combination of several dialects (or sometimes from single-dialects alone -- Borland, I'm looking in your direction) and other issues.
Why do I think so? Mainly because I'm convinced that designing languages (and a new GPC would add new features, including new syntax) using hand-made parsers usually leads to bad syntax, i.e., ambiguous, nearly ambiguous or otherwise problematic.
A typical example for me is BP (or then, TP) that was written, for all we know, with a parser hand-written in assembler. They designed some problematic syntax, worst of all "^C" style character constants. A parser generator would have told them right away that they cause serious problems (and thus were a bad idea). Writing a parser by hand doesn't tell you so, so they happily added them, probably not even noting that their own new feature didn't work in many cases because they had not thought of them.
Certainly, this was an easy case, and an experienced language designer might have seen it coming without any tools, but in a language as complex as GPC (again, mainly due to the combination of dialects), conflicts are often surprising and in unexpected places, yet a parser generator like Bison detects them.
The lexer (generated by Flex) is a smaller issue, but I see no reason to switch from it either.
I will be happy to help out. If I'm starting with C code that needs to be translated into Pascal, then I will probably be able to get translations done with the minimum of help from you.
It would be more rewriting than translating, i.e. understand what the C code does (with the backend), and implement the same in Pascal (with a, say, C++ output). The big difficulty is to match the behaviour exactly (so the new GPC would be compatible with the exiting one), yet with a completely different target, with largely different internal structures (i.e., high-level structures instead of TREE_NODEs), and in a different language. That (combined with the size of the compiler) is not an easy task by any measure, obviously.
Frank