KeyWord

cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: KeyWord

Post by cfbsoftware »

Robert wrote:Isn't the genie the fact that predeclared identifiers can be redefined at all?
The reason behind not defining predeclared identifiers as reserved words is not so that you can redefine them. The reason is to protect you from future language changes:

When new predeclared identifiers are introduced (either because of evolution of the language or when porting to the same language in a different environment) you don't have to worry about your code breaking if the names you chose for your identifiers now clash with the new predeclared ones. Yours will take precedence. You would only have to rename yours if and when you wanted to use the new features.

As Josef surmised - that may be the reason why Oberon microsystems weren't as dogmatic as they could have been when they implemented the new attributes.

Admittedly, however, this is not as much of a benefit for users of BlackBox Component Pascal as it might be for users of other languages because (as far as I know):
  • There are only two active implementations of Component Pascal
  • No new predeclared identifiers have been added to the language in the last 10 years.
    and, anyway:
  • You can avoid such potential future name clashes by avoiding the use of uppercase names for your identifiers.
It is interesting to see how the designers of C# handled the same issue:

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/index

They have a few more reserved words to worry about!
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: KeyWord

Post by Robert »

cfbsoftware wrote:The reason behind not defining predeclared identifiers as reserved words is ...
Thanks for the explanation, which makes sense to me.

We are left with the (minor) problem that the reserved words ABSTRACT, EMPTY, EXTENSIBLE, & LIMITED can be redefined without compile time error, but this is forbidden by the Language Report.
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: KeyWord

Post by cfbsoftware »

Robert wrote:We are left with the (minor) problem that the reserved words ABSTRACT, EMPTY, EXTENSIBLE, & LIMITED can be redefined without compile time error, but this is forbidden by the Language Report.
My recommendation would be to just put a note mentioning it as a limitation of the BlackBox implementation of Component Pascal in the 'Platform-Specific Issues' section of the BB Help. It is highly unlikely that it would actually result in a problem in the real world e.g. if somebody redefined them accidentally.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: KeyWord

Post by Josef Templ »

cfbsoftware wrote:
Robert wrote:We are left with the (minor) problem that the reserved words ABSTRACT, EMPTY, EXTENSIBLE, & LIMITED can be redefined without compile time error, but this is forbidden by the Language Report.
My recommendation would be to just put a note mentioning it as a limitation of the BlackBox implementation of Component Pascal in the 'Platform-Specific Issues' section of the BB Help. It is highly unlikely that it would actually result in a problem in the real world e.g. if somebody redefined them accidentally.
This would be OK for me, too.
My first choice would have been to treat it as a typo in the spec, but if there is no agreement on that,
it can also be handled in the Platform-Specific Issues.

- Josef
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: KeyWord

Post by Robert »

I see three options:

1 - Do nothing - this seems to be a minority preference.
2 - Fix the compiler (maybe a small modification of luowy's suggestion).
3 - Apologise in the Platform-Specific-Issues document for not fixing the compiler.

Comparing (2) with (3):

- It makes the compiler compliant with the Language Report - Good!
- It makes the compiler consistent with GPCP - Good!
- It is a simpler solution from the point of view of language users - Good!
- It potentially breaks some existing (illegal) programs - Bad? My guess is that this is a very low risk.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: KeyWord

Post by Josef Templ »

The fourth choice is to fix the inconsistency in the docu.

Once again, the intention of the compiler writer is very clear in this particular case.
The names in question are intended to be predefined names, not keywords.

If you want to check directly with the compiler, which is very easy in this case, have a look at
DevCPT.EnterAttr and its usage in the body.

There are no keywords defined but there is a special object mode introduced especially for representing for attributes.
Why would somebody introduce extra code for making those names keywords eventually??

Since the practical implications are zero, I cannot understand why a fix of this inconsistency in the report
should not be possible.

- Josef
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: KeyWord

Post by Robert »

Josef Templ wrote:The fourth choice is to fix the inconsistency in the docu.
Can you please spell out which two bits of the Language Report contradict each other.
Once again, the intention of the compiler writer is very clear in this particular case.
The names in question are intended to be predefined names, not keywords.
This makes it sound as if the inconsistency is between the Language Report and the compiler. Ok, but I don't know if the reason is an error in the Report, or a misunderstanding on the part of the compiler writer.
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: KeyWord

Post by cfbsoftware »

Josef Templ wrote: Since the practical implications are zero, I cannot understand why a fix of this inconsistency in the report
should not be possible.
The problem is that you would then break the Gardens Point Component Pascal compiler which implements the language as defined in the report. In that case the intention of the compiler writer is also very clear. The Reserved words EMPTY, EXTENSIBLE and LIMITED are recognised in procedure CheckLiteral in the Scanner module CPascalS with all the other reserved words. That is where I would have expected to find them.

As I suggested previously I suspect that Oberon microsystems were being pragmatic rather than dogmatic. I can understand why as it would have been a riskier path to take to implement it to the letter of the report. Commercial organisations always have to consider the financial risk as well as the pursuit of perfection. Unless their reasoning has been documented it is fruitless to attempt to guess what they were thinking of at the time. However, you could always ask them if you really want to know.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: KeyWord

Post by Josef Templ »

Robert, yes the inconsistency is between the compiler and the docu.
And if you resolve it in the compiler you end up with one anomaly left: NEW.
So it cannot be cleanly resolved in the compiler.
In addition, I strongly believe that the intention was that those names are not keywords but
happen to be listed in the wrong place in the docu (see DevCPT).

The resulting inconsistency with the GP compiler is unfortunate but unavoidable.
The practical implications are ZERO. This inconsistency existed within BlackBox for 20+ years now
and nobody cared.
IMHO, the BB compiler is and should be the reference compiler and it should be clean and free of
contradictions with the docu.

- Josef
Post Reply