On 21 Nov 2002 at 21:55, Frank Heckenbach wrote:
[...]
Good question. It may well be that when the Delphi and C++ compilers started using the same backend, they decided to relax some of the restrictions on Pascal
As I said already on other occasions, syntax has nothing to do with the backend (code generation) -- unless they have a very confused architecture.
I think I used the wrong word. What I meant was the actual compiler, ("engine"?) not the code generator. Delphi (from version 2.0 onwards) and Borland C++/C++ Builder share the same compiler engine - at least, from what I have read (both from Borland and elsewhere).
- or perhaps it was just easier to let some C-
like features remain rather than to remove them from the Pascal side of things. I suspect the latter.
You mean their "Pascal" compiler (frontend) is not based on their previous "Pascal" compilers, but on the C compiler?
This is my understanding (at least from Delphi 2.0 onwards).
This might explain some things. ;-)
It certainly does ...
[...]
You mean what Borland likes to call Pascal ...
Yes. But there is still a decent and "proper" Pascal compiler lurking in there. Even with the latest version of Delphi (7.x), you can eschew all the graphical stuff completely, and do pretty straightforward procedural Pascal programming. Delphi will also still compile strictly- BP code (giving allowances for all the weird 16-bit relics that will be rejected). In fact, the class library that I am working on can be compiled with Delphi, GPC, FPC, and Virtual Pascal - and they are all equally happy with it.
[...]
I wouldn't exactly call the union of ISO 7185, 10206 and BP a "lowest common denominator". ISO and BP are far enough apart, so this covers quite a range of features, and maybe with one or another occasional extension it should be suitable for quite a wide range of applications.
Yes. But for a standards-compliant Pascal compiler, they should constitute a lowest common denominator (i.e., ideally, they should all be supported). If all popular Pascal compilers supported all 3, then we would be in source code portability nirvana. I could code to any one of them, and compile with whatever compiler generates the fastest code (or whatever) on every platform that I want to support.
Though I can imagine that the `class' model might be a little easier to use than `object's, I don't see the really big advantage in it yet, and much less so for most other Delphi features I've seen so far (well, exceptions perhaps ...).
I don't yet see the really big advantage in speaking Mandarin (but that is simply because I have never been to China - if I went there (rather than simply listen to what the Chinese tell me about Mandarin) I would suddenly see the big advantage ;-)).
[...]
Their architecture looks rather mixed-up and confused to me, so much that even MS's one might be cleaner, and I wouldn't be surprised if they get overtaken and kicked out by them soon ...
Perhaps. But I see the point from Borland's point of view. Have a single compiler engine, have a single class library, call then from two programming languages. Those who like Pascal should use Delphi, and those who swear by C/C++ should use C++ Builder.
[...]
BTW, does there exist a substantial amount of free Delphi code (which is not Windows only)?
Yes. A lot of code now supports Kylix and therefore has to be written "portably". There is also a lot of Windows code that can easily have the Windows-specific parts (often just the user interface) removed. If the code is well written, this separation is normally quite painless. The absence of Delphi classes is normally a bigger problem than separating the Windows stuff. But that problem can also be reduced significantly by having wrapper objects, and then changing all the calls to constructors.
So we still need (IMHO) to make a fundamental decision - is Delphi-compatibility worth striving for? If the answer is "yes", then I don't think that we can pick and choose which features we like to support. If the answer is "no", then we might as well stop adding any more Delphi- compatibility features.
Agreed. If anything, it would be stupid to ignore the easy features and try with the difficult ones, that's for sure. The `()' syntax is almost a non-issue I suppose, but do we want to imitate all strange features that appear (and will appear in the future) in other compilers?
If Delphi is doing it, and others are mimicking it (which they would have to in order to remain compatible) then "yes" we should do it too (as long as it will not take an inordinate amount of time/effort to implement it). If it is trivial to implement, then I can see no reason for not doing it.
It is of no consequence to me personally which way the decision goes, since I have Delphi and Kylix and I can use them if I want for Windows and Linux programming.
Sure, if you like your home and computers searched and that sort of things (http://freshmeat.net/articles/view/369/) ...
Fortunately, I have never been subjected to that kind of thing - nor do I anticipate such happening to a Great Chief like me ;)
[...]
Fortunately now Waldek has started to contribute code (especially for the gcc-3 port, and those changes affected large parts of the compiler). I don't know how hard it was and how long it took you to get enough overview of the internals, and if you feel ready yet to maintain any part or add features (or if you want to do that at all), but I admit it's a little difficult getting started. (Though I'm trying to simplify the internals wherever possible, so some things are now a little less difficult than they used to be, but it's a long way ...)
I assume that you are referring to Waldek here ...
So, when a feature is requested "for GPC", this is merely short-hand for saying "Frank, would you please do it?". Frank needs to have a life (and I am sure he does!)
I'm trying to, thanks. ;-)
You are welcome ;)
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/