Some random notes. Mark Mitchell wrote:
> Personally, I'm not necessarily convinced that adding Pascal to > GCC is a good idea. I like Pascal just fine, but because every new > language adds to the load on everyone. (In my ideal world, we'd > have stable enough interfaces that it was easy to maintain front > ends separately from the rest of the compiler, but, though I've > been extolling that vision for years, I've made little progress in > realizing it...) I think I'd like the idea. Then the backend would be used almost like a library. Of course, I understand that the interface and dependencies will be bigger than of most other libraries, and changes between versions might also be more significant. And it will be versions beyond what gpc currently supports, so changes in gpc will be necessary anyway. But if it's a realistic plan (which I can't judge), it might be a useful long-term goal for gpc as well. (And I'm not too impatient about it.) One advantage I see of not integrating is to decouple release dates and feature sets -- in particular for frontends that are changing sigificantly WRT syntax and features, as gpc still is. (E.g., if a user wants to get the latest gpc features, but the latest backend version has some serious bug on his platform, now he can just use the previous backend version; with an integrated front-end this is no option, and he has to wait for a new backend release in order to use the existing frontend features. Of course, assuming a normal user who doesn't want to use a CVS snapshot, which may contain the bugfix earlier, for production work.) Ed Smith-Rowland wrote: > I, for one, am more likely to play with a gpascal that bootstraps > with mainline than to try to build one with, perhaps unusual, > dependencies and some different version of gcc. Except for the gcc version, the other dependencies will not necessarily change by integration (e.g., bison version). > My understandng is that gpc uses flex/bison in a p2c - a pascal to C > translator. I would like to know why folks think hand written > parsers are better. My guess is that they are easier to maintain > and that they support more lookahead. We don't use p2c. The gpc compiler is written in C, only the runtime support is (mostly) written in Pascal. The compiler uses flex and bison in C, as usual. Bison now supports GLR parsing which, effectively, allows for unbounded look-ahead. In our experience, the main advantages of a parser generator are (a) more readable grammar, (b) automatic computation of look-aheads, (c) when adding new syntax rules, one sees easier when they contain nonobvious conflicts. Currently bison works well for gpc, and I don't see a reason to rewrite a thing that works. Maybe other languages favour hand-written parsers, but Pascal doesn't AFAICT. Marcin Dalecki wrote: > If you have only USCDII in mind yes. But not if you look after any > of the usable, aka Delfi, implementation of it. You always have to > have runtime libraries. GPC already supports several standards and dialects and is quite usable (and used :-) already, and the runtime library exists. Neither UCSD nor Delphi are my favourite examples of useful dialects, BTW (sparing stronger words for reasons of good taste). But if you think of Delphi-like GUI class libraries and stuff like that (which some people are currently developing), I think they should remain separate projects anyway and not be part of gpc (whether or not gpc in turn will be integrated in gcc). > Hugh? I see the argument that another front-end will exercise more > of the back-end, since chances are that it will trigger code paths > in it which other languages don't use. > > However I can hardly see any Pascal language feature/construct, > which wouldn't be already covered by the C++ or Java ABI. How hard did you look actually? Andrew Pinski already mentioned non-local gotos and nested functions. In addition, there are things like SET_TYPEs (which AFAIK only Chill used besides Pascal), schema types (which are implemented not quite the same as C++ templates), subrange types, case (switch) ranges and perhaps some more. Anyway, experience has shown that gpc has already found some backend bugs. Some were fixed in gcc-3.4 thanks to Waldek Hebisch, some more are still on our list. I can't judge whether gpc integration does more good or bad from your POV in general, and as I wrote I have some reservations from my POV as well. But this one is not a valid point anyway. Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
