On 09.09.2024 11:43, Josep Maria Blasco wrote:
Missatge de Rick McGuire <[email protected]> del dia dc., 4 de set. 2024 a
les 18:14:
On Wed, Sep 4, 2024 at 12:07 PM Erich Steinböck
<[email protected]> wrote:
Ok, thanks.
As, except for tracing, there seems to be little value in labels that
cannot be branched
to, should we completely disallow them already in the translation
phase, like it is done
for labels within INTERPRET?
One of the open bug reports claims we should allow `label: THEN` within
an IF (it's the
ANSI argument) and I wonder whether we really want a fix with so lottle
vealue.
I think I'd be in favor of not allowing them at those locations. I agree
there is very little
value in having them there, and the control structure of how instructions
are linked together
probably would not accommodate that well.
(Resending from my Gmail address)
My impression is that several different questions are being conflated here. Let
me elaborate.
It would be nice if others would give their opinions, too. The changes to the
language are important.
I will work modulo null clauses (as they are completely ignored, I will do so myself). Labels can
precede other labels and different clauses, including the implicit exit instruction assumed at the
end of every code body
e.g., you can place a label at the end of a program (or prolog), of a
routine or of a method
body,
but excluding directives, i.e., you cannot place a label immediately before a directive, because
of the way the parser works: LABEL: ::DIRECTIVE would be parsed as {LABEL ::} {:DIRECTIVE}, and
then we would have a directive start marker, "::", followed by a single colon, ":", which is
obviously invalid.
A label before a directive, anyway, would not make much sense: a directive is non-executable,
while a label is in principle always traceable, and may additionally also be SIGNALable, CALLable,
etc.
Even if all clauses can, in principle, from a Classic Rexx perspective, be labelled, not all
labels make the same sense.
* *Group 1)* Some labels are indisputable. They are attached to first-level
instructions (i.e.,
instructions which are not inside a block instruction), and can therefore
be the targets of
CALL, SIGNAL, etc. (unless they are duplicates).
* *Group 4)* In the other extreme, labels before WHEN, THEN, ELSE, OTHERWISE,
or the END of a
SELECT block do not seem to make much sense. There is no possible semantics
for a SIGNAL or a
CALL to one of these labels which appears to be meaningful (unless we
ignore a THEN clause and
branch instead to the attached instruction, for example, but this is to
evade the question).
These clauses, in some sense, can be thought of as non-executable, pure
syntax sugar (not that
they have to be in the current interpreter, but think of an optimizing
compiler). Since labels
identifying them cannot be used in any significant way, there are strong
arguments in favour
of forbidding them altogether.
* *Group 3)* Labels before LEAVE, ITERATE and END for DO/LOOP blocks are only
slightly less
problematic. The difference with the above is that LEAVE, ITERATE and END
are actually
executable instructions or clauses (and END, if we allow it to mean "jump
to the start of the
loop"). A branch to one of these would produce an immediate error, but they
should be able to
be traced. This makes a strong point in favour of forbidding static SIGNAL
and CALLs to these
labels at translation time, but allowing them to be used for tracing.
* *Group 2)* Other labels inside block instructions are similarly
problematic. Being able to
SIGNAL one of these labels made sense in the times of TRL2 (and for sure it
opens several
interesting avenues for programming), but it is not allowed by ANSI. If one
wants to assign a
sane semantics to such a branch, one has to stipulate that the program should
"jump out" of
the block instruction before encountering a conflicting instruction (like
LEAVE, ITERATE or
END). Implementing such a semantics makes writing compilers much more
difficult and/or
inefficient.
ANSI defines labels inside block instructions as /trace-only/ (6.4.2), and disallows SIGNALing or
CALLing them (errors 16.2 and 16.3).
Currently, Erich is writing a set of patches that completely _disallow /all labels/_ inside block
instructions, and (in the more recent patch) also labels attached to instructions which should not
be jumped to, like EXPOSE. You can follow the development of these patches here:
https://sourceforge.net/p/oorexx/bugs/1945/
Some users complained that this change would make the claimed compatibility with classic Rexx
extremely problematic.
I tend to agree.
One thing is to _disallow /branches/_ into labels inside block instructions (or EXPOSE, etc),
effectively making these labels trace-only, to use the ANSI nomenclature, and a completely
different one is to _disallow /the labels themselves/_.
Disallowing the label themselves *breaks TRACE L semantics, and poses a big compatibility
problem*. To me, it appears as a not very good idea.
On the other hand, disallowing labels in places where they do not make any sense altogether (i.e.,
group 4 labels) seems a sensible approach. The TRACE effect can be achieved by attaching a label
to the subordinate instruction, in the case of WHEN, THEN, ELSE, OTHERWISE, or just after the
instruction, in the case of SELECT.
Labels inside block instructions or non-branchable instructions (like EXPOSE or USE LOCAL) should
be allowed, but they should be made trace-only.
To summarize, my take is the following:
* Group 1: Allow labels, SIGNAL and CALL.
* Groups 2 and 3: Allow labels, but make them trace only. Static SIGNAL and
CALL instructions
should be rejected at translation time.
* Group 4: Labels should not be allowed (and thus SIGNAL or CALL become
impossible).
What's your opinion?
Well, I have been following these items, issues and fixes, and have been fascinated by your and
Erich's hard and close work! Kudos to both!
Ad labels in selects and the like: I learned that "trace l" adds utility to it (would have never
thought about that).
With regards to compatibility: if it is to be expected that code exists that takes advantage of
these ANSI definitions then it would be desirable that ooRexx would be able to execute such code
(thereby making that feature available to ooRexx as well, now that we know :) ).
Just my 2 cents.
---rony
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
