I forgot to add: another possibility which is also easy to remember and
explain is the following:
Definition: nesting level: the number of opened unpaired "(" and "[" when
examining thee current token.
Rule: A simple symbol will be recognized as an expression terminator if and
only if it is at nesting level zero and it is found after a blank or
abuttal concatenation operator.
This option would give maximal freedom to the programmer. My only worry is
that it, in some cases, it might make error detection more complicated.
Josep Maria
Missatge de Josep Maria Blasco <jose.maria.bla...@gmail.com> del dia dc.,
11 de set. 2024 a les 18:07:
> The latest fixes have added a new chapter to rexxref, chapter 16 "Reserved
> keywords", which details when a simple symbol will be recognized as an
> expression terminator. I think this is a very welcome addition to the
> reference manual.
>
> Allow me to center the discussion around an example: the DO instruction.
>
> TRL2 says
>
> The sub-keywords WHILE and UNTIL are reserved within a DO instruction, in
> that they cannot be used as symbols in any of the expressions. Similarly,
> TO, BY, and FOR cannot be used in *expri*, *exprt*, *exprb*, or *exprf*.
> FOREVER is also reserved, but only if it immediately follows the keyword DO.
>
>
> Regina follows TRL2. The version of Object Rexx distributed with OS/2,
> "OBJREXX 6.00 18 May 1999", also has the same paragraph.
>
> ooRexx is much more flexible. It takes the "no reserved words" philosophy
> of Rexx (which it inherited from PL/I) to a new level, because it allows to
> use a symbol that would usually be considered to be a reserved word as a
> normal variable if it is found between parenthesis (or brackets, but this
> was not documented until the very recent addition of chapter 16). So, for
> example, after to = 3,
>
> Do i = 1 To to; Say i; End
>
>
> produces a syntax error, while
>
> Do i = 1 To (to); Say i; End
>
>
> works perfectly.
>
> One day, I realized that
>
> Do i = 1 To >to ; Say i; End
>
>
> was working. I reported it as a bug: the documentation said that reserved
> symbols had to be between parenthesis to be usable as normal variables.
> Rick pointed that a construction like
>
> Do i = 1 To a~to ; Say i; End
>
>
> produced an error, and that both cases should work in the same way.
>
> Lately, there have been some fixes that modify the language so that these
> constructions are both accepted. This is documented in the new chapter 16:
>
> While typically these reserved keywords act as expression terminators,
> using them within terms like message terms or Variable Reference terms, or
> with parentheses around or within the expression, can prevent these
> keywords from terminating the expression.
>
>
> In the discussion of a new bug, I discovered that namespace-qualified
> symbols are also accepted, even if they are reserved subkeywords. So, for
> example
>
> namespace:to
>
>
> would not be recognized as a reserved subkeyword. This is still not
> documented.
>
> I understand and appreciate the general intention of these modifications:
> they are an attempt to improve the language by making it as independent of
> reserved keywords as possible.
>
> But at the same time, I am afraid that this goes against the idea of
> keeping the language small and simple.
>
> Allow me to elaborate a little more. If the namespace feature is
> documented, the mentioned paragraph should tell the user that a reserved
> subkeyword can be used as a normal symbol when 1) it is between
> parentheses; 2) when it is between brackets (I would strongly suggest
> making this possibility explicit); 3) when it is used as a Variable
> Reference term; 4) when it is the message name of a message term; and now
> 5) when it is a namespace-qualified symbol.
>
> To me, it seems that this is getting complicated, very complicated, and
> quite difficult to remember. With a suitable preparsing pass, a parser
> could also accept subkeywords-as-variables as the right operands of most
> binary operators (I checked it), but what would we gain from it?
>
> Very little in terms of making our own life easier. And we would be
> getting a language that would be more and more complicated.
>
> I would suggest reverting things to something which can be effortlessly
> explained and understood: a reserved subkeyword will not be recognized as
> an expression terminator *if and only if it is found between parenthesis
> or brackets*. And nothing more. No more special cases.
>
> When things become too complicated, I feel forced to re-read the manual
> continuously. It's a nuisance, not something which makes my programming
> life easier.
>
> I would prefer a syntax which is simple and easy to remember.
>
> Josep Maria
>
>
>
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
