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