Hi all
Newer versions of Delphi (IIRC, from v4.0 onwards) permit a somewhat C-like procedure/function call - e.g., if you have these routines: function foo : integer; procedure bar;
You can call them like this; i := foo; // GPC expects this bar; // -- ditto --
j := foo (); // Delphi accepts, but GPC doesn't bar(); // -- ditto --
I thing that it would be nice if GPC could support the addition of the brackets, but there may well be strong reasons for not doing so (for one, it is un-Pascalish). I also do not know whether it would be easy or difficult to implement. I fully appreciate that there are many other things that are far greater priorities - but if it could be done easily then should it? I find that many Delphi programmers are increasingly doing this (probably those who came from a C/C++ background) and so it gets a bit cumbersome to deal with them when trying to port free Delphi code to GPC.
Any comments?
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
On Monday 18 November 2002 11:17 am, Prof. A Olowofoyeku (The African Chief) wrote:
Hi all
Newer versions of Delphi (IIRC, from v4.0 onwards) permit a somewhat C-like procedure/function call - e.g., if you have these routines: function foo : integer; procedure bar;
You can call them like this; i := foo; // GPC expects this bar; // -- ditto --
j := foo (); // Delphi accepts, but GPC doesn't bar(); // -- ditto --
I thing that it would be nice if GPC could support the addition of the brackets, but there may well be strong reasons for not doing so (for one, it is un-Pascalish). I also do not know whether it would be easy or difficult to implement. I fully appreciate that there are many other things that are far greater priorities - but if it could be done easily then should it? I find that many Delphi programmers are increasingly doing this (probably those who came from a C/C++ background) and so it gets a bit cumbersome to deal with them when trying to port free Delphi code to GPC.
Any comments?
I personally don't like it that much :) However I agree that it maybe usefull for porting purposes.
Its probably pretty easy due to the fact that you can already pass varibles via parameter(? or is it value.... I forget my Pascal education :) ).
If it is added, perhaps a compile warning could be generated for each instance of the usage of the ()'s this would let people know that its not "real" Pascal.
Prof. A Olowofoyeku (The African Chief) wrote:
Newer versions of Delphi (IIRC, from v4.0 onwards) permit a somewhat C-like procedure/function call - e.g., if you have these routines: function foo : integer; procedure bar;
You can call them like this; i := foo; // GPC expects this bar; // -- ditto --
j := foo (); // Delphi accepts, but GPC doesn't bar(); // -- ditto --
I thing that it would be nice if GPC could support the addition of the brackets, but there may well be strong reasons for not doing so (for one, it is un-Pascalish). I also do not know whether it would be easy or difficult to implement. I fully appreciate that there are many other things that are far greater priorities - but if it could be done easily then should it? I find that many Delphi programmers are increasingly doing this (probably those who came from a C/C++ background) and so it gets a bit cumbersome to deal with them when trying to port free Delphi code to GPC.
<sarcasm> I think that's a very useful feature. It makes the language so much clearer and allows for many things that weren't possible otherwise. Now only one step is missing -- to finally call the language C with extensions ...
Oh yeah, and allow `{'/`}' for `begin'/`end'. The confusion with old-fashioned Pascal comments should be no problem since they have already C++ style comments.
I think that feature may be necessary for Delphi compatibility. But I start to wonder if we're the right project to do this. Maybe the GNU C developers should go for it, they're language seems to be much closer already. </sarcasm>
Honestly, what craziness made them add such a feature? If programmers come from C/C++ to a (slightly) Pascalish language, one might think they would at least want to learn the basics of the language. Otherwise, why don't they stay with C/C++? Even Borland has a C++ compiler, don't they?
Andrew McCall wrote:
I personally don't like it that much :) However I agree that it maybe usefull for porting purposes.
Its probably pretty easy due to the fact that you can already pass varibles via parameter(? or is it value.... I forget my Pascal education :) ).
You can pass values and variables as parameters. ;-)
If it is added, perhaps a compile warning could be generated for each instance of the usage of the ()'s this would let people know that its not "real" Pascal.
If it's added (and I'm really not sure about it), it should at least produce a fat warning by default and an error in any other dialect except `--delphi'.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
Actually, it doesn't. Such a message can be inserted by anyone, even by a virus. ;-) In order to have any meaning, it should at least contain a cryptographic signature.
Frank
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 - 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.
If programmers come from C/C++ to a (slightly) Pascalish language, one might think they would at least want to learn the basics of the language. Otherwise, why don't they stay with C/C++? Even Borland has a C++ compiler, don't they?
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. In fact, it uses the same Delphi VCL (written in Pascal of course) as its class library. So you can freely write Pascal units, etc., and use them in your C++ Builder code.
Should GPC support the "()" additions to functions/procedure calls? I think that for Delphi compatibility reasons alone it might be worth supporting (with all the usual warnings). I would argue that there should be no errors or warnings when using "--delphi" or "--gnu-pascal", but that there should be warnings or errors when using other dialects.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Hi!
On Thu, Nov 21, 2002 at 12:33:36PM -0000, Prof. A Olowofoyeku (The African Chief) wrote:
Should GPC support the "()" additions to functions/procedure calls? I think that for Delphi compatibility reasons alone it might be worth supporting (with all the usual warnings).
If Delphi(tm) is a conglomerate from C++, C, Pascal and much more, it seems, it is a kind of new language with its own syntax. The fact, that they support Pascal units as you pointed out is an interesting feature of this language, but nothing more. IMO, we should not support 'unpascalish' things in the GNU Pascal Compiler and concentrate on a superset of all _Pascal_dialects_. If someone would write a C-Compiler and call this 'Yet Another Pascal Compiler', the things would look much clearer.
Eike
(A reply to several mails, and a little rant ... ;-)
Prof. A Olowofoyeku (The African Chief) wrote:
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.
- 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. ;-)
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 ...
On 21 Nov 2002 at 15:39, Marco van de Voort wrote:
[...]
IMHO it is no use to support a subset of a dialect (e.g. Delphi), and not at least strive to go all the way in the long run.
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.
BP is a closed target, and therefore BP compatibility alone might not lead us anywhere except to provide a fixed point of reference - the same goes for ISO 7185 and ISO 10206. They are all not going any other place anytime soon.
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.
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.
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. I don't know Delphi myself, but what I've seen recently sounds more like the latter ...
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 ...
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 (which is not Windows only)?
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?
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/) ...
As long as it doesn't interfere with "normal" Pascal, I don't see what the issue is, other than the effort to add it - which would be the effort of someone who wants the compatibility....
This is where the "but" comes in. AFAIK, Peter is the only one who really knows all the deep internals of the compiler. Frank is the next most knowledgeable person, but might still require Peter's assistance on occasion. Other people know a bit about this or that, but, realistically (at present) only Peter and Frank have the knowledge to maintain any part of the compiler.
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 ...)
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. ;-)
Frank
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.
Marco van de Voort wrote:
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)
I didn't claim that. AFAIK, only some small language elements are Windows oriented. But most existing code written for Delphi is probably quite Windows oriented.
Borland C++ Builder can compile Pascal code.
You mean what Borland likes to call Pascal ...
What 99% of the Pascal programmers calls Pascal ;-)
No. Maybe 99% of Borland (and FPC, ...) users, but most of them are not Pascal programmers since these compilers don't support the Pascal language.
Wirth has created a language and called it Pascal. That's his right. Later this language has been formally specified in the first Pascal stnadard. Others have created various modifications to the language. That's also their right. But calling these modifications also Pascal (unless they're a superset of the Pascal language) is not their right. What would you think if, say, someonse writes a compiler, calls it FPC, happens to get more popularity than your FPC and then claims his compiler is *the* FPC?
(Note that I'm not talking about extensions, but omissions from the Pascal language.)
Delphi adds exceptions (can of worms in its own right combined with your non-local goto's :-),
Uhm, you mean Pascal's non-local gotos. :-)
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?
Yes, I suppose it will make more sense for MS to drive them into bankruptcy than buying them out ...
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%.
This might be true, but I'm not exactly interested in supporting non-free and non-portable software. The only possible reason for supporting Delphi compatibility I can imagine is to allow programmers make their Delphi programs available for other systems. But if the Windows specific code is too hard to replace (or people don't want to do this), that's pointless.
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.
Please explain to me how this feature is useful, i.e., you can do anything with it that you can't do (easily) without?
Otherwise you might implement 250 of these parser and minor language details (like variable result for the return value of functions),
Do you mean result variables (function foo = bar: baz)? They're actually standard (EP), and GPC has had them for a long time ...
Frank
Marco van de Voort wrote:
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)
I didn't claim that. AFAIK, only some small language elements are Windows oriented. But most existing code written for Delphi is probably quite Windows oriented.
Most is yes. But its publically available codebase is slowly getting larger than even TPs, and more important, a lot more advanced (XML processors, complete scripting languages etc) A few percents or ten percent maybe (if you take e.g. server only parts under IFDEF) that is reusable even make quite a large intersting base.
Borland C++ Builder can compile Pascal code.
You mean what Borland likes to call Pascal ...
What 99% of the Pascal programmers calls Pascal ;-)
No. Maybe 99% of Borland (and FPC, ...) users, but most of them are not Pascal programmers since these compilers don't support the Pascal language.
---- I've had enough of this. If you want to carry on a silly Jihad against Borland, then go on.
I've had more than my portion of this in the years I tried to approach GPC sensibly, and on common base instead of differences, and about implementing Pascal compilers and runtime libraries in general. I even recommended GPC in c.l.p.b for certain cases.
I will be unsubscribing from this list this week, because I realise that one can't create a dialogue with fanatics. Or at least I can't bear the nonsense for so little merit. And I've quite a thick skin, which was hardened by Modula2 ISO fanatics.
BTW Actually we tried to get a ISO (7xxx) mode project running for FPC, just for compabilities sake, though we didn't want to spent too much core workers time on it.... Nobody was interested. One of the c.p.l.ansi-iso regulars (can't remember who) was interested, but we never heard from him again. ----
[more ISO bible blabla skipped, resuming on some non or less propaganda stuff]
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%.
This might be true, but I'm not exactly interested in supporting non-free and non-portable software.
I joined FPC when I was a DOS programmer, and couldn't get GPC compiled. Now I do the FPC unix RTL.
Waiting for people to come to your ivory tower won't work. Even RMS realises that.
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.
Please explain to me how this feature is useful, i.e., you can do anything with it that you can't do (easily) without?
I'd say this a typical parser thing. Read the sentence below. Mainly the "THESE parser and minor language details" part.
Personally I think you shouldn't start with Delphi compability at all until the compability with all currently supported dialects is roughly finished (I use quite a lot of qualified identifiers as a result of my Modula-2 period)
But I would start to try to make up my mind together with the people also putting time and effort into GPC in which direction the project will move: Delphi, yes/no/partial. And if partial, what features would be an option, and if full in what order do we implement them.
Simply because if you envision to implement them, and you work on spots now, you can make small preparations, and think about designs etc.
Otherwise you might implement 250 of these parser and minor language details (like variable result for the return value of functions),
Do you mean result variables (function foo = bar: baz)? They're actually standard (EP), and GPC has had them for a long time ...
No. That sounds like a thing that VB would have btw, but maybe the latest version of Delphi has it. They also copy from VB which is even worse than from C++ IMHO ;-)
Some things from memory, if you want a lot of stuff, try to run the publically available FPC testsuite with GPC, or just study it.
- functionresults can also be returned in pseudo local var "result" - "var" for initialised constants. (so VAR bla : sometype = value;) - In general Delphi allows a lot of small differences (places where a comma is optional etc) - resourcestring keyword.
______________
BYE!
_______________
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.
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/
Prof A Olowofoyeku (The African Chief) wrote:
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).
I don't know what "engine" means in this context -- I can still only imagine the code generator and similar things.
[...]
You mean what Borland likes to call Pascal ...
Yes. But there is still a decent and "proper" Pascal compiler lurking in there.
Sorry, but Borland never had a proper Pascal compiler.
[...]
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).
For a standards-compilant compiler, the BP dialect is irrelevant.
If all popular Pascal compilers supported all 3, then we would be in source code portability nirvana.
Indeed. However, I don't know of too many other compilers that do ...
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 ;-)).
So where's the land where the `()' feature is useful? ;-)
But seriously, human language have developed over a long time and "just exist", and they're there for all kinds of communcations. Computer languages are designed and for specific purposes, so the analogy doesn't really hold.
Besides, it's not about a languages, but rather a language element. If a make up a new "English" word, I wouldn't see any advantage in using it ...
[...]
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.
That would be ok -- that's roughly what GNU does as well: Have a single backend (if I may equate this with engine), have many libraries (sure, not a single one, since there's not this MS-ish uniformity) which can be called from many languages.
But why on earth do they mix the languages together? That's not necessary for this model to work.
Those who like Pascal should use Delphi, and those who swear by C/C++ should use C++ Builder.
Exactly, so C/C++ features are not required in Delphi.
[...]
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".
OK, so it's not all Windows only, but portable? I thought Kylix also only supported the x86 processors, doesn't it?
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 ...
Yes -- it's difficult to use the right pronoun here (oh, maybe I should invent a new word ;-) since he's probably also reading it ...
Frank
On 22 Nov 2002 at 02:45, Frank Heckenbach wrote:
[...]
Sorry, but Borland never had a proper Pascal compiler.
A matter of opinion and perspective. If not for Borland Pascal, I would not be a "Pascal" programmer today. I think that Borland's versions of "Pascal" did much to give the language critical mass outside the classroom. Whether it is really "Pascal" or not is a debate that reminds me of old law school debates about whether "International law" is really "law" - everybody had his opinion, and no-one's opinion ever changed.
[...]
For a standards-compilant compiler, the BP dialect is irrelevant.
Except that it is a de facto standard, and it has the highest critical mass of all "Pascal" "standards" - that makes it relevant if one wants to attract many users.
If all popular Pascal compilers supported all 3, then we would be in source code portability nirvana.
Indeed. However, I don't know of too many other compilers that do
True. That is why I describe GPC as "the mother of all Pascal compilers" on my web page.
[...]
So where's the land where the `()' feature is useful? ;-)
Bor-land (pun intended ;))
But seriously, human language have developed over a long time and "just exist", and they're there for all kinds of communcations. Computer languages are designed and for specific purposes, so the analogy doesn't really hold.
It does insofar as it articulates the idea that it is difficult to see the advantage in anything that one has not experienced for oneself. As we say here in Anglia, "the taste of the pudding is in the eating". How can one really explain how wonderful a piece of cake is to someone who has never eaten a cake before?
Besides, it's not about a languages, but rather a language element. If a make up a new "English" word, I wouldn't see any advantage in using it ...
So why did the persons who invented the word "compiler" or "computer" or any other new English word bother to do so? And if they never did it, how would we describe today what I am now typing on, or the software that you and Peter work so hard to maintain?
[...]
That would be ok -- that's roughly what GNU does as well: Have a single backend (if I may equate this with engine), have many libraries (sure, not a single one, since there's not this MS-ish uniformity) which can be called from many languages.
But why on earth do they mix the languages together? That's not necessary for this model to work.
If you want to have a single VCL and RAD tool, written in Pascal, and you don't want to reinvent it again and again for your C++ compiler, you have no option but to allow C++ to compile Pascal. But why would they allow C-ish stuff into Delphi/Pascal? On that one, your guess is as good as mine! It is not necessary at all, so one can only speculate.
Those who like Pascal should use Delphi, and those who swear by C/C++ should use C++ Builder.
Exactly, so C/C++ features are not required in Delphi.
Nope. I don't even think that they are necessarily always helpful. It is weird.
[...]
Yes. A lot of code now supports Kylix and therefore has to be written "portably".
OK, so it's not all Windows only, but portable?
From one OS to the other, yes - if you code to the CLX instead of VCL
for the user interface. The actual Pascal code itself does not need to be platform specific at all. And the CLX is a cross-platform alternative to the VCL. If you use anything that is platform-specific, you get tons of warnings (if you turn warnings on). No-one needs to code in an unportable manner anymore - and sensible programmers are changing their attitudes.
I thought Kylix also only supported the x86 processors, doesn't it?
You are correct. That is not to say that other processors will not be supported if there is "sufficient demand" - read "don't hold your breath".
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
A matter of opinion and perspective. If not for Borland Pascal, I would not be a "Pascal" programmer today. I think that Borland's versions of "Pascal" did much to give the language critical mass outside the classroom. Whether it is really "Pascal" or not is a debate that reminds me of old law school debates about whether "International law" is really "law" - everybody had his opinion, and no-one's opinion ever changed.
That's quite a difference. "Law" is a word from common language and has developed in cultures etc. "Pascal", OTOH, (in this context) is the name that Wirth gave to a language he designed, therefore it's a well defined term, not subject to opinions. (The language was later revised in the standard, but it only made some clarifications and did not really deviate from the original language. The later standard is called "Extended Pascal" -- rightfully, since it's strictly an extension and includes the previous version completely.)
To say it again, I think it's quite impertinent to create a mutilated form of the language and claim that the result is the real language. It's quite unfortunate that in this society, apparently Wirth would have had to get a trademark and sue Borland to prevent such an abuse. But to be fair, I'm not sure if Borland actually made this claim (though many users do, mostly out of ignorance I guess). It may be that Borland only talked about the "Turbo Pascal" and "Borland Pascal" languages or similar, which may be acceptable and could be read as describing a dialect (but still bears the confusion to be understood as the Pascal language by Borland).
[ About the usefulness of `()' ]
So why did the persons who invented the word "compiler" or "computer" or any other new English word bother to do so? And if they never did it, how would we describe today what I am now typing on, or the software that you and Peter work so hard to maintain?
So these words have a meaning, as you describe. I still haven't seen any practical usefulness of the `()' feature. I don't think we have to travel to foreign (Bor-)lands to see the usefulness, if there is any. Apparently, this feature has been supported in Delphi for some time, so there must be some examples what it's good for (except the laziness of former C/C++ programmers to learn and save to keystrokes).
[...]
That would be ok -- that's roughly what GNU does as well: Have a single backend (if I may equate this with engine), have many libraries (sure, not a single one, since there's not this MS-ish uniformity) which can be called from many languages.
But why on earth do they mix the languages together? That's not necessary for this model to work.
If you want to have a single VCL and RAD tool, written in Pascal, and you don't want to reinvent it again and again for your C++ compiler, you have no option but to allow C++ to compile Pascal.
Yes, you have. Simply allow C++ to access Pascal routines (same as most Pascal compilers can call routines written in other languages). There's no need for the C++ compiler to compile the Pascal code.
Waldek Hebisch wrote:
I think the rational reason is overloading: if one wants methods and atributes to share a name, then the syntax must distingush between variables and parameterless functions.
What are attributes? Object fields, or properties?
Anyway, I have a hard time seeing an advantage of function overloading already (i.e., the slight convenience of naming "everything" the same minus the added confusion, especially when debugging), but overloading the same name for routines and variables??? What's next? Overloading types and labels? Or constants and reserved words? Redefine the `[' and `]' "operators"? ;-)
Prof A Olowofoyeku (The African Chief) wrote:
Not very far. Delphi has things like function and method overloading, commenting with "//", and things like "foo()". Delphi has "variants" (compatible with virtually any type), and things like "Array of Const" parameters. But I am not sure whether these were borrowed from C++ or not.
C++ has `//' comments and overloading (that doesn't necessarily mean they were invented there, I don't know that exactly), C/C++ have function calls with `()'. C/C++ has `void *' parameters which are like BP's untyped parameters, but I suppose variants are not quite the same. And C/C++ surely has something like `array of const', but with a more sane syntax -- sure, C's syntax for structured types is a little strange, but once you've understood the rules, it's quite logical in itself; I can't say that of `array of const' -- `array of' is normally followed by a type denoter in Pascal, but here they put the word `const' instead.
I seem to see a pattern in the last two examples. Apparently, a common pattern is to macerate the syntax more and more. Of course, it already started in BP. E.g., the untyped parameters -- we can argue about their usefulness (semantically), but syntactically at least a pseudo-type like `Void' (cf. C) would have been much cleaner than just omitting the type (and creating a new syntax just for that special case). Or the ridiculous "typed constants" (syntactially) instead of initialized variables (which they are semantically). Not to mention `absolute' variables as well as the `Mem' and `Port' arrays (which map features of the processor architecture, the segment/offset addressing and the assembler I/O instructions, into the language syntax). `interrupt' procedures and the BP `asm' syntax(*) (especially for whole routines) are not much better, either. Oh yeah, and the infamous `^A' syntax for character constants ... -- Oh well, was it already that bad in BP -- I almost had forgotten it until I started to collect this list ...
(*) Admitted, GPC also extends the syntax for `asm'. But at least the machine instructions and register names are put into string constants, so it's possible to parse it without knowing the details of the target architecture.
And apparently they're happily continuing this trend. I can't help but think that sooner or later that language will just collapse under its own weight. (OK, what does collapse mean here? Creating inconsistencies and ambiguities in itself? Well, BP has done that long time ago. I guess in such a commercial-proprietary setting it will mean they either go bankrupt or they drop the product because they can't maintain it anymore.)
I sometimes hear the argument that good programmers don't use the whole mess of misfeatures, but only a "sane" subset of the language -- I hope that's true. If it is, maybe we should focus on supporting such a sane subset, and if nobody else does, we might even have to define that subset first. That might imply that we should not support features like `()' and other misfeatures (in contradiction to what I said yesterday) -- not because `()' would be difficult to implement, but because for all I know it has no real use and just adds unnecessary complexity.
One of the features of the original Pascal was a very clean syntax -- unfortunately the language was too limited for many purposes. Extended Pascal went a long way to remedy the latter while keeping the language mostly as clean and systematic. The (draft standard) object extensions (which actually seem close to Delphi's model) seem to follow in this spirit. But for many other extensions, I fail to see big advantages, but I often see substantial disadvantages (often in the syntax).
Frank
On 23 Nov 2002 at 1:46, Frank Heckenbach wrote:
[...]
That's quite a difference. "Law" is a word from common language and has developed in cultures etc. "Pascal", OTOH, (in this context) is the name that Wirth gave to a language he designed, therefore it's a well defined term, not subject to opinions. (The language was later revised in the standard, but it only made some clarifications and did not really deviate from the original language. The later standard is called "Extended Pascal" -- rightfully, since it's strictly an extension and includes the previous version completely.)
To say it again, I think it's quite impertinent to create a mutilated form of the language and claim that the result is the real language.
I don't think that Borland ever claimed that their Pascal was "the" Pascal.
It's quite unfortunate that in this society, apparently Wirth would have had to get a trademark and sue Borland to prevent such an abuse. But to be fair, I'm not sure if Borland actually made this claim (though many users do, mostly out of ignorance I guess). It may be that Borland only talked about the "Turbo Pascal" and "Borland Pascal" languages or similar, which may be acceptable and could be read as describing a dialect (but still bears the confusion to be understood as the Pascal language by Borland).
Is the following code "Pascal" or not?
program foo (input, output); type bar = record bar1 : integer; bar2 : char; end; type mybar = (here, there, where); Var b1 : mybar; b2 : bar; begin with b2 do begin bar1 := 10; bar2 := 'C'; {do whatever} end; end.
All versions of Delphi and BP compile it. If they do, then they are "Pascal" compilers. Is this phrase Spanish? "Me gustaria tomar flan". Yes, it is. Of course it isn't all the Spanish that exists, but no-one can say that it is not Spanish because it doesn't contain subjunctives or the whole of the Spanish vocabulary. Is my Spanish any less Spanish because it is not perfect or complete? I doubt it. Else many people on this list will not be taken as writing "English". BP and Delphi do not support everything in Wirth's language - and they contain extensions that are not in Wirth. Does that make them "not Pascal"? IMHO, no. "How do you do?" is English - incomplete as it is. Therefore I conclude that BP and Delphi are "Pascal", albeit incomplete implementations with extensions.
[ About the usefulness of `()' ]
So why did the persons who invented the word "compiler" or "computer" or any other new English word bother to do so? And if they never did it, how would we describe today what I am now typing on, or the software that you and Peter work so hard to maintain?
So these words have a meaning, as you describe. I still haven't seen any practical usefulness of the `()' feature.
It is not obvious to me either - but Waldek may have unearthed the rationale for it in his earlier post. It is increasingly being used though - and by Borland's own developers. Many of the units that come with Delphi now use it (albeit mainly the newer ones).
[...]
If you want to have a single VCL and RAD tool, written in Pascal, and you don't want to reinvent it again and again for your C++ compiler, you have no option but to allow C++ to compile Pascal.
Yes, you have. Simply allow C++ to access Pascal routines (same as most Pascal compilers can call routines written in other languages). There's no need for the C++ compiler to compile the Pascal code.
There is a need if you do not want to restrict your C++ users to precompiled Pascal libraries. What if they want to change something in the VCL (or 3rd party) sources, to fix a bug, or for whatever other reason? This would be impossible if they couldn't then recompile the sources.
[...]
C++ has `//' comments and overloading (that doesn't necessarily mean they were invented there, I don't know that exactly), C/C++ have function calls with `()'. C/C++ has `void *' parameters which are like BP's untyped parameters, but I suppose variants are not quite the same. And C/C++ surely has something like `array of const', but with a more sane syntax -- sure, C's syntax for structured types is a little strange, but once you've understood the rules, it's quite logical in itself; I can't say that of `array of const' -- `array of' is normally followed by a type denoter in Pascal, but here they put the word `const' instead.
Yes, it is a bit silly. I guess the closest thing to it that I can think of is varargs in C. This is their way of supporting variable numbers (and types) of parameters. It is controversial whether that should ever be supported. But once you decide to support it, you are already extending the language - and I guess it's then up to you how you do it.
[...]
And apparently they're happily continuing this trend. I can't help but think that sooner or later that language will just collapse under its own weight.
I doubt it. Sometimes these extensions are simply a matter sharing features that already exist (and should exist) in a "sister" product. I would imagine that, if anything needs to go, it would be the excess baggage of backward compatibility
[...]
I sometimes hear the argument that good programmers don't use the whole mess of misfeatures, but only a "sane" subset of the language -- I hope that's true.
People who were already experienced Pascal/Delphi programmers just tend to stick to their own style of coding. New programmers (or newcomers to Delphi from other languages) tend to use all features indiscriminately. On the other hand, if you want to take advantage of variable numbers of arguments, you don't have much choice. The alternative is to write many different routines - and some people prefer this route.
If it is, maybe we should focus on supporting such a sane subset, and if nobody else does, we might even have to define that subset first. That might imply that we should not support features like `()' and other misfeatures (in contradiction to what I said yesterday) -- not because `()' would be difficult to implement, but because for all I know it has no real use and just adds unnecessary complexity.
Supporting a sane subset IMHO is no different from Borland's opiginal decision to implement only a subset (which I am sure they considered as "sane") of "Pascal". It would be half-baked, controversial, and not very useful for its intended purpose (facilitating the porting of Delphi code to GPC, or heling Delphi programmers in their transition to GPC). I think that GPC should either support all that it can when there is time to do it, or that Delphi support should just be dropped. In any case, things like qualified identifiers (to complete BP support) and "smart linking" seem to be greater priorities than patchy Delphi support.
One of the features of the original Pascal was a very clean syntax -- unfortunately the language was too limited for many purposes. Extended Pascal went a long way to remedy the latter while keeping the language mostly as clean and systematic. The (draft standard) object extensions (which actually seem close to Delphi's model) seem to follow in this spirit. But for many other extensions, I fail to see big advantages, but I often see substantial disadvantages (often in the syntax).
I am not sure that there is a consensus on that point (or that there can be). Delphi code seems very clear and eminently readable to me (and no doubt to many others). The extensions do not make the code any less clear or readable to me. Even if I don't see the point of them, people don't normally add pointless features to their software, even if others can't see what that point is. In the event, each developer has his own point of view, and very often, debates on points of view (read "preferences") are often inconclusive (which is why it often takes the producers of ANSI/ISO standards for ever to decide anything). Since you are maintaining the compiler, I guess you should just implement whatever you feel happy with. If others want more, then they can do it themselves!
As Marco said in another post, full Delphi support may well turn out to be a very hard nut to crack, and, given the philosophy behind GPC, perhaps we should leave that nut to the FPC people and concentrate on BP and the official "standards".
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
To say it again, I think it's quite impertinent to create a mutilated form of the language and claim that the result is the real language.
I don't think that Borland ever claimed that their Pascal was "the" Pascal.
As I said in the part you deleted, "I'm not sure if Borland actually made this claim". So maybe only (many of) their users are to blame (including myself, some years ago).
Is the following code "Pascal" or not?
program foo (input, output); type bar = record bar1 : integer; bar2 : char; end; type mybar = (here, there, where); Var b1 : mybar; b2 : bar; begin with b2 do begin bar1 := 10; bar2 := 'C'; {do whatever} end; end.
(Actually, it isn't according to ISO 7185, since there must be only one type declaration part, but it's easy to resolve, of course. And it's allowed in EP.)
All versions of Delphi and BP compile it. If they do, then they are "Pascal" compilers.
Is the following code C or not? All versions of Bourne compatible shells can run it and produce the expected output. If they do, then they are C compilers (or maybe C interpreters). ;-)
#include <stdio.h> #define echo int main () { printf ( #define exit "\n"); return 0; } echo "Hello, world!" exit
(Hint: The code is both valid C and sh syntax, using some tricks. ;-)
Is this phrase Spanish? "Me gustaria tomar flan". Yes, it is. Of course it isn't all the Spanish that exists, but no-one can say that it is not Spanish because it doesn't contain subjunctives or the whole of the Spanish vocabulary.
Your analogy has (at least) two flaws. First, the difference between natural and formal languages that I've already mentioned. Secondly, the difference between one example and whole language. The fact that BP and Delphi can compile some valid Pascal programs does not mean that they're a complete Pascal compilers (as the humorous example above hopefully shows; likewise, I wouldn't claim that I speak Spanish if I understood that sentence).
Actually, the standard makes quite details provisions what a conforming compiler ("processor") must and may do. Nobody denies that BP fails to satisfy some of the requirements.
: This International Standard specifies the semantics and syntax of : the computer programming language Pascal by specifying requirements : for a processor and for a conforming program.
So, again, you can compile some conforming programs, but BP is not a conforming "processor". (BTW, GPC isn't either, but we do acknowledge the deviations as bugs and don't try to talk them away.)
Therefore I conclude that BP and Delphi are "Pascal", albeit incomplete implementations with extensions.
I might agree to this. However, it's a very wide description. For sufficiently large values of incomplete and sufficiently many extensions, every C compiler is an incomplete implementation of Pascal with extensions. ;-)
If you want to have a single VCL and RAD tool, written in Pascal, and you don't want to reinvent it again and again for your C++ compiler, you have no option but to allow C++ to compile Pascal.
Yes, you have. Simply allow C++ to access Pascal routines (same as most Pascal compilers can call routines written in other languages). There's no need for the C++ compiler to compile the Pascal code.
There is a need if you do not want to restrict your C++ users to precompiled Pascal libraries. What if they want to change something in the VCL (or 3rd party) sources, to fix a bug, or for whatever other reason? This would be impossible if they couldn't then recompile the sources.
Then Borland should simply ship the Pascal compiler together with the C++ compiler. (That might be a question of licensing, but if the current C++ compiler can compile Pascal, every user of that compiler effectively has a Pascal compiler now, so it wouldn't make much of a difference.) I still hold that it's not necessary to mix the languages for any such reason. (And again, that's quite exactly what GNU does, so I think I have some experience in this area ...)
BTW, interesting that you bring up this point in this context. What if the users want to fix a bug in the compiler? Does Borland supply the source code of the compiler then?
Yes, it is a bit silly. I guess the closest thing to it that I can think of is varargs in C. This is their way of supporting variable numbers (and types) of parameters. It is controversial whether that should ever be supported. But once you decide to support it, you are already extending the language - and I guess it's then up to you how you do it.
Anything they do in their compiler is up to them, but we may still discuss whether or not it's done well. Extending the syntax is always a rather heavy "cost" and should be well justified, especially when there's an easy alternative available. In this case the alternative would be a protected (EP) or const (BP), conformant (SP) or open (BP) array of `Void'. So the only thing new would be a `Void' type, but that's merely a new predefined identifier (which, of course, should be redefinable, so it won't disturbe anyone who doesn't want to use it in this meaning, and would allow parsing even when one doesn't know what it means), and maybe some predefined routines to work with the `Void' type (inquire the real type and retrieve the values etc.) i.e.
protected array [a .. b: Integer] of Void { EP }
or
const array of Void { BP }
I am not sure that there is a consensus on that point (or that there can be). Delphi code seems very clear and eminently readable to me (and no doubt to many others). The extensions do not make the code any less clear or readable to me.
Honestly, I'm quite tired of hearing these general and unspecific claims. Why don't you present some actual code which is clearer or better understandable due to these controversial features like overloading, `()' etc.? (I mean real understandability -- it might be easier at first sight to read some code where "everything" is called, say, `Read' -- one will think, oh yeah, that's reading something, very clear. But if you really want to understand what's going on, you'll have to figure out which routine/method is called in which case, and I don't see how overloading will help there. Making the easy things easier and the difficult things more difficult doesn't seem like a good strategy on the whole.)
Even if I don't see the point of them, people don't normally add pointless features to their software, even if others can't see what that point is.
I could say a lot about this, but it would really get off-topic ...
Frank
On 23 Nov 2002 at 17:17, Frank Heckenbach wrote:
[...]
I don't think that Borland ever claimed that their Pascal was "the" Pascal.
As I said in the part you deleted, "I'm not sure if Borland actually made this claim".
Yes, my mistake.
[...]
Is the following code C or not? All versions of Bourne compatible shells can run it and produce the expected output. If they do, then they are C compilers (or maybe C interpreters). ;-)
#include <stdio.h> #define echo int main () { printf ( #define exit "\n"); return 0; } echo "Hello, world!" exit
Just betrays the C origins of the Bourne and similar shells. The logical conclusion is that "sh" can act as a C interpreter, and if it compiles the code, then it is not very different from a C compiler or a subset thereof.
[...]
Therefore I conclude that BP and Delphi are "Pascal", albeit incomplete implementations with extensions.
I might agree to this. However, it's a very wide description. For sufficiently large values of incomplete and sufficiently many extensions, every C compiler is an incomplete implementation of Pascal with extensions. ;-)
When a C compiler can compile correctly the simple Pascal program that I used as an example, then I will consider it an incomplete implementation of Pascal.
[...]
There is a need if you do not want to restrict your C++ users to precompiled Pascal libraries. What if they want to change something in the VCL (or 3rd party) sources, to fix a bug, or for whatever other reason? This would be impossible if they couldn't then recompile the sources.
Then Borland should simply ship the Pascal compiler together with the C++ compiler.
That is what "sort of" happens. There are binaries that the C++ compiler interacts with which are little more than emasculated versions of some Delphi binaries.
(That might be a question of licensing, but if the current C++ compiler can compile Pascal, every user of that compiler effectively has a Pascal compiler now, so it wouldn't make much of a difference.)
I haven't tried to produce .exes with the emasculated versions of Delphi binaries, but I suspect that it wouldn't work, and that you can only compile units with them. So they are not of much use other than to produce .DCUs for the C++ compiler to use.
I still hold that it's not necessary to mix the languages for any such reason. (And again, that's quite exactly what GNU does, so I think I have some experience in this area ...)
BTW, interesting that you bring up this point in this context. What if the users want to fix a bug in the compiler? Does Borland supply the source code of the compiler then?
Nope. Why would they? They supply the sources to the VCL and RTL if you have the "professional" or "enterprise" versions. But if you want to fix bugs in the compiler you just have to report and then wait until service packs are released (and hope they got round to fixing "your" bug).
Yes, it is a bit silly. I guess the closest thing to it that I can think of is varargs in C. This is their way of supporting variable numbers (and types) of parameters. It is controversial whether that should ever be supported. But once you decide to support it, you are already extending the language - and I guess it's then up to you how you do it.
Anything they do in their compiler is up to them, but we may still >discuss whether or not it's done well.
Of course.
[...]
I am not sure that there is a consensus on that point (or that there can be). Delphi code seems very clear and eminently readable to me (and no doubt to many others). The extensions do not make the code any less clear or readable to me.
Honestly, I'm quite tired of hearing these general and unspecific claims.
Nothing general or unspecific about that I said! I merely articulated my experience when examining source code.
Why don't you present some actual code which is clearer or better understandable due to these controversial features like overloading, `()' etc.?
I never said that it was clearer or better understandable. I said "The extensions do not make the code any less clear or readable to me".
"i := foo();" is just as clear and readable to me as "i := foo;"
Some might say that it is more readable (I express no opinion on that point - but Waldek indirectly alluded to this) because, in the former, it is clear that "foo()" is a function/method - but in the latter, "foo" might be a variable/field, or a function/method.
(I mean real understandability -- it might be easier at first sight to read some code where "everything" is called, say, `Read' -- one will think, oh yeah, that's reading something, very clear. But if you really want to understand what's going on, you'll have to figure out which routine/method is called in which case, and I don't see how overloading will help there.
I can. If you have:
Procedure Read (x:string);overload; Procedure Read (x, y:integer);overload; Procedure Read (x:string; y:integer; z:Double);overload;
It would be quite obvious which of these is being called, when the parameters passed are examined.
"Read (14, 32);" cannot be calling anything other than the second "Read".
This is arguably less clear than:
Procedure Read1 (x:string); Procedure Read2 (x, y:integer); Procedure Read3 (x:string; y:integer; z:Double);
"Read2 (14, 32);"
But I am not confused or mystified by either model, and both are equally accessible and understandable to me, and if I am debugging, I cannot see that one model makes which routine is actually being called less or more clear to me than the other. Whether or not one is "better" than another is a matter for the individual programmer's taste and philosophy. We can debate these things until kingdom come - but anything that we say for or against either model will only be rehashing well worn arguments in the programming world.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
Is the following code C or not? All versions of Bourne compatible shells can run it and produce the expected output. If they do, then they are C compilers (or maybe C interpreters). ;-)
#include <stdio.h> #define echo int main () { printf ( #define exit "\n"); return 0; } echo "Hello, world!" exit
Just betrays the C origins of the Bourne and similar shells.
Actually, it doesn't. Though they have some similarities, I didn't make use of them here. The trick is that a leading `#' is a comment in sh, but a preprocessor directive in C, so I could define some macros etc. which contain most of the C code, which is simply ignored by sh.
I hope these explanations make the example clearer. It does not reveal any substantial similarity of sh and C. I didn't manage to produce a file that would be both valid Pascal and C, but that's just "coincidence". Even if I would, that wouldn't mean anything, in particular it would not prove that every Pascal compiler is a limited C compiler and vice versa.
Single programs don't mean anything. That's why the standard doesn't list a few hundred example programs and says, a compiler which compiles those is a confirming Pascal compiler. Instead, it describes the syntax and semantics very explicitly and detailed (though not always very clearly WRT to the language used ;-).
(That might be a question of licensing, but if the current C++ compiler can compile Pascal, every user of that compiler effectively has a Pascal compiler now, so it wouldn't make much of a difference.)
I haven't tried to produce .exes with the emasculated versions of Delphi binaries, but I suspect that it wouldn't work, and that you can only compile units with them. So they are not of much use other than to produce .DCUs for the C++ compiler to use.
OK, so I conclude (again ;-) that the actual C++ compiler does not have to compile Pascal code.
BTW, interesting that you bring up this point in this context. What if the users want to fix a bug in the compiler? Does Borland supply the source code of the compiler then?
Nope. Why would they?
Of course, I didn't expect otherwise. But since you made a point that programmers should be able to fix bugs in the VCL -- if they're just a little less lucky, the bug is in the compiler, and they can't fix it, either. So this argument is rather weak.
[...]
I am not sure that there is a consensus on that point (or that there can be). Delphi code seems very clear and eminently readable to me (and no doubt to many others). The extensions do not make the code any less clear or readable to me.
Honestly, I'm quite tired of hearing these general and unspecific claims.
Nothing general or unspecific about that I said! I merely articulated my experience when examining source code.
Sorry, but just saying "my experience is so" is general and unspecific. I can believe you or not, but there's nothing in the statement that enables me to decide for myself whether it's true, or whether any existing feature might be suitable just as well (or even better).
Why don't you present some actual code which is clearer or better understandable due to these controversial features like overloading, `()' etc.?
I never said that it was clearer or better understandable. I said "The extensions do not make the code any less clear or readable to me".
"i := foo();" is just as clear and readable to me as "i := foo;"
"Just as clear" doesn't exactly justify messing with the syntax. It should be substantially clearer/powerful/readable/...
Some might say that it is more readable (I express no opinion on that point - but Waldek indirectly alluded to this) because, in the former, it is clear that "foo()" is a function/method - but in the latter, "foo" might be a variable/field, or a function/method.
That might be a point, but this difference has already been blurred by properties AFAIUI.
(I mean real understandability -- it might be easier at first sight to read some code where "everything" is called, say, `Read' -- one will think, oh yeah, that's reading something, very clear. But if you really want to understand what's going on, you'll have to figure out which routine/method is called in which case, and I don't see how overloading will help there.
I can. If you have:
Procedure Read (x:string);overload; Procedure Read (x, y:integer);overload; Procedure Read (x:string; y:integer; z:Double);overload;
It would be quite obvious which of these is being called, when the parameters passed are examined.
That's a rather easy example. It gets more confusing if you have the same number of arguments, but different types.
Frank
[various stuff]
This has been an interesting debate, but I fail to see the point of prolonging it. What has been raised is a fundamental question about whether and to what extent GPC should aim for Delphi compatibility. On that question the silence of other members of this list has been deafening. I can only assume that this is because no-one else is interested in Delphi compatibility. If so, then it renders any debate moot. If not, then it would be good to hear what others think.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
On Sun, Nov 24, 2002 at 08:18:22AM -0000, Prof A Olowofoyeku (The African Chief) wrote:
This has been an interesting debate, but I fail to see the point of prolonging it. What has been raised is a fundamental question about whether and to what extent GPC should aim for Delphi compatibility. On that question the silence of other members of this list has been deafening. I can only assume that this is because no-one else is interested in Delphi compatibility. If so, then it renders any debate moot. If not, then it would be good to hear what others think.
I will not prolong the debate, but just give my opinion.
Personally, I am not particularly interested in Delphi compatibility. I find it more important to have a good (standard) Pascal compiler available under Solaris, Linux, Mac OS, ...
Tom
Tom Verhoeff wrote:
I will not prolong the debate, but just give my opinion.
Personally, I am not particularly interested in Delphi compatibility. I find it more important to have a good (standard) Pascal compiler available under Solaris, Linux, Mac OS, ...
I quite agree.
Adriaan van Os adriaan@microbizz.nl
In article 3DE08B4E.31948.298775@localhost, "Prof A Olowofoyeku (The African Chief)" chiefsoft@bigfoot.com writes
On that question the silence of other members of this list has been deafening. I can only assume that this is because no-one else is interested in Delphi compatibility. If so, then it renders any debate moot. If not, then it would be good to hear what others think.
This is free software. The people doing the work are free to do whatever they want. Personally I have been happy with Frank's priorities. I'd much sooner he spent his time working on the compiler than engage in endless debates on this list. For the record, Delphi compatibility would be of some minor interest to us.
Hi folks,
Prof A Olowofoyeku (The African Chief) wrote:
This has been an interesting debate, but I fail to see the point of prolonging it. What has been raised is a fundamental question about whether and to what extent GPC should aim for Delphi compatibility. On that question the silence of other members of this list has been deafening. I can only assume that this is because no-one else is interested in Delphi compatibility. If so, then it renders any debate moot. If not, then it would be good to hear what others think.
I think, a verbatim Delphi compatibility of GPC is _not_ a good idea, especially regarding its tendency to C resemblance, which was the trigger of this thread. In my experience, the Delphi tendence of imitating C leads to nothing but making Delphi a _less_ powerful language. (E.g. the Delphi _styleguide_ -- not even the compiler itself -- tells you to put every class definition into a file of its own, thus yielding lots of cross-reference errors whenever two classes have to know each other. A "true Delphi developer" will rather implement dozens of f*cking workarounds than break with this C-style rule.) Adding procedure calls with empty parameters lists would increase confusion in GPC without enhancing its abilities.
Delphi compatibility of GPC should be restricted to the effort to provide all mechanisms Delphi is capable of, but not necessarily with the same syntax. E.g. there should be an exception handling mechanism with try..except..finally clauses, but they needn't exactly look like their equivalent in Delphi. (Remark: Sorry, Frank, I still haven't had the time to look the mechanism up in the GCC backend.) Since we already have parameterless procedures, we need no second mechanism for the same use.
Yours,
Markus
Markus Gerwinski wrote:
I think, a verbatim Delphi compatibility of GPC is _not_ a good idea, especially regarding its tendency to C resemblance, which was the trigger of this thread. In my experience, the Delphi tendence of imitating C leads to nothing but making Delphi a _less_ powerful language. (E.g. the Delphi _styleguide_ -- not even the compiler itself -- tells you to put every class definition into a file of its own, thus yielding lots of cross-reference errors whenever two classes have to know each other. A "true Delphi developer" will rather implement dozens of f*cking workarounds than break with this C-style rule.)
Really? I'd rather forbid external declarations of things defined in other Pascal source files as well as circular unit references (no people, don't worry, I won't do it, I just say I'd rather ;-) than to encourage them.
Delphi compatibility of GPC should be restricted to the effort to provide all mechanisms Delphi is capable of, but not necessarily with the same syntax. E.g. there should be an exception handling mechanism with try..except..finally clauses, but they needn't exactly look like their equivalent in Delphi.
I agree that we should have EH sometime, and as long as there are no problems (such as ambiguities, inconsistencies, ugliness ;-), other compatibility requirements), we should probably use the same syntax.
I'm more concerned about those features that add no new capabilities, but just more syntactical variations or unnecessary complexity ...
Prof. A Olowofoyeku (The African Chief) wrote:
On 24 Nov 2002, 13:02:36 Martin Liddle wrote:
This is free software. The people doing the work are free to do whatever they want.
That is merely to state the obvious - but it is a sad day when this is considered an appropriate response to a question about whether and to what extent a certain feature should be added to GNU software. I didn't think that GNU was about the dictatorship of the maintainers. I doubt that Frank himself would consider the statement: "I do the work, so I can do anything I please" to be sound reasoning or an appropriate response.
I've discussed some planned changes here, and I plan to continue so. However, I find it disappointing when sometimes discussions about the actual (de-)merits of a feature are stifled in favour of "[my favourite compiler] does it so and so" or "the standard doesn't have it".
I personally want a language that is powerful and easy to use (in my taste, of course ;-). The standards go a long way to that aim, but they don't cover everything (especially in lower-level areas), and make some things more complicated than necessary. The same goes for other dialects, except that the areas are different (low-level usually covered better, but higher-level often worse) and the percentage of good vs. bad features might vary ...
My consequence is neither to ignore the standards, nor to restrict myself to them (or any other given dialect), but to support the standards, but also better (IMHO) alternatives, and to use the latter in my Pascal programs, so they remain clear and portable etc. (which is, in the end, my main goal).
So when I implement some compatibility features (including some dubious standard features like "mixed comments"), I do so only for completeness and will likely never use them myself. Therefore, obviously, my motivation is not as high as with more important (IMHO) features, especially if they are difficult to implement or cause more problems (such as syntax ambiguities). Of course, I won't stop anyone from doing it themselves (if they find ways to solve the problems and/or invest the necessary effort) ...
Besides, when implementing a new feature, there's often a choice of doing it well and efficiently, or just to barely satisfy the compatiblity requirements with an easy implementation, or whether to add a warning that the feature is stupid and should be used only for backwards-compatiblity etc. We've done such things, especially with some BP features (added warnings, put them in the System unit, etc.). Sometimes a discussion about a feature can also give me an idea about how to judge it in these regards (e.g., someone might come up with an application that makes a feature look really useful which I wasn't aware of).
Personally I have been happy with Frank's priorities.
So have I - and so have (one must assume) most people on this list. That does not dispense with the need sometimes to discuss (and agree or disagree on) important issues. If an issue is important to one person, then it is important and discussion thereon should not be stifled because it irritates, bores, or disinterests others.
I agree, but I also apply this to discussions about more general issues such as how to value a certain dialect (Delphi in this case) in general. If noone else is interested in this question, fine, but I don't want to be forbidden to even question Borland's eternal wisdom. ;-)
For the record, Delphi compatibility would be of some minor interest to us.
This is what I was asking about. And this is the response that answers that question. It is clear that there is little desire here for Delphi compatibility. So be it. At least we now have a clear idea on how people feel about it (presumably those who are silent are not interested). So we can forget about Delphi compatibility, and life can go on. Frank, you're now officially "off the hook", and you can concentrate your efforts on features that people do want ;-).
I guess this also signals doom for my "Delphi compatibility" units, which can perhaps quietly disappear. This is not necessarily a bad thing, because I have long been dubious as to whether anyone other than me is using them. I still intend of course to continue to develop them for my own purposes, so those who are interested in them will be able to get updates.
This is no big surprise to me, as those who (think they) need Delphi compatibility urgently are probably using other compilers now. I suppose it will require a rather big one-time effort to get it started to a partly usable state. Then others might get interested, and it can slowly improve.
I think that's also how BP support started. Peter needed it (at that time, around 1995) for his projects, so he made the effort and implemented some of the most important things in one go. Later, when they were tested and improved some more, others (like me) joined and helped with the "fine-tuning".
For Delphi, I currently don't see anyone with the necessary motivation to do the initial step. (Neither me -- I don't really have the motivation because I probably won't use much of it myself, also there are a number of other things I rather do instead that will probably be more useful, I think.) Of course, this may change at any time, so a decision not to implement something now, is not a final decision to do it never.
Frank
On 12 Dec 2002 at 5:41, Frank Heckenbach wrote:
Markus Gerwinski wrote:
I think, a verbatim Delphi compatibility of GPC is _not_ a good idea, especially regarding its tendency to C resemblance, which was the trigger of this thread. In my experience, the Delphi tendence of imitating C leads to nothing but making Delphi a _less_ powerful language. (E.g. the Delphi _styleguide_ -- not even the compiler itself -- tells you to put every class definition into a file of its own, thus yielding lots of cross-reference errors whenever two classes have to know each other. A "true Delphi developer" will rather implement dozens of f*cking workarounds than break with this C-style rule.)
Really? I'd rather forbid external declarations of things defined in other Pascal source files as well as circular unit references (no people, don't worry, I won't do it, I just say I'd rather ;-) than to encourage them.
I would have to say that I have never encountered the problem that is being described here, and I have never had to implement any "#@5$" workaround to avoid it. In my experience, class definitions are normally put in their own separate units only when they are visually designed decendants of "TForm" (as opposed to ones created and destroyed by code).
[...]
For Delphi, I currently don't see anyone with the necessary motivation to do the initial step.
I do. I just don't have the C programming skills to do it - and of course, the sources to the compiler itself are like Mandarin to me ;)
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Le Samedi 23 Novembre 2002 17:17, Frank Heckenbach a écrit :
There is a need if you do not want to restrict your C++ users to precompiled Pascal libraries. What if they want to change something in the VCL (or 3rd party) sources, to fix a bug, or for whatever other reason? This would be impossible if they couldn't then recompile the sources.
Then Borland should simply ship the Pascal compiler together with the C++ compiler. (That might be a question of licensing, but if the current C++ compiler can compile Pascal, every user of that compiler effectively has a Pascal compiler now, so it wouldn't make much of a difference.) I still hold that it's not necessary to mix the languages for any such reason. (And again, that's quite exactly what GNU does, so I think I have some experience in this area ...)
BTW, interesting that you bring up this point in this context. What if the users want to fix a bug in the compiler? Does Borland supply the source code of the compiler then?
In past times, Borland did supply the source code of the runtime library and the main units on request, for a symbolic price (but not the source of the compiler itself) . Borland has been sold three or for times since then, so it is not surprising that their policy is not the same now.
Frank Heckenbach wrote:
... snip ...
C++ has `//' comments and overloading (that doesn't necessarily mean they were invented there, I don't know that exactly), C/C++ have function calls with `()'. C/C++ has `void *' parameters which are like BP's untyped parameters, but I suppose variants are not quite
The C "void *" has a very specific meaning. It is a generic pointer, and is non-derefenceable. It can always be converted into a typed pointer, and that conversion is only meaningful for the original type. i.e. you cannot convert a pointer to an array of char to a void* and expect to convert that to a pointer to an integer.
Since Pascal does not have the wild abandonment of C pointer construction and usage, the only equivalent is the NIL pointer.
Much confusion arises from such usage as "void **", which denotes a pointer to a generic pointer, and can thus be dereferenced.
The less said about // the better.
CBFalconer wrote:
Frank Heckenbach wrote:
... snip ...
C++ has `//' comments and overloading (that doesn't necessarily mean they were invented there, I don't know that exactly), C/C++ have function calls with `()'. C/C++ has `void *' parameters which are like BP's untyped parameters, but I suppose variants are not quite
The C "void *" has a very specific meaning. It is a generic pointer, and is non-derefenceable. It can always be converted into a typed pointer, and that conversion is only meaningful for the original type. i.e. you cannot convert a pointer to an array of char to a void* and expect to convert that to a pointer to an integer.
Since Pascal does not have the wild abandonment of C pointer construction and usage, the only equivalent is the NIL pointer.
Well, I didn't talk about Pascal, but Borland Pascal. ;-) (I suppose Marco has unsubscribed by now, so we can save another flamewar. ;-)
BP's untyped parameters are indeed like C's `void *'. They can be converted to something else which is meaningful for the original type, or when you know exactly the internal memory layout. BP programs regularly do such things (there are other ways to get into such trouble in BP, while in SP/EP you only get there by misusing variant records) which is one reason why many of them are so hard to port.
The less said about // the better.
Agreed.
Frank
GNU C developers should go for it, they're language seems to be much closer already.
</sarcasm>
Honestly, what craziness made them add such a feature? If programmers come from C/C++ to a (slightly) Pascalish language, one might think they would at least want to learn the basics of the language. Otherwise, why don't they stay with C/C++? Even Borland has a C++ compiler, don't they?
IMHO it is no use to support a subset of a dialect (e.g. Delphi), and not at least strive to go all the way in the long run.
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)
On 21 Nov 2002 at 15:39, Marco van de Voort wrote:
[...]
IMHO it is no use to support a subset of a dialect (e.g. Delphi), and not at least strive to go all the way in the long run.
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? BP is a closed target, and therefore BP compatibility alone might not lead us anywhere except to provide a fixed point of reference - the same goes for ISO 7185 and ISO 10206. They are all not going any other place anytime soon.
But once we have these fixed reference points as a lowest common denominator and a convergence point for all Pascal implementations, then what next? Everybody (GPC included) adds this or that to their implementation that, if used, breaks compatibility with other compilers. This is fine, as long as people can opt to code to one of the fixed reference points (ISO BP (ha! ;), ISO 7185 and ISO 10206).
Delphi is a moving target (and it is the only constantly evolving "standard") 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. 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.
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. So, from my "sitting on the fence" position, I can say, like Marco, that half-hearted support is not of much use. Anything worth doing at all is worth doing well. So we should either do it well (in the course of time and when time permits) or we should just drop it.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
On Thursday 21 November 2002 3:16 pm, Prof. A Olowofoyeku (The African Chief) wrote:
On 21 Nov 2002 at 15:39, Marco van de Voort wrote:
[...]
IMHO it is no use to support a subset of a dialect (e.g. Delphi), and not at least strive to go all the way in the long run.
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? BP is a closed target, and therefore BP compatibility alone might not lead us anywhere except to provide a fixed point of reference - the same goes for ISO 7185 and ISO 10206. They are all not going any other place anytime soon.
Is there anyway that you could introduce compatibility for users that want it by using a compatibility library or compiler switch?
Its a simple logic really :
The people who don't want compatibility won't use it so won't care if compatibility is there or not.
The people who *do* want it won't be happy if compatibility isn't there.
Thus, you might as well add compatibility, but get someone who *wants* it to maintain it. Then everyone is happy, and GPC gets a wider audience.
As long as it doesn't interfere with "normal" Pascal, I don't see what the issue is, other than the effort to add it - which would be the effort of someone who wants the compatibility....
On 21 Nov 2002 at 15:54, Andrew McCall wrote:
[...]
Is there anyway that you could introduce compatibility for users that want it by using a compatibility library or compiler switch?
Switches such as "--borland-pascal" and "--delphi" do just that.
Its a simple logic really :
The people who don't want compatibility won't use it so won't care if compatibility is there or not.
Again, this describes the status quo. There are people on this list who don't care much for Borland's extensions, or indeed for any thing other than the ISO standards.
The people who *do* want it won't be happy if compatibility isn't there.
No they won't - but they might well have to live with it, if the consensus is that a particular extension should not be supported (or more likely, if Frank or Peter (who are very busy people) do not have the time to do it).
Thus, you might as well add compatibility, but get someone who *wants* it to maintain it. Then everyone is happy, and GPC gets a wider audience.
Good in principle - but ...
As long as it doesn't interfere with "normal" Pascal, I don't see what the issue is, other than the effort to add it - which would be the effort of someone who wants the compatibility....
This is where the "but" comes in. AFAIK, Peter is the only one who really knows all the deep internals of the compiler. Frank is the next most knowledgeable person, but might still require Peter's assistance on occasion. Other people know a bit about this or that, but, realistically (at present) only Peter and Frank have the knowledge to maintain any part of the compiler. Leave it to someone like me, and you will have a dead compiler ;-). I have lots of ideas (don't we all !) but not the knowledge or skill to implement them. Ideally, we will have umpteen people with the C-programming skills and the knowledge of the internals of the compiler to spread the load around - but we currently don't.
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!) so he can't do everything that everyone wants, even if he wanted to. I am afraid that, until sufficient numbers of us get the requisite C programming skills and sufficient knowledge of the compiler, it will not be feasible to "get someone who *wants* it maintain it".
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Frank Heckenbach wrote (about foo() syntax):
Honestly, what craziness made them add such a feature? If programmers come from C/C++ to a (slightly) Pascalish language, one might think they would at least want to learn the basics of the language. Otherwise, why don't they stay with C/C++? Even Borland has a C++ compiler, don't they?
I think the rational reason is overloading: if one wants methods and atributes to share a name, then the syntax must distingush between variables and parameterless functions. Few days ago I was thinking about C++ compatibility -- to call methods of C++ objects one needs to have compatible overloading and inheritance model, and that includes distinction between variables and functions (alternatively one have to do massive renaming). I do not know how far Delphi moved in such direction, but at the moment the main reason that dominat languages stay popular are libraries and legacy code. So, the ability to use C++ libraries may be (is?) big plus for Delphi. Personally, I think that GPC should try to be superset of Delphi, however debatable features should be switchable (between on, warning and off) independently -- so that even in Delphi mode one should be able to exclude them.
On 22 Nov 2002 at 21:46, Waldek Hebisch wrote:
Frank Heckenbach wrote (about foo() syntax):
[...]
I think the rational reason is overloading: if one wants methods and atributes to share a name, then the syntax must distingush between variables and parameterless functions. Few days ago I was thinking about C++ compatibility -- to call methods of C++ objects one needs to have compatible overloading and inheritance model, and that includes distinction between variables and functions (alternatively one have to do massive renaming). I do not know how far Delphi moved in such direction,
Not very far. Delphi has things like function and method overloading, commenting with "//", and things like "foo()". Delphi has "variants" (compatible with virtually any type), and things like "Array of Const" parameters. But I am not sure whether these were borrowed from C++ or not.
but at the moment the main reason that dominat languages stay popular are libraries and legacy code. So, the ability to use C++ libraries may be (is?) big plus for Delphi.
Delphi cannot (yet) use C++ libraries - but C++ Builder can use Delphi (i.e., Pascal) units.
Personally, I think that GPC should try to be superset of Delphi, however debatable features should be switchable (between on, warning and off) independently -- so that even in Delphi mode one should be able to exclude them.
That would be nice. But I think we are probably a long way from realising that. I think that GPC is very thinly spread. We are a "broad church" and comprise so many interests. Not all those interests are necessarily always compatible with each other. This slows things down (compared to a single church (e.g., just 7185 or 10206 or BP)) but is inevitable if we are to keep our broad church - and I think that we must keep it. Eventually we will get there - as more of us become more proficient in C, and/or acquire increased knowledge of the compiler.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
-
Adriaan van Os -
Andrew McCall -
CBFalconer -
Eike Lange -
Frank Heckenbach -
Jean-Pierre Vial -
marcov＠stack.nl -
Markus Gerwinski -
Martin Liddle -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)
-
Tom Verhoeff -
Waldek Hebisch