Frank Heckenbach wrote:
Markus Gerwinski wrote:
compiling the program
Program Test;
var x: integer;
Function foo: integer;
Procedure bar; begin (* bar *) result:= 7; end (* bar *);
begin (* foo *) bar; end (* foo *);
begin x:= foo; end.
yields an error message
test.pas: In procedure `bar': test.pas:14: error: invalid access to `Result' test.pas: In function `foo': test.pas:20: error: result of function not assigned
Bug or feature?
An interesting case indeed. Since `Result' is a Delphi feature, we probably should check if Delphi allows this, and if so do so as well.
I just tested with Delphi and found that `Result' behaves exactly like an implicitly defined local variable here. I.e. the sub-function of a function has its own `Result' that shadows the one of the enclosing function. A sub-procedure correctly accesses the `Result' of the enclosing function.
Notice, though, that if it does, it's somewhat confusing (if both `foo' and `bar' are functions, one implicit `Result' probably shadows the other -- please try this case with Delphi as well), and error-prone (in your example, if you later decide to make `bar' a function with an integer type result, the code would silently change its meaning).
Indeed. That is another advantage of the explicitly declared result variable. (At least if you, like me, prefer to avoid using the function name as a write-only identifier.)
Frank, is there any chance to change gpc's behaviour back to the way I started this thread with? I know it would violate a standard, but in this case I think the standard makes less sense than the "unwanted feature" we had before.
Yours,
Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
Markus Gerwinski wrote:
Bug or feature?
An interesting case indeed. Since `Result' is a Delphi feature, we probably should check if Delphi allows this, and if so do so as well.
I just tested with Delphi and found that `Result' behaves exactly like an implicitly defined local variable here. I.e. the sub-function of a function has its own `Result' that shadows the one of the enclosing function. A sub-procedure correctly accesses the `Result' of the enclosing function.
Notice, though, that if it does, it's somewhat confusing (if both `foo' and `bar' are functions, one implicit `Result' probably shadows the other -- please try this case with Delphi as well), and error-prone (in your example, if you later decide to make `bar' a function with an integer type result, the code would silently change its meaning).
Indeed. That is another advantage of the explicitly declared result variable. (At least if you, like me, prefer to avoid using the function name as a write-only identifier.)
Frank, is there any chance to change gpc's behaviour back to the way I started this thread with? I know it would violate a standard, but in this case I think the standard makes less sense than the "unwanted feature" we had before.
I agree with Frank that "Result" should behave as in Delphi and it does consistently behave there the way it was designed to, although the example shows that the whole idea of an "unnamed" Result identifier is in itself a poorly designed language feature. Obviously, not much thought went into it.
Still - what about adding a warning when "Result" is referenced in the subprocedure (or sub-subprocedure) of a function ?
Regards,
Adriaan van Os
Notice, though, that if it does, it's somewhat confusing (if both `foo' and `bar' are functions, one implicit `Result' probably shadows the other -- please try this case with Delphi as well), and error-prone (in your example, if you later decide to make `bar' a function with an integer type result, the code would silently change its meaning).
I agree with Frank that "Result" should behave as in Delphi and it does consistently behave there the way it was designed to, although the example shows that the whole idea of an "unnamed" Result identifier is in itself a poorly designed language feature. Obviously, not much thought went into it.
Still - what about adding a warning when "Result" is referenced in the subprocedure (or sub-subprocedure) of a function ?
Actually, pretty much the same consequences happen in normal Pascal - it is a general consequence of shadowing. For example:
var F: Integer;
procedure Proc; function F: Integer; begin F := 5; end; begin end;
If you change the name of the function, with no other changes, the program will still compile but will likely not be doing what you want. And in this case, it is about as devious as the implicit Result variable, as the F variable definition could be arbitrarily far from the function.
Shadowing is a helpful feature, but it is not without its risks as far as robust programming goes.
Peter N Lewis wrote:
Notice, though, that if it does, it's somewhat confusing (if both `foo' and `bar' are functions, one implicit `Result' probably shadows the other -- please try this case with Delphi as well), and error-prone (in your example, if you later decide to make `bar' a function with an integer type result, the code would silently change its meaning).
Actually, pretty much the same consequences happen in normal Pascal - it is a general consequence of shadowing. For example:
var F: Integer;
procedure Proc; function F: Integer; begin F := 5; end; begin end;
If you change the name of the function, with no other changes, the program will still compile but will likely not be doing what you want.
Sure, with renaming this can always happen. My point was that with `Result' it can also happen without renaming or introducing any new declaration, just by changing a procedure to a function (*without* an explicit result variable). Anyway, we'll have to live with it.
Frank
Adriaan van Os wrote:
Markus Gerwinski wrote:
Bug or feature?
An interesting case indeed. Since `Result' is a Delphi feature, we probably should check if Delphi allows this, and if so do so as well.
I just tested with Delphi and found that `Result' behaves exactly like an implicitly defined local variable here. I.e. the sub-function of a function has its own `Result' that shadows the one of the enclosing function. A sub-procedure correctly accesses the `Result' of the enclosing function.
Notice, though, that if it does, it's somewhat confusing (if both `foo' and `bar' are functions, one implicit `Result' probably shadows the other -- please try this case with Delphi as well), and error-prone (in your example, if you later decide to make `bar' a function with an integer type result, the code would silently change its meaning).
Indeed. That is another advantage of the explicitly declared result variable. (At least if you, like me, prefer to avoid using the function name as a write-only identifier.)
Frank, is there any chance to change gpc's behaviour back to the way I started this thread with? I know it would violate a standard, but in this case I think the standard makes less sense than the "unwanted feature" we had before.
I agree with Frank that "Result" should behave as in Delphi and it does consistently behave there the way it was designed to, although the example shows that the whole idea of an "unnamed" Result identifier is in itself a poorly designed language feature. Obviously, not much thought went into it.
Indeed! I found out it's much worse than I thought ...
Consider the following program:
program Foo;
var Result: Integer;
function f: Integer; begin f := 1; Result := 2 end;
begin Result := 3; WriteLn (f, ' ', Result) end.
In any dialect that doesn't have a built-in `Result' (e.g. EP and even BP!), the assignment goes to the global `Result' variable, so the program writes `1 2'. (This is what GPC currently does, as well as BP.)
With Delphi, it assigns to the function result, however. So I guess it writes `2 3', does it?
So, apparently, `Result' is not just another predefined identifier of a dialect like so many others. Because it's not defined at the outermost scope, but implicitly in each function, it can in fact alter the behaviour of the same program in an incompatible way, as this example shows. This makes it a really evil feature ...
BTW, I wonder if Borland themselves noticed this straight-out incompatility between their languages, or what other more or less Borland compatible compilers do ...
So what should we do?
Up to now, we tried to handle dialects such that `--gnu-pascal' allows all dialect features combined (sometimes with warnings for particularly bad features, such as BP's "typed constants"). With `Result' this is not possible without causing incompatiblities.
The only reasonable solution I see ATM is to disable `Result' completely by default, and only enable it with `--delphi' (and a separate option which we should then probably have; `--enable-keyword=Result' won't do AFAICS since it's no keyword in Delphi, i.e. it's possible to call an identifier `Result', isn't it?; so `--enable-result' or something) ...
When it's enabled, it should, of course, be Delphi compatible then.
Frank
On 4 Mar 2005 at 6:49, Frank Heckenbach wrote:
[...]
I agree with Frank that "Result" should behave as in Delphi and it does consistently behave there the way it was designed to, although the example shows that the whole idea of an "unnamed" Result identifier is in itself a poorly designed language feature. Obviously, not much thought went into it.
Indeed! I found out it's much worse than I thought ...
Consider the following program:
program Foo;
var Result: Integer;
function f: Integer; begin f := 1; Result := 2 end;
begin Result := 3; WriteLn (f, ' ', Result) end.
In any dialect that doesn't have a built-in `Result' (e.g. EP and even BP!), the assignment goes to the global `Result' variable, so the program writes `1 2'. (This is what GPC currently does, as well as BP.)
With Delphi, it assigns to the function result, however. So I guess it writes `2 3', does it?
Yes.
So, apparently, `Result' is not just another predefined identifier of a dialect like so many others. Because it's not defined at the outermost scope, but implicitly in each function,
Yes.
it can in fact alter the behaviour of the same program in an incompatible way, as this example shows.
Yes, it possibly can. However, that outcome is fully understood (and expected) by Delphi programmers. Indeed, I have never heard of it being an issue, except perhaps in a contrived situation like this.
This makes it a really evil feature ...
I disagree. Any feature can be misused by careless programming. To me, it is not much different from;
program foo; var c : integer;
procedure bar; var c: integer; begin c := 4; writeln (c); end;
begin c := 2; bar; writeln (c); end.
In either case, the person who is assigning a value to "c" ought to know which "c" he means. Same with "Result". The programmer should know which "Result" he is assigning a value to. The main difference (which some may see as vital) is that, in the case of "Result", one is explicit and one is implicit. However, I don't see that difference as fundamental, since anyone who reads the code and understands the implict "Result" variable of functions knows which "Result" is being assigned.
BTW, I wonder if Borland themselves noticed this straight-out incompatility between their languages, or what other more or less Borland compatible compilers do ...
There is no incompatibility, since BP knows nothing about "Result". If, in your example program, you really want to assign a value to the global "Result" variable, then that can be done explicitly: "Foo.Result := 2"
So what should we do?
Nothing. Programmers should know what they are doing, and it is very easy to assign to the global variable if that is what is desired. And if they don't do that, then it is clear that what is being assigned inside the function is the function's own implicit Result variable.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku wrote:
On 4 Mar 2005 at 6:49, Frank Heckenbach wrote:
So, apparently, `Result' is not just another predefined identifier of a dialect like so many others. Because it's not defined at the outermost scope, but implicitly in each function,
Yes.
it can in fact alter the behaviour of the same program in an incompatible way, as this example shows.
Yes, it possibly can. However, that outcome is fully understood (and expected) by Delphi programmers. Indeed, I have never heard of it being an issue, except perhaps in a contrived situation like this.
This makes it a really evil feature ...
I disagree. Any feature can be misused by careless programming. To me, it is not much different from;
There is one fundamental difference: take a classic Pascal program writen 15 years ago. The programmer had no way of knowing about Delphi `Result'. Since `Result' is a nice word there is quite good chance to find variables named `Result' in such a program. Once the program is big enough you will find assignment to outer `Result' in nested functions. Compile the program using Delphi (or Delphi mode of GPC). The program will compile, but silently produce wrong results.
I think it is pointless to discuss merits of the `Result' variable in itself. We _want_ to support `Result' variable for Delphi programs. And we want to correctly compile standard Pascal programs. So `Result' variable _is_ evil because we can not do those two things simultaneously (without a version switch). Note that unlike constructs which are illegal in one dialect but meaningfull in another this one can silently introduce bugs.
BTW, I think that we should have a way to enable/disable all predefined words. Personally I would call `Result' or `Dispose' a keyword but I would also agree to something like `--enable-predefined-identifier Result'.
Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
On 4 Mar 2005 at 6:49, Frank Heckenbach wrote:
... snip ...
it can in fact alter the behaviour of the same program in an incompatible way, as this example shows.
Yes, it possibly can. However, that outcome is fully understood (and expected) by Delphi programmers. Indeed, I have never heard of it being an issue, except perhaps in a contrived situation like this.
This makes it a really evil feature ...
I disagree. Any feature can be misused by careless programming. To me, it is not much different from;
There is one fundamental difference: take a classic Pascal program writen 15 years ago. The programmer had no way of knowing about Delphi `Result'. Since `Result' is a nice word there is quite good chance to find variables named `Result' in such a program. Once the program is big enough you will find assignment to outer `Result' in nested functions. Compile the program using Delphi (or Delphi mode of GPC). The program will compile, but silently produce wrong results.
The usage also violates the fundamental Pascal principal of "declare before use".
... snip ...
BTW, I think that we should have a way to enable/disable all predefined words. Personally I would call `Result' or `Dispose' a keyword but I would also agree to something like `--enable-predefined-identifier Result'.
Dispose is in the class of standard procedures, declared in what I term the 'enclosing' or level 0 block. Result is an orphan. Nothing you do is going to meet all the previous usages. For example, a forward declared procedure must have the actual procedure heading either identical or without parameters. I prefer identical, because you can then see the header when coding it. To use result sanely, it has to be declared in the function header, but it really only affects the implementation, so it shouldn't be in the forward declaration (or equivalent for modules/units etc.).
PascalP had the ability to enable/disable all non-standard Standard Procedures bodily. Now there are several classifications: the ISO7185 list, the ISO10206 list, the GPC list, the Turbo list, the Delphi list, and I suspect the classifications are not orthagonal. Those worms are squirming.
Since they are declared at level 0 the only purpose in disabling them is to uncover non-portabilities in source code. There is no penalty whatsoever in redefining them at any level.
CBFalconer wrote:
There is one fundamental difference: take a classic Pascal program writen 15 years ago. The programmer had no way of knowing about Delphi `Result'. Since `Result' is a nice word there is quite good chance to find variables named `Result' in such a program. Once the program is big enough you will find assignment to outer `Result' in nested functions. Compile the program using Delphi (or Delphi mode of GPC). The program will compile, but silently produce wrong results.
The usage also violates the fundamental Pascal principal of "declare before use".
Actually it violates the principle of "declare" at all. That's the main problem.
... snip ...
BTW, I think that we should have a way to enable/disable all predefined words. Personally I would call `Result' or `Dispose' a keyword but I would also agree to something like `--enable-predefined-identifier Result'.
Dispose is in the class of standard procedures, declared in what I term the 'enclosing' or level 0 block. Result is an orphan. Nothing you do is going to meet all the previous usages.
Yes, that's why a compiler option is the best we can expect to meet everyone's needs.
For example, a forward declared procedure must have the actual procedure heading either identical or without parameters. I prefer identical, because you can then see the header when coding it.
So do I, and apparently many of us.
To use result sanely, it has to be declared in the function header, but it really only affects the implementation, so it shouldn't be in the forward declaration (or equivalent for modules/units etc.).
Now you're talking about explicit result variables. In fact, Markus's original posting was about these, and we've decided to allow omitting them in the forward declaration since, as you also say, they really only affect the implementation.
PascalP had the ability to enable/disable all non-standard Standard Procedures bodily. Now there are several classifications: the ISO7185 list, the ISO10206 list, the GPC list, the Turbo list, the Delphi list, and I suspect the classifications are not orthagonal. Those worms are squirming.
That's basically what we deal with with our dialect options, e.g. `--classic-pascal' disables all non-ISO7185 things. Most of the time they're only about disabling things, or changing semantics explicitly (`mod', field-widths, `-' precedence). But for `Result' we have to let a dialect option *enable* it.
Since they are declared at level 0 the only purpose in disabling them is to uncover non-portabilities in source code. There is no penalty whatsoever in redefining them at any level.
For such "level 0" things, yes. But each dialects also adds some new keywords, and for them, disabling them might be necessary to compiler other dialects' programs.
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
The usage also violates the fundamental Pascal principal of "declare before use".
Actually it violates the principle of "declare" at all. That's the main problem.
That's the reason why I'm so much of a fan of the result variable declaration in the implementation header...
Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
On 4 Mar 2005 at 6:49, Frank Heckenbach wrote:
So, apparently, `Result' is not just another predefined identifier of a dialect like so many others. Because it's not defined at the outermost scope, but implicitly in each function,
Yes.
it can in fact alter the behaviour of the same program in an incompatible way, as this example shows.
Yes, it possibly can. However, that outcome is fully understood (and expected) by Delphi programmers. Indeed, I have never heard of it being an issue, except perhaps in a contrived situation like this.
This makes it a really evil feature ...
I disagree. Any feature can be misused by careless programming. To me, it is not much different from;
There is one fundamental difference: take a classic Pascal program writen 15 years ago. The programmer had no way of knowing about Delphi `Result'. Since `Result' is a nice word there is quite good chance to find variables named `Result' in such a program. Once the program is big enough you will find assignment to outer `Result' in nested functions. Compile the program using Delphi (or Delphi mode of GPC). The program will compile, but silently produce wrong results.
Yes. The same cannot happen with The Chief's example, since there both identifiers are explicit and no standard or dialect would interpret them differently.
I think it is pointless to discuss merits of the `Result' variable in itself. We _want_ to support `Result' variable for Delphi programs. And we want to correctly compile standard Pascal programs. So `Result' variable _is_ evil because we can not do those two things simultaneously (without a version switch). Note that unlike constructs which are illegal in one dialect but meaningfull in another this one can silently introduce bugs.
Yes, that's exactly why I wrote it's evil. We've had only dialect incompatibilities (such as the semantics of `mod' or the precedence of unary `-'), but at least they were explicit. This one is a rather hidden side-effects (I had dealt with `Result' several times before, but hadn't realized this problem so far; I wonder if others have, including Borland themselves).
BTW, I think that we should have a way to enable/disable all predefined words. Personally I would call `Result' or `Dispose' a keyword
I call keywords only those names that cannot be used as identifiers (in the respective dialect), i.e. what ISO calls word-symbols. Both `Result' and `Dispose' can be redefined in all dialects AFAIK.
but I would also agree to something like `--enable-predefined-identifier Result'.
We could probably do this rather easily (since we have the mechanism working for keywords already, and keywords and predefined-identifiers are handled rather similarly internally).
However, `Result' exactly is *not* a predefined identifier like the rest (that just why it's so evil).
In particular, we can't keep the current handling of `Result' (like a predefined identifier) in order to be Delphi compatible. The original problem Markus reported could be fixed with some additional code, but my example could not (unless adding really messy code, looking at scopes, searching for declarations called `Result', etc.).
So AFAICS the right thing to do for a Delphi compatible `Result' is to actually make it a local variable declaration (as we do for explicit result variables). This should be rather easy and will naturally handle scopes correctly.
Therefore, I think we need a separate option for `Result' anyway (independent of whether we decide to add `--enable-predefined-identifier' for other reasons -- I currently don't see a need for it, since predefined identifiers can be overriden easily, without the problems we have with `Result', but I may be convinced otherwise).
I suggested `--enable-result', but as it may confuse someone not familiar with this problem, perhaps rather `--enable-implicit-result' (to be more explicit ;-).
The Chief wrote:
So what should we do?
Nothing.
But you understand this would mean leaving things are they are (or disabling `Result' completely), in both cases being incompatible to Delphi (before we even started to achieve Delphi compatibility WRT OOP). Is that really what you want?
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
BTW, I think that we should have a way to enable/disable all predefined words. Personally I would call `Result' or `Dispose' a keyword
I call keywords only those names that cannot be used as identifiers (in the respective dialect), i.e. what ISO calls word-symbols. Both `Result' and `Dispose' can be redefined in all dialects AFAIK.
If something can not be redefined, I call it a reserved word. But probably for most Pascal users keyword = reserved word.
but I would also agree to something like `--enable-predefined-identifier Result'.
We could probably do this rather easily (since we have the mechanism working for keywords already, and keywords and predefined-identifiers are handled rather similarly internally).
However, `Result' exactly is *not* a predefined identifier like the rest (that just why it's so evil).
In particular, we can't keep the current handling of `Result' (like a predefined identifier) in order to be Delphi compatible. The original problem Markus reported could be fixed with some additional code, but my example could not (unless adding really messy code, looking at scopes, searching for declarations called `Result', etc.).
So AFAICS the right thing to do for a Delphi compatible `Result' is to actually make it a local variable declaration (as we do for explicit result variables). This should be rather easy and will naturally handle scopes correctly.
Therefore, I think we need a separate option for `Result' anyway (independent of whether we decide to add `--enable-predefined-identifier' for other reasons -- I currently don't see a need for it, since predefined identifiers can be overriden easily, without the problems we have with `Result', but I may be convinced otherwise).
I agree that implementarion for `Result' is different. But from user point of view it is just attaching builtin meaning to a word, the same as other builtins. Concerning other builtins: old programs frequently are "almost" classic Pascal, with some extra builtins. Even with weak identifiers the easiest method to compile them may be to choose classic Pascal mode. But then only few builtins are available. So I think that ability to selectivly turn _on_ builtins is usefull. Similarly when there is "near miss" in dialect setting. Disabling builtins may be of some use to enforce coding guidelines.
But my main motivation is symmetry. I prefer one general-purpose mechanizm then a bunch of special cases.
BTW. `--enable-builtin-identifier' may correspond better to your intuition.
Waldek Hebisch wrote:
but I would also agree to something like `--enable-predefined-identifier Result'.
We could probably do this rather easily (since we have the mechanism working for keywords already, and keywords and predefined-identifiers are handled rather similarly internally).
However, `Result' exactly is *not* a predefined identifier like the rest (that just why it's so evil).
In particular, we can't keep the current handling of `Result' (like a predefined identifier) in order to be Delphi compatible. The original problem Markus reported could be fixed with some additional code, but my example could not (unless adding really messy code, looking at scopes, searching for declarations called `Result', etc.).
So AFAICS the right thing to do for a Delphi compatible `Result' is to actually make it a local variable declaration (as we do for explicit result variables). This should be rather easy and will naturally handle scopes correctly.
Therefore, I think we need a separate option for `Result' anyway (independent of whether we decide to add `--enable-predefined-identifier' for other reasons -- I currently don't see a need for it, since predefined identifiers can be overriden easily, without the problems we have with `Result', but I may be convinced otherwise).
I agree that implementarion for `Result' is different. But from user point of view it is just attaching builtin meaning to a word, the same as other builtins.
Well, it's not the same, as it can shadow an explicit declaration, and can be shadowed by local declarations, and can shadow each other in nested functions. That's just the trouble we're discussing, of course. So I think it would only confuse users as well as it did us, if we pretended `Result' was like the other builtin identifiers.
Concerning other builtins: old programs frequently are "almost" classic Pascal, with some extra builtins.
If it's almost EP, I'd suggest making the extra stuff available through a module not compiled in EP mode. But in CP we don't have this option ...
Even with weak identifiers the easiest method to compile them may be to choose classic Pascal mode. But then only few builtins are available. So I think that ability to selectivly turn _on_ builtins is usefull. Similarly when there is "near miss" in dialect setting. Disabling builtins may be of some use to enforce coding guidelines.
That's a point.
But my main motivation is symmetry. I prefer one general-purpose mechanizm then a bunch of special cases.
I'm not talking about a "bunch" of special cases. `Result' is really different. All the other predefined ("level 0") identifiers are the same in this regard.
Prof A Olowofoyeku (The African Chief) wrote:
On 6 Mar 2005 at 8:20, Frank Heckenbach wrote:
[...]
I suggested `--enable-result', but as it may confuse someone not familiar with this problem, perhaps rather `--enable-implicit-result' (to be more explicit ;-).
That is fine. If it were my decision however, I would simply generate a warning whenever a global variable "Result" is defined. That should warn whoever is porting legacy code about potential problems, and once he/she has ensured that there are no problems, then he/she can disable the warnings.
Perhaps if everybody wanted to port their code to the Delphi dialect. But default warnings would also appear for people who have no intention doing so (including myself ;-), and who wouldn't agree to calling their code "legacy", BTW.
But AFAICS, the people who are porting legacy code to GPC are the ones we are worried about (because the original writers of the code did not know anything about "Result").
I'm not sure what you mean here. If you mean that code using `Result' as a regular identifier is "legacy" and should be changed, I disagreee.
CBFalconer wrote:
"Prof A Olowofoyeku (The African Chief)" wrote:
On 6 Mar 2005 at 8:20, Frank Heckenbach wrote:
... snip ...
IMHO it would be better to convice Borland to add explicit result variables (probably very easy to do for them) and add a warning for all that legacy code that uses implicit `Result', so one can change it, and they can finally disable it sometime. :-)
I just saw a pig flying past my window ... ;)
As someones sig says in some newsgroup "Given sufficient thrust, pigs fly very well."
RFC 1925
Frank
On 5 Mar 2005 at 3:12, Frank Heckenbach wrote:
[...]
In particular, we can't keep the current handling of `Result' (like a predefined identifier) in order to be Delphi compatible.
True.
[...]
So AFAICS the right thing to do for a Delphi compatible `Result' is to actually make it a local variable declaration (as we do for explicit result variables). This should be rather easy and will naturally handle scopes correctly.
Agreed.
Therefore, I think we need a separate option for `Result' anyway (independent of whether we decide to add `--enable-predefined-identifier' for other reasons -- I currently don't see a need for it, since predefined identifiers can be overriden easily, without the problems we have with `Result', but I may be convinced otherwise).
I suggested `--enable-result', but as it may confuse someone not familiar with this problem, perhaps rather `--enable-implicit-result' (to be more explicit ;-).
That is fine. If it were my decision however, I would simply generate a warning whenever a global variable "Result" is defined. That should warn whoever is porting legacy code about potential problems, and once he/she has ensured that there are no problems, then he/she can disable the warnings.
The Chief wrote:
So what should we do?
Nothing.
But you understand this would mean leaving things are they are (or disabling `Result' completely), in both cases being incompatible to Delphi (before we even started to achieve Delphi compatibility WRT OOP). Is that really what you want?
No. Please see above. Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 5 Mar 2005 at 3:12, Frank Heckenbach wrote:
Therefore, I think we need a separate option for `Result' anyway (independent of whether we decide to add `--enable-predefined-identifier' for other reasons -- I currently don't see a need for it, since predefined identifiers can be overriden easily, without the problems we have with `Result', but I may be convinced otherwise).
I suggested `--enable-result', but as it may confuse someone not familiar with this problem, perhaps rather `--enable-implicit-result' (to be more explicit ;-).
That is fine. If it were my decision however, I would simply generate a warning whenever a global variable "Result" is defined. That should warn whoever is porting legacy code about potential problems, and once he/she has ensured that there are no problems, then he/she can disable the warnings.
Perhaps if everybody wanted to port their code to the Delphi dialect. But default warnings would also appear for people who have no intention doing so (including myself ;-), and who wouldn't agree to calling their code "legacy", BTW.
IMHO it would be better to convice Borland to add explicit result variables (probably very easy to do for them) and add a warning for all that legacy code that uses implicit `Result', so one can change it, and they can finally disable it sometime. :-)
Frank
On 6 Mar 2005 at 8:20, Frank Heckenbach wrote:
[...]
I suggested `--enable-result', but as it may confuse someone not familiar with this problem, perhaps rather `--enable-implicit-result' (to be more explicit ;-).
That is fine. If it were my decision however, I would simply generate a warning whenever a global variable "Result" is defined. That should warn whoever is porting legacy code about potential problems, and once he/she has ensured that there are no problems, then he/she can disable the warnings.
Perhaps if everybody wanted to port their code to the Delphi dialect. But default warnings would also appear for people who have no intention doing so (including myself ;-), and who wouldn't agree to calling their code "legacy", BTW.
But AFAICS, the people who are porting legacy code to GPC are the ones we are worried about (because the original writers of the code did not know anything about "Result").
In any case, "--enable-implicit-result" would do just fine (especially if it can be turned on in a source file).
IMHO it would be better to convice Borland to add explicit result variables (probably very easy to do for them) and add a warning for all that legacy code that uses implicit `Result', so one can change it, and they can finally disable it sometime. :-)
I just saw a pig flying past my window ... ;)
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
"Prof A Olowofoyeku (The African Chief)" wrote:
On 6 Mar 2005 at 8:20, Frank Heckenbach wrote:
... snip ...
IMHO it would be better to convice Borland to add explicit result variables (probably very easy to do for them) and add a warning for all that legacy code that uses implicit `Result', so one can change it, and they can finally disable it sometime. :-)
I just saw a pig flying past my window ... ;)
As someones sig says in some newsgroup "Given sufficient thrust, pigs fly very well."
Yes, nothing to do. Full agree with The Chief.
We know what we do.
Who ever declare a 'RESULT:..' named var in any global scope ... must feel the noise.
Thanks to Borland/Delphi for this 'Fmaj7'-taste and type proof language feature.
David
Am Fri, 04 Mar 2005 09:39:30 -0000 hat Prof A Olowofoyeku (The African Chief) chiefsoft@bigfoot.com geschrieben:
[...]
So what should we do?
Nothing. Programmers should know what they are doing, and it is very easy to assign to the global variable if that is what is desired. And if they don't do that, then it is clear that what is being assigned inside the function is the function's own implicit Result variable. Best regards, The Chief
Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
David Ulbrich wrote:
Yes, nothing to do. Full agree with The Chief.
We know what we do.
Perhaps you didn't really understand the problem. (Maybe Waldek's and my previous mails helped to clarify it.) The problem can affect programs written before Delphi even existed, so those who wrote them *cannot* have know "what they did" (i.e., what Delphi would make of it).
Thanks to Borland/Delphi for this 'Fmaj7'-taste and type proof language feature.
As I don't know what 'Fmaj7' is, I'm not sure if this comment is sarcastic or not. If not, I suggest you take a look at explicit result variables as found in EP, PXSC and probably elsewhere. They're not only type-safe (why should they not?), but also "declaration safe".
Frank
On 5 Mar 2005 at 3:34, Frank Heckenbach wrote:
David Ulbrich wrote:
[...]
Thanks to Borland/Delphi for this 'Fmaj7'-taste and type proof language feature.
As I don't know what 'Fmaj7' is, I'm not sure if this comment is sarcastic or not.
Not. Fmaj7 is a variant of the F major chord (guitar, piano, etc.). Some people think that the "major 7" variation adds spice to the chord. It certainly makes it sound different. Whether it is for the better or for the worse is simply a matter of taste ;)
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
I wrote:
`--enable-implicit-result' (to be more explicit ;-).
Actually I now prefer `--[no]-implicit-result'. This is more in line with the other positive/negative options.
I've implemented it now, and it fixes the cases discussed. It's on in `--delphi', off otherwise. (Or what about Mac Pascal, should it be on there?)
But there's another problem. Does Delphi allow redeclaration of `Result' within the same function? (I hope not -- then we'll only have to change the test program.)
Program RetVal;
function K: Char; var Result: array [1 .. 7] of Char; begin Result := '....K..'; K := Result[5] end;
begin WriteLn (K) end.
Frank
On 8 Mar 2005 at 0:38, Frank Heckenbach wrote:
I wrote:
`--enable-implicit-result' (to be more explicit ;-).
Actually I now prefer `--[no]-implicit-result'. This is more in line with the other positive/negative options.
Ok, that should be fine, thanks.
I've implemented it now, and it fixes the cases discussed. It's on in `--delphi', off otherwise. (Or what about Mac Pascal, should it be on there?)
But there's another problem. Does Delphi allow redeclaration of `Result' within the same function?
[...]
No. You get this "Error: Identifier redeclared: 'Result'".
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
I've implemented it now, and it fixes the cases discussed. It's on in `--delphi', off otherwise. (Or what about Mac Pascal, should it be on there?)
But there's another problem. Does Delphi allow redeclaration of `Result' within the same function?
[...]
No. You get this "Error: Identifier redeclared: 'Result'".
OK, I think then the next release of GPC will be compatible.
Frank
Frank Heckenbach wrote:
I wrote:
`--enable-implicit-result' (to be more explicit ;-).
Actually I now prefer `--[no]-implicit-result'. This is more in line with the other positive/negative options.
I've implemented it now, and it fixes the cases discussed. It's on in `--delphi', off otherwise. (Or what about Mac Pascal, should it be on there?)
It should be off for --mac-pascal.
Gale Paeper gpaeper@empirenet.com