MODULE ObxKW;
(* https://forum.oberoncore.ru/viewtopic.php?f=29&t=6166 *)
TYPE
ABSTRACT = POINTER TO RECORD END;
VAR
EXTENSIBLE, LIMITED: ABSTRACT;
BEGIN
EXTENSIBLE := LIMITED;
END ObxKW.
In the compiler, keywords and predefined objects are treated in a very different way.
It looks obvious to me that the intention was to treat the type attributes as predefined objects
and not as keywords. I cannot imagine that this was done accidentally in the compiler.
I think the intention was to make as few changes to the set of keywords as possible in order to preserve
compatibility with the original Oberon language and maybe there are more reasons.
In the docu then 3 predefined identifiers were listed under keywords.
With the proposed fix you would forbid using them as identifiers but it creates some mess
in the compiler because then some keywords are real keywords and some are specially treated
predefined identifiers.
I checked the text example in the other major implementation of Component Pascal (GPCP) and it failed to compile as I would have expected. The CP language report defines EXTENSIBLE, ABSTRACT and LIMITED as reserved words and explicitly states that they 'cannot be used as identifiers'.
However I agree that it is quite posible that it was implemented in the BlackBox compiler the way it was for pragmatic reasons. If a proposed solution makes the compiler less maintainable then I'm happy for it to be left as it is - I'm not particularly concerned that it does not reject a pathological test case that I would not expect to occur in the real world.
if the alternative solution, 'It could be fixed easily in the docu', means changing the language report I would reject that.
Another reason for treating the modifiers as predefined objects, I think, is the
existence of the NEW modifier for type-bound procedures.
NEW was already a predefined name in Oberon and was also used as such in CP.
But NEW is not only a standard procedure but is also used for marking newly added type-bound procedures.
This duality may have been an unfortunate decision but it can certainly not be changed now.
Having one modifier as a predefined object and others as keywords would be strange, wouldn't it?
In general, if the language report accidentally listed INTEGER as a keyword
I would not consider it a 'change' to fix that but rather as fixing a typo.
The practical implications are zero because no existing program can be invalidated.
The distinction between keywords and predefined objects is a subtle topic.
Why does it exist at all? I mean, why aren't for example the basic types (INTEGER, etc.) not keywords but
predefined types? In my understanding the reason for inventing and using the concept of predefined
objects is upgrade-ability. If at a later time a new basic type or standard procedure (or modifier)
needs to be added to the language it does not invalidate any existing programs that happen to use
that particular identifier.
Josef Templ wrote:
The distinction between keywords and predefined objects is a subtle topic.
Why does it exist at all? I mean, why aren't for example the basic types (INTEGER, etc.) not keywords but
predefined types? In my understanding the reason for inventing and using the concept of predefined
objects is upgrade-ability. If at a later time a new basic type or standard procedure (or modifier)
needs to be added to the language it does not invalidate any existing programs that happen to use
that particular identifier.
Appendix B: Syntax of Component Pascal clarifies the distinction between reserved words / keywords and standard / predefined identifiers for me. The list of keywords comprises all the literal values that appear there. The fact that NEW has a split personality being both a predefined object and a keyword makes it an exception but that is no reason for any other reserved words / keywords to be treated similarly.
Last edited by cfbsoftware on Sat Dec 15, 2018 11:10 am, edited 1 time in total.