On 21 Nov 2002 at 10:39, Frank Heckenbach wrote:
[...]
Honestly, what craziness made them add such a feature?
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 your original assumption was closer to the truth, at least for versions after 3. Featuritis, combined with the need to compete with Windows orientated competitors. (still the windows dependance of the language is not that large though)
- 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 might explain some things. ;-)
But that is not true afaik, or better, not what is usually said.
It is commonly known that the commandline compiler itself is in C++, BUT nobody ever said it used to be something else. IOW it is written in it, but it could be a pascal compiler from scratch written in it.
The RAD + libraries itself is in Pascal though.
You have just opened a can of worms ;-). Yes, they have Borland C++ (which I don't think is being developed as a separate stand-alone product anymore). They also have Borland C++ Builder, which, although housing a standards-compliant C++ compiler, is also basically a C++- based Delphi (i.e., everything is the same with Delphi - except the language you use in coding your methods). Now the can of worms. Borland C++ Builder can compile Pascal code.
You mean what Borland likes to call Pascal ...
What 99% of the Pascal programmers calls Pascal ;-)
Compability is of little use in practice if it requires more changes than once every 100 lines. (and that is libraries + language)
(one can of course strive for a lesser version than the newest Delphi version at first)
I agree. This discussion does raise a fundamental question - should GPC aim for Delphi-compatibility at all?
Indeed, that's the main question.
Don't underestimate it. It'll probably require more changes than BP.
AFAIK FPC started with Delphi compability during 0.99.5 to 0.99.8 (August '98).
We are only now slowly getting close to compability. (and that is asymptotical)
But once we have these fixed reference points as a lowest common denominator and a convergence point for all Pascal implementations, then what next?
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.
Delphi adds exceptions (can of worms in its own right combined with your non-local goto's :-), OTOH you already have types that require initialisation/finalisation in a function, some might be generalisable.
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 ...). Most of them -- especially, of course, such syntantic additions like `()' that add nothing to the expressiveness of the language -- only look like feature bloat.
Interfaces are nice to have also.
Delphi is a moving target (and it is the only constantly evolving "standard")
I wonder if it's really evolving (for any definition of evolution that does not offend Darwin ;-), or if they're merely adding useless features desparately, just to get a justification for a new version.
Its never black or white, so it is both. But I think also legacy and backwards compability are slowly taking their toll after 7 versions.
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 ...
MS has owned a small percentage in Borland for a while, but sold it. There are some rumors that IBM might acquire Borland, (probably more for JBuilder than for Delphi). Another possibility is bankruptcy. How can they compete if the competitor can sponspor development tools and even the sales from their OS and Office suite sales?
and we might well decide to ignore it totally (either because it is too hard to keep up with, or because we don't like where it is going, or for any other reason). But if we don't ignore it completely, then what do we do? Supporting "()" is a small matter that doesn't add much to the GPC compiler, but it could become a real pain not to have it if we are to try and use free Delphi code that will increasingly make use of the feature.
BTW, does there exist a substantial amount of free Delphi code
The FPC compiler is Delphi compilable ;_)
(which is not Windows only)?
There is some, but it is rare, also a lot of Delphi source is not free. There is an awfull lot, but quite a lot is shareware.
But Windows-only code can be also be a boost. Do you have estimates what percentage windows users there are under GPC users? For FPC I guess it Windows is twice as much as Linux, and the rest is 10% combined, so win32: 60%, linux: 30%, rest: 10%.
Also one can take the core (e.g. server part based on sockets) of a windows application and try to clean it up. I did it a few times (for smaller progs), and it was significantly less than starting from scratch.
This figure hardly increases with the number of platforms we support, though Mac OS (X) might be an exception.
And it is not just Delphi. FPC supports Delphi dialect, VP supports Delphi dialect (though a bit, and VP is a bit silent lately), TMT supports Delphi, Pocket Studio supports Delphi dialect.
It is an un-Pascalish thing to support - but does this mean that we should ignore it, or treat it as a leprous extension that should be viewed with disdain? Perhaps - but there may well be other things that will be added to Delphi in the future that we might dislike even more. 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?
There are two reasons to implement that feature: - You want to be Delphi compabitle someday: implement it, even though you hate it. (If it really requires completely new subsystems or other really difficult (manyear) stuff, because it e.g. conflicts too much with some ISO parts, then you can let it be the exception to the rule) - You don't want Delphi compability, but it is a useful feature as a GPC specific extension on some of the supported dialects.
If you want to go for the Delphi compability, I'd start with trying to implement the major features of Delphi (interfaces, variants, ansistrings, classes, exceptions, dynamic arrays, overloading, default params, array of const), and see if they are doable.
Otherwise you might implement 250 of these parser and minor language details (like variable result for the return value of functions), and fail usable Delphi compability in the long run because of fundamental problems with some major feature.
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/) ...
Standard US corporate license nowadays. Don't like it either.