Hi all,
There are some ongoing changes to the ooRexx interpreter
that will strongly affect the language definition, in such a
way that the 5.1.0 release may end up implementing a version
of the language that does no longer allow us to hold true what
is asserted in the landing page for the project:
"Home of the Open Object Rexx Project. ooRexx is the open
source version of IBM's Object REXX Interpreter. It is
upwardly compatible with classic REXX and will execute
classic REXX programs unchanged. The project is
managed by the Rexx Language Association".
In the preceding paragraph, I have highlighted the part
that will become problematic if the ongoing changes
consolidate. Namely,
- Any program containing labels inside block instructions
will immediately stop working (with syntax error 47.002
for DO/LOOP, 47.003 for IF, and 47.004 for SELECT).
- Any program containing labels before the initial EXPOSE
or USE LOCAL method instructions will fail (with 99.910
for USE LOCAL and 99.907 for EXPOSE).
Please note that these programs will stop working
even if they never branch (i.e., SIGNAL or CALL) to
any of these labels. Normal ("classic Rexx") semantics
for such labels is to treat them as null clauses, except for
tracing purposes: when TRACE Labels is in effect, the
language processor
Traces [...] labels passed during program execution. This
is especially useful with debug mode, when the language
processor pauses after each invocation or call (rexxref
2.29.1).
If the ongoing changes consolidate into the 5.1.0 release,
our claim of compatibility with classic Rexx will no longer be
valid.
My impression is that these changes should be reverted, but
I understand that there has been a considerable amount of
effort put by the developers in implementing these
modifications, and therefore such a reversal should not be
undertaken slightly.
Please allow me to elaborate on the background behind these
changes, to widen our perspective about the subject.
Statement of the problem
A label is a clause. Following TRL2 (and TRL1, in that
respect), "more than one label may precede any instruction"
(emphasis mine). Some interpreters seem to allow labels
preceding any clause. To appreciate the difference
between the two concepts, please consider the following small
program:
Trace L
A: If 1 = 1
B: Then
C: Say "Hi"
Object Rexx (6.00, ArcaOS) chokes on B:, but allows A: and
C: (THEN is not an instruction by itself); Regina Rexx happily
processes A:, B: and C: (and traces them, when asked); the
current version of ooRexx refuses to run the above program,
even if we eliminate the B: label (it produces a 47.3, 'Labels
are not allowed within an IF block; found "C"').
The ANSI standard defines labels inside a block instruction
as "trace-only", and reserves errors 16.2 and 16.3 for the
cases when a CALL or SIGNAL instruction tries to target one of
these labels.
The Errata for the Rexx standard explicitly corrects
6.3.2.14 and 6.3.2.19, stating "This disallows labels before
the THEN keyword".
Now the question is the following:
¿What variant of the language should ooRexx implement?
There was some discussion in the developers list (starting
at
https://sourceforge.net/p/oorexx/mailman/message/58813104/)
about whether labels inside block instructions should be
allowed to be called/branched to. The consensus was that this
should not be allowed, putting ooRexx in line with the ANSI
standard in this respect. I agree with that.
There was also a discussion about whether labels should be
allowed when they cannot be branched to. The example
used was relatively ambiguous, since it used a label before a
THEN keyword:
label: THEN
¿Why do I say that this is an ambiguous example? Because
one might object to disallowing such a label, a) because THEN
is not an instruction, or b) because THEN is part of an IF.
Depending on how we understand the example, we will have two
different versions of the language.
The main point is this
One may have good reasons to want to disallow labels before
THEN and, at the same time, think that instructions
inside other instructions (i.e., not clauses which are
not instructions by themselves) deserve to have labels, even
if they are, as the ANSI standard says, trace-only.
My take is the following
Labels before THEN, ELSE, WHEN, OTHERWISE or END should not
be allowed. All other labels should be allowed, including
before EXPOSE and USE LOCAL. SIGNALing or CALLing a label
before EXPOSE or USE LOCAL, or a label inside an
IF/DO/LOOP/SELECT should produce an error.
What do you all think?
This is important. We are about to change the definition of
the language, making it potentially incompatible with many
existing programs.
Kind regards,
Josep Maria
