Page 1 of 3

KeyWord

Posted: Sat Dec 02, 2017 2:20 am
by luowy
report by
https://forum.oberoncore.ru/viewtopic.php?f=29&t=6166

Code: Select all

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.

Re: KeyWord

Posted: Sat Dec 02, 2017 8:10 pm
by Josef Templ
This is an inconsistency in the language report.
It mixes keywords with predefined global identifiers.

It could be fixed easily in the docu.
For the keywords DevCPS.Get is relevant.

ARRAY
BEGIN
BY
CASE
...

- Josef

Re: KeyWord

Posted: Sun Dec 03, 2017 4:26 am
by luowy
I add a single line code to solve this problem in DevCPT.Insert and DevCPT.InsertThisField at
beginning:

Code: Select all

IF (name = "ABSTRACT") OR (name = "EXTENSIBLE") OR (name = "LIMITED") THEN DevCPM.Mark(48, DevCPM.curpos-1);END;
you can ignore it if you not like;

Re: KeyWord

Posted: Mon Dec 10, 2018 4:35 pm
by Robert
What is the status of this "Bug"? Is it Dormant or Rejected or Resolved, or something else?

Re: KeyWord

Posted: Thu Dec 13, 2018 3:05 pm
by Zinn
luowy wrote:I add a single line code to solve this problem in DevCPT.Insert and DevCPT.InsertThisField at
beginning:

Code: Select all

IF (name = "ABSTRACT") OR (name = "EXTENSIBLE") OR (name = "LIMITED") THEN DevCPM.Mark(48, DevCPM.curpos-1);END;
you can ignore it if you not like;
Here it make sense to add your lines. I prefer to trade it as keyword and not as global variable.
- Helmut

After following this discussion I changed my mind. We should not add this changes.

Re: KeyWord

Posted: Fri Dec 14, 2018 12:54 pm
by Robert
Josef Templ wrote:This is an inconsistency in the language report.
It mixes keywords with predefined global identifiers.

It could be fixed easily in the docu.
Can you expand this a little; what is the easy fix, and in which docu?

Re: KeyWord

Posted: Fri Dec 14, 2018 3:46 pm
by Josef Templ
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.

- Josef

Re: KeyWord

Posted: Fri Dec 14, 2018 10:43 pm
by cfbsoftware
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.

Re: KeyWord

Posted: Sat Dec 15, 2018 9:34 am
by Josef Templ
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

Re: KeyWord

Posted: Sat Dec 15, 2018 10:34 am
by cfbsoftware
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.