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
