The only use for labels inside those constructs is that they would show up
if Trace L is in effect. Otherwise, they are useless. 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.
Rick
On Wed, Oct 23, 2024 at 4:19 PM Chip Davis <c...@aresti.com> wrote:
> For my benefit (I am not the language-design mavens some of you are) would
> someone give me a code example where using a label inside a block
> instruction was useful, necessary, or even reasonable. Aside from
> violating many fundamentals of the Rexx Philosophy, I can't understand what
> algorithmic problem would be solved by allowing such labels.
>
> -Chip-
>
>
> 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.
>
> Kind regards,
>
> Josep Maria
>
>
>
>
>
> _______________________________________________
> Oorexx-devel mailing
> listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
