Thanks for your replies so far. Here are some comments as a summary reply to several of your mails, in no particular order.
Kevan Hashemi wrote:
But if the compiler is written in Pascal, and compiles itself, I will be very happy to start trying to host the development of GPC myself, using some sort of version control code like GIT.
plus I have static IP addresses for hosting the code. At the very least, I could maintain the existing versions.
Thanks for the offer, but unfortunately that's not my main concern. Our server (where the web site is currently hosted) has static IP addresses and more than enough free bandwidth, and we could probably set up git easily (or even go to Sourceforge etc. if this was advantageous), but I'm afraid infrastructure will not write a program. (I'm a burned child here -- with several previous initiatives, including documentation, translation, libraries, and setting up a CVS, there was always much interest in creating the infrastructure (or at least in discussing the infrastructure), but once this was done (or not done), not much actual work happened.)
I usually work on MacOS, so I could cover the interface with the MacOS operating system. We would need other people to work on the interface with the other operating systems.
Also I'm afraid to say that this isn't one of my main concerns. We have runtime libraries, and as I listed under "Reusable parts", they could probably more or less be kept. The actual problem is really the compiler proper.
When it comes to debugging, I am always able to get by with writeln statements and looking at the console on Linux or MacOS. On Windows GPC has no particular place to write to, so I have more trouble there. But I place the debugger as a low-priority item.
Of course, I've also done much writeln-debugging with GPC (for lack of alternatives) and sometimes recently also in C++ (out of habit ;-), but honestly, having a real debugger (gdb with C++) available is quite helpful sometimes, especially to find more complex bugs. For me, it's at least medium priority.
Thus, I see no need for Pascal to provide more than its existing rudimentary interface with the local operating system (although the Windows version should be brought up to the level of the others).
I also have the need for an extended OS interface (though obviously not Windows, but Unix), but again, that's not my main concern. If that was all, I'd probably write it within a few days and be done.
If the GPC compiler were written in GPC, I could work on fixing bugs. I would be happy to write or maintain the code that implements the mathematical run-time library (sin, cos, etc.). I understand that the self-compiling compiler requires a complete re-write.
Actually, GPC's runtime library is already written in Pascal for the most part (i.e., except for the direct libc interface), so that's just the area that would require the least amount of work.
Felipe Monteiro de Carvalho wrote:
One suggestion: Why not implement a syntax mode in Free Pascal which is compatible with the current GPC syntax?
That would merge both projects and avoid such trouble.
If there is no volunteer to do this work, but someone interrested in it's conclusion has some money (at least 200 eur for the doing the gross initial work, more later for the fine tuning), I could try to find an implementor for it in the context of the Lazarus Season of Code: http://wiki.freepascal.org/Lazarus_Season_of_Code
I'm skeptical given what I heard from FPC advocates WRT standard Pascal etc. before. Not wanting to rehash old and less than pleasant discussions, all I'll say WRT my participation in any project with FPC is: Not interested.
Of course, if you'd like to do this, go ahead -- and good luck!
John L. Ries wrote:
I find it interesting that when I was a young CS major back in the 1980s, I somewhat resented Pascal's status as the "official religion" in my university's CS department, but as a professional programmer, my appreciation for the way it encourages good programming practices has increased by leaps and bounds. At the same time, my attitude toward C has gone from infatuation to active dislike.
Again, I'd prefer to leave out C (which I'd suggest to noone as an alternative for Pascal), and talk about C++ instead which is indeed quite a bit more high-level (though it carries all the ballast from C, but unfortunately so does GPC, often disguised as BP extensions).
Of course, I have gathered most of my programming experience in Pascal and applied it in C++ later, and I don't know how my habits would have developed if I had started in C++.
That said, I agree in principle with the proposal to rewrite GPC in Pascal, though if it can be made easy to keep the existing GPC in sync with the GCC back end, it would free up time for the core developers to work on the rewrite.
Unfortunately, that's just the main problem here. As I wrote, I figure it would take several weeks just to "fix" gpc with gcc-4.1, after Waldek spent months porting it to gcc-4 in the first place. Then additional effort is required to port it to the current gcc, test and fix it, and by then probably new gcc versions will have appeared, possibly with major changes.
And I'm talking about full-time development here. I may have a few weeks available now, but then I'll have to concentrate more on other projects again and only have occasional time for Pascal. The same goes for Waldek. And for new developers, even if there were some, it would take some time to get used to the backend to become able to do any productive work.
So, sorry, I just don't see a way to get, let alone keep, GPC in sync with the backend. I had hoped so when I started, but since then the distance has probably even increased, despite the extensive efforts of Peter, Waldek and me.
I'm not sure how much language extension is required,
"Required" is, of course, subjective here. I tried to explain why something like templates are important to me (and adding templates in the langauge is very much non-trivial), or in other words a way to write a structure (such as a list, hash table or tree) that can be applied to *any* type.
but Pascal greatly suffers from a lack of bindings to widely used libraries, including and especially GUI toolkits. I know there is a tool to facilitate creation of Pascal bindings to C/C++ libraries, but it's not (as far as I can see) distributed with GPC, or mentioned on the GPC website. I don't really understand why the existing GPC couldn't be used to boostrap a new compiler written entirely in Pascal, but perhaps Frank could elaborate on why his suggested C++ converter is preferable as an interim step.
Perhaps I was unclear, but I didn't mean it as an interim step, but as the actual target for the alternative development (i.e., getting away from the backend). An advantage WRT your point would be that the generated C++ code could include the C/C++ headers directly, so interfacing would become easier (though not completely trivial, as I explained in my article).
Scott Moore wrote:
Although a rewrite of GPC in Pascal is interesting, I don't think it would help. It is a huge undertaking, and it still would not result in an all-Pascal project, since it must integrate with the GCC backend.
See my previous paragraph. My point of the rewrite would be that it would *not* integrate with the gcc backend, but output C++ code (which would then probably be compiled with g++ using the gcc backend, but we're not involved with that then).
Prof Abimbola Olowofoyeku (The African Chief) wrote:
My one concern would be about producing yet another Pascal object model that is not compatible with any of the existing ones. But I guess that, if the old BP model is still supported so that existing code would compile, that would be fine.
That's kind of what I half expected and half feared. If I'm the only one to want a new (or at least extended) object model (in particular WRT enforced constructors and automatic destructors) or other features (such as templates), there's no point implementing them.
Adriaan van Os wrote:
The devil is in the details. For me, a compiler is a professional tool and the quality of the tool is more important than new features. A handful of weak points may become serious deployment obstacles.
Current GPC problems:
- wrong line numbers in debug code
- wrong and/or incomplete debug-symbol info, notably for 64-bit code
- order-2 performance of unit symbol loading
- order-2 performance of operator overloading symbols
http://www2.gnu-pascal.de/crystal/gpc/en/mail12897.html 5. stalled GCC back-end development/integration (a show stopper when the target OS requires a recent GCC)
I am not complaining or opposing new features. I am saying that a future path for GPC must tackle these and similar problems. Questions must be answered. Does (5) imply moving away from the low-level GCC back-end ? What are the alternatives ?
As I wrote, the only way I could see WRT (5) as far as I'm concerned would be moving away from the backend, and my alternative would be to output C++. This could also help solving (1) (when being careful about emitting line breaks and/or inserting "#line" directives), and partly (2) (the debug info should at least be useable, but as I noted, in particular types would, at least initially, be in C++ notation).
For (3) and (4) it wouldn't help, but if the new compiler was written in a high-level language (i.e., C++ or its own new Pascal dialect) using high-level data structures (e.g., template based), it would make it easier to tackle those problems.
- producing C/C++/Objective-C. What about the debugging experience ? What about GDB maintenance ?
Debugging plain C++ works well with gdb, even multi-threaded programs. I think at least for the mainstream languages (C and C++) gdb is currently well maintained.
Debugging Pascal translated to C++ would, of course, be inferior, see above, but still it would be a huge step forward from the current state of affairs.
- producing LLVM assembly http://llvm.org/docs/LangRef.html
That might be an option. However, the problems I see are (a) I'm not familiar with LLVM assembly (in contrast to C++), and I'm not sure anyone else here is, so it would take additional learning before one could get productive, and (b) it's, of course, low-level, so we'd have to reimplement things like the object-model, templates, exceptions etc., that C++ already has.
- LLVM integration http://llvm.org/docs/tutorial/ (also a moving target with a moving C++ API)
As you can imagine, I've become skeptical of moving targets.
Frank