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? Josep Maria
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
