And yet, Rick said, "So the question comes down to 1) disallow them if
they appear in a location where they can't be branched to, or 2) allow
them, but catch all attempts to branch to one in a bad location. From
my standpoint, catching them at translation time and raising an error
is much better than the disruption that would be caused to rework the
internals to raise an error at run time. And the nice thing about
raising an error up front is that it is always easier to lift a
restriction later than try to impose one after the fact."
"... the attempt to branch to them" is at execution time, and Rick has
already deemed it a "disruption that would be caused to rework the
internals to raise an error at run time", so that seems like a heavy
lift to me.
I still agree with JMB's "take". "Belling the cat" at run-time sounds
like a non-trivial effort.
-Chip-
On 10/25/2024 9:35 AM, Gilbert Barmwater wrote:
I've read all the comments (so far) on this and the ones that had
the most impact on my opinion were Mike's -
"...it's the attempt to branch to them that should be flagged, not
the label itself, which is just a label." - and Jeremy's - "Some
users might be running code that they don't have source for - ie
they've been supplied with the output from rexxc. Why should they
not be able to continue to run their programs?". So I vote for
allowing "trace only" labels but raising an error if an attempt is
made to SIGNAL or CALL them.
On 10/23/2024 9:31 AM, Josep Maria Blasco wrote:
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.
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
