On Fri, Oct 25, 2024 at 4:24 PM Chip Davis <c...@aresti.com> wrote:
> 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 took a quick look at the code, the disruption is much less severe that I
first thought and can even be done without causing problems with programs
saved using rexxc.
Rick
>
> 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
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
