Consider this code, which may have some typos in it. Which of these numbered statements are valid?

a: PROCEDURE();
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */
END; /* b */
CALL c(); /* 1: Valid? */
CALL b();
CALL cref(); /* 2: Valid? */
CALL d();
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */
END /* a */

d: PROCEDURE();
CALL a;
STOP;
dynamic: ;
END;

0) Jumps to statically enclosing procedure
1) Calls inner inner procedure without calling sub-procedure
2) Calls inner inner procedure via procedure variable set up by inner procedure 3) Jumps to dynamically invoking procedure

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Cowan <cowan@ccil.org> wrote:

Consider this code, which may have some typos in it. Which of these
numbered statements are valid?

a: PROCEDURE();
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */
END; /* b */
CALL c(); /* 1: Valid? */
CALL b();
CALL cref(); /* 2: Valid? */
CALL d();
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */
END /* a */

d: PROCEDURE();
CALL a;
STOP;
dynamic: ;
END;

0) Jumps to statically enclosing procedure
1) Calls inner inner procedure without calling sub-procedure
2) Calls inner inner procedure via procedure variable set up by inner procedure
3) Jumps to dynamically invoking procedure

little hard to figure out, but “GOTO dynamic” is invalid because it is out of the scope of a. You can goto out of a procedure, but not into one.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/21/22 7:13 PM, John Cowan wrote:

Consider this code, which may have some typos in it. Which of these numbered statements are valid?

a: PROCEDURE();
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */
END; /* b */
CALL c(); /* 1: Valid? */
CALL b();
CALL cref(); /* 2: Valid? */
CALL d();
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */
END /* a */

d: PROCEDURE();
CALL a;
STOP;
dynamic: ;
END;

0) Jumps to statically enclosing procedure
1) Calls inner inner procedure without calling sub-procedure
2) Calls inner inner procedure via procedure variable set up by inner procedure
3) Jumps to dynamically invoking procedure

0 is invalid because there is no way to get to it, because it
immediately follows RETURN. A compiler for a modern language with
mandatory flow analysis, like Java or Swift, would catch it.

1 is invalid because c is inside b and b is dead. Any PL/I compiler will
catch it.

2 is invalid because the value of cref is c, which is inside b, and b is
dead. The results will depend on the way that the compiler and runtime implement ENTRY parameters and variables, but it is wrongity-wrong, and
will probably crash or worse.

3 is invalid beause d is dead. Any PL/I compiler will catch it.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 22, 2022 at 9:13:25 AM UTC+10, co...@ccil.org wrote:

Consider this code, which may have some typos in it. Which of these numbered statements are valid?

a: PROCEDURE();
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */
END; /* b */
CALL c(); /* 1: Valid? */
CALL b();
CALL cref(); /* 2: Valid? */
CALL d();
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */
END /* a */

d: PROCEDURE();
CALL a;
STOP;
dynamic: ;
END;

0) Jumps to statically enclosing procedure
1) Calls inner inner procedure without calling sub-procedure
2) Calls inner inner procedure via procedure variable set up by inner procedure
3) Jumps to dynamically invoking procedure

.

a: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */ YES
END; /* b */
CALL c(); /* 1: Valid? */ NO, NOT WITHIN SCOPE
CALL b(); YES
CALL cref(); /* 2: Valid? */ YES
CALL d(); REQUIRES EXTERNAL ATTRIBUTE
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */ NO, NOT WITHIN SCOPE
END /* a */

d: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
CALL a;
STOP;
dynamic: ;
END;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/21/22 9:59 PM, Robin Vowels wrote:

On Thursday, September 22, 2022 at 9:13:25 AM UTC+10, co...@ccil.org wrote:

Consider this code, which may have some typos in it. Which of these numbered statements are valid?

a: PROCEDURE();
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */
END; /* b */
CALL c(); /* 1: Valid? */
CALL b();
CALL cref(); /* 2: Valid? */
CALL d();
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */
END /* a */

d: PROCEDURE();
CALL a;
STOP;
dynamic: ;
END;

0) Jumps to statically enclosing procedure
1) Calls inner inner procedure without calling sub-procedure
2) Calls inner inner procedure via procedure variable set up by inner procedure
3) Jumps to dynamically invoking procedure

.

a: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */ YES
END; /* b */
CALL c(); /* 1: Valid? */ NO, NOT WITHIN SCOPE
CALL b(); YES
CALL cref(); /* 2: Valid? */ YES
CALL d(); REQUIRES EXTERNAL ATTRIBUTE
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */ NO, NOT WITHIN SCOPE
END /* a */

d: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
CALL a;
STOP;
dynamic: ;
END;

0 is not valid, because it is an unreachable statement.

2 is not valid, beecause the value in cref has to contain a live
environment of b, and it doesn’t.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 22, 2022 at 12:23:38 PM UTC+10, John W. Kennedy wrote:

On 9/21/22 9:59 PM, Robin Vowels wrote:

On Thursday, September 22, 2022 at 9:13:25 AM UTC+10, co...@ccil.org wrote:

Consider this code, which may have some typos in it. Which of these numbered statements are valid?

a: PROCEDURE();
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */
END; /* b */
CALL c(); /* 1: Valid? */
CALL b();
CALL cref(); /* 2: Valid? */
CALL d();
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */
END /* a */

d: PROCEDURE();
CALL a;
STOP;
dynamic: ;
END;

0) Jumps to statically enclosing procedure
1) Calls inner inner procedure without calling sub-procedure
2) Calls inner inner procedure via procedure variable set up by inner procedure
3) Jumps to dynamically invoking procedure

.

a: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */ YES
END; /* b */
CALL c(); /* 1: Valid? */ NO, NOT WITHIN SCOPE
CALL b(); YES
CALL cref(); /* 2: Valid? */ YES
CALL d(); REQUIRES EXTERNAL ATTRIBUTE
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */ NO, NOT WITHIN SCOPE
END /* a */

d: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
CALL a;
STOP;
dynamic: ;
END;

.

0 is not valid, because it is an unreachable statement.

.
The statement GO TO STATIC; is in procedure A.
The label STATIC is in procedure A.
Therefore, the GO TO statement is legal and could transfer to
to label STATIC. LabelSTATIC is reachable from the GO TO statement.
.
The OP asked only whether the statements are valid or not,
not whether it made any sense to execute them in this skeleton program.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robin Vowels <robin.vowels@gmail.com> wrote:

On Thursday, September 22, 2022 at 12:23:38 PM UTC+10, John W. Kennedy wrote:

On 9/21/22 9:59 PM, Robin Vowels wrote:

On Thursday, September 22, 2022 at 9:13:25 AM UTC+10, co...@ccil.org wrote: >>>> Consider this code, which may have some typos in it. Which of these

numbered statements are valid?

a: PROCEDURE();
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */
END; /* b */
CALL c(); /* 1: Valid? */
CALL b();
CALL cref(); /* 2: Valid? */
CALL d();
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */
END /* a */

d: PROCEDURE();
CALL a;
STOP;
dynamic: ;
END;

0) Jumps to statically enclosing procedure
1) Calls inner inner procedure without calling sub-procedure
2) Calls inner inner procedure via procedure variable set up by inner procedure
3) Jumps to dynamically invoking procedure

.

a: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */ YES
END; /* b */
CALL c(); /* 1: Valid? */ NO, NOT WITHIN SCOPE
CALL b(); YES
CALL cref(); /* 2: Valid? */ YES
CALL d(); REQUIRES EXTERNAL ATTRIBUTE
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */ NO, NOT WITHIN SCOPE
END /* a */

d: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
CALL a;
STOP;
dynamic: ;
END;

.

0 is not valid, because it is an unreachable statement.

.
The statement GO TO STATIC; is in procedure A.
The label STATIC is in procedure A.
Therefore, the GO TO statement is legal and could transfer to
to label STATIC. LabelSTATIC is reachable from the GO TO statement.
.
The OP asked only whether the statements are valid or not,
not whether it made any sense to execute them in this skeleton program.

+1

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 22, 2022 at 4:06:23 AM UTC-4, Robin Vowels wrote:

The OP asked only whether the statements are valid or not,
not whether it made any sense to execute them in this skeleton program.

Indeed, I ought not to have tried to present any such program, because
to get it right *and* illustrate all my points is just too hard at my current state of understanding. But let me summarize what I think I have learned:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some other procedure G, even if G is F. Attempts to dodge this rule using procedure variables are unavailing.

(b) A GOTO in a procedure X may jump to a label in X or any containing procedure at any level, but not to arbitrary procedures further
up the call stack. Presumably attempts to dodge this rule using label variables are likewise unavailing.

(c) From (a) and (b) together we can conclude that if procedure Z is directly or indirectly contained in procedure Y, then when Z is executing, Y is also
on the call stack.

Yes?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 22, 2022 at 11:45:34 PM UTC+10, co...@ccil.org wrote:

On Thursday, September 22, 2022 at 4:06:23 AM UTC-4, Robin Vowels wrote:

The OP asked only whether the statements are valid or not,
not whether it made any sense to execute them in this skeleton program.

Indeed, I ought not to have tried to present any such program, because
to get it right *and* illustrate all my points is just too hard at my current state of understanding. But let me summarize what I think I have learned:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(b) A GOTO in a procedure X may jump to a label in X or any containing procedure at any level, but not to arbitrary procedures further
up the call stack. Presumably attempts to dodge this rule using label variables are likewise unavailing.

(c) From (a) and (b) together we can conclude that if procedure Z is directly or indirectly contained in procedure Y, then when Z is executing, Y is also on the call stack.

Yes?

.
Yes. Y must have been active in order for Z to have been called.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/22/22 4:06 AM, Robin Vowels wrote:

On Thursday, September 22, 2022 at 12:23:38 PM UTC+10, John W. Kennedy wrote:

On 9/21/22 9:59 PM, Robin Vowels wrote:

On Thursday, September 22, 2022 at 9:13:25 AM UTC+10, co...@ccil.org wrote: >>>> Consider this code, which may have some typos in it. Which of these numbered statements are valid?

a: PROCEDURE();
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */
END; /* b */
CALL c(); /* 1: Valid? */
CALL b();
CALL cref(); /* 2: Valid? */
CALL d();
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */
END /* a */

d: PROCEDURE();
CALL a;
STOP;
dynamic: ;
END;

0) Jumps to statically enclosing procedure
1) Calls inner inner procedure without calling sub-procedure
2) Calls inner inner procedure via procedure variable set up by inner procedure
3) Jumps to dynamically invoking procedure

.

a: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */ YES
END; /* b */
CALL c(); /* 1: Valid? */ NO, NOT WITHIN SCOPE
CALL b(); YES
CALL cref(); /* 2: Valid? */ YES
CALL d(); REQUIRES EXTERNAL ATTRIBUTE
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */ NO, NOT WITHIN SCOPE
END /* a */

d: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
CALL a;
STOP;
dynamic: ;
END;

.

0 is not valid, because it is an unreachable statement.

.
The statement GO TO STATIC; is in procedure A.
The label STATIC is in procedure A.
Therefore, the GO TO statement is legal and could transfer to
to label STATIC. LabelSTATIC is reachable from the GO TO statement.
.
The OP asked only whether the statements are valid or not,
not whether it made any sense to execute them in this skeleton program.

The problem is that there is no possible way to get TO the "GOTO static" statement in the first place, and any compiler that is not hopelessly
antique will catch this. I just tested on both clang and swiftc. I don’t
have a mainframe.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Cowan <cowan@ccil.org> wrote:

On Thursday, September 22, 2022 at 4:06:23 AM UTC-4, Robin Vowels wrote:

The OP asked only whether the statements are valid or not,
not whether it made any sense to execute them in this skeleton program.

Indeed, I ought not to have tried to present any such program, because
to get it right *and* illustrate all my points is just too hard at my current state of understanding. But let me summarize what I think I have learned:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

Not unavailing, but the results will be “unexpected.”

(b) A GOTO in a procedure X may jump to a label in X or any containing procedure at any level, but not to arbitrary procedures further
up the call stack. Presumably attempts to dodge this rule using label variables are likewise unavailing.

See above.

(c) From (a) and (b) together we can conclude that if procedure Z is directly or indirectly contained in procedure Y, then when Z is executing, Y is also on the call stack.

Yes?

Yes.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, September 23, 2022 at 5:10:43 AM UTC+10, John W. Kennedy wrote:

On 9/22/22 4:06 AM, Robin Vowels wrote:

On Thursday, September 22, 2022 at 12:23:38 PM UTC+10, John W. Kennedy wrote:

On 9/21/22 9:59 PM, Robin Vowels wrote:

On Thursday, September 22, 2022 at 9:13:25 AM UTC+10, co...@ccil.org wrote:

Consider this code, which may have some typos in it. Which of these numbered statements are valid?

a: PROCEDURE();
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */
END; /* b */
CALL c(); /* 1: Valid? */
CALL b();
CALL cref(); /* 2: Valid? */
CALL d();
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */
END /* a */

d: PROCEDURE();
CALL a;
STOP;
dynamic: ;
END;

0) Jumps to statically enclosing procedure
1) Calls inner inner procedure without calling sub-procedure
2) Calls inner inner procedure via procedure variable set up by inner procedure
3) Jumps to dynamically invoking procedure

.

a: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
DECLARE cref ENTRY VARIABLE;
b: PROCEDURE();
c: PROCEDURE()
END /* c */;
cref = c;
RETURN;
GOTO static; /* 0: Valid? */ YES
END; /* b */
CALL c(); /* 1: Valid? */ NO, NOT WITHIN SCOPE
CALL b(); YES
CALL cref(); /* 2: Valid? */ YES
CALL d(); REQUIRES EXTERNAL ATTRIBUTE
RETURN();
static: ;
GOTO dynamic; /* 3: Valid? */ NO, NOT WITHIN SCOPE
END /* a */

d: PROCEDURE(); REQUIRES RECURSIVE ATTRIBUTE
CALL a;
STOP;
dynamic: ;
END;

.

0 is not valid, because it is an unreachable statement.

.
The statement GO TO STATIC; is in procedure A.
The label STATIC is in procedure A.
Therefore, the GO TO statement is legal and could transfer to
to label STATIC. LabelSTATIC is reachable from the GO TO statement.
.
The OP asked only whether the statements are valid or not,
not whether it made any sense to execute them in this skeleton program.

.

The problem is that there is no possible way to get TO the "GOTO static"

.
We are all aware of this.
That wasn't the question asked by the OP.
.

statement in the first place, and any compiler that is not hopelessly antique will catch this. I just tested on both clang and swiftc. I don’t have a mainframe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Cowan <cowan@ccil.org> wrote:

On Thursday, September 22, 2022 at 4:06:23 AM UTC-4, Robin Vowels wrote:

The OP asked only whether the statements are valid or not,
not whether it made any sense to execute them in this skeleton program.

Indeed, I ought not to have tried to present any such program, because
to get it right *and* illustrate all my points is just too hard at my current state of understanding. But let me summarize what I think I have learned:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(b) A GOTO in a procedure X may jump to a label in X or any containing procedure at any level, but not to arbitrary procedures further
up the call stack. Presumably attempts to dodge this rule using label variables are likewise unavailing.

(c) From (a) and (b) together we can conclude that if procedure Z is directly or indirectly contained in procedure Y, then when Z is executing, Y is also on the call stack.

Yes?

(a) and (b) are false. (c) is valid and is essentially the only
restriction. Using label variables you can jump above to arbitrary
label up in call chain.

Rules for named procedures and named labels follow from lexical
scope: procedure sees what is in containing procedures. It
also sees procedures which are contained in it but does not see
inside of contained procedures. Think of procedure as a
container: if you are inside you see what is in it. From
otside you only see the container. So is you are outside a
container A (procedure A) you can not see container B
(procedure B) that is inside A.

For jump and calls via variables what matters is active
procedures. More precisely I should write about procedure
activations, there may be many activations corresponding
to the same textual procedure. Procedure activation starts
when procedure is called (recursive call creates _new_
activation). Logically activations form a stack. Normally
one speaks of stack frame corresponding to specific activation.
Normal return just removes last activation. Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

For label variables rule is that you can jump as long as procedure
containing label is active. In other words, you can jump out,
but not inside. And one procedure actication finshed all labels
in this activation are invalid. Note: labels target specific
activation. So minimally label contains address of machine
instruction and position on the stack (reference to stack
frame).

For procedure variables rule is that directly containing procedure
must be active. Again, this targets specific activation,
so procedure variable beside machine address must also contain
reference to stack frame of containing procedure. This
is related to lexical scope: to have access to variables in
containing procedure inner procedure need reference to stack
frame of containing procedrure. Note when I write "must"
I mean that to handle all cases you need extra info (or
at least some replacement). There are frequent special
cases that could be implemented easier.

You can some aspect of this looking at "man or boy" test:

https://rosettacode.org/wiki/Man_or_boy_test#PL/I

However, thanks to procedure variables and label variables
PL/I is much more powerful than required for "man or boy"
test.

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it, or any top-level procedure, but not a procedure H that is contained in some other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot
directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed; that
code may then raise ERROR and/or FINISH. Therefore the
stack cannot be removed until a jump is reached within the
ON-unit.

So minimally label contains address of machine
instruction and position on the stack (reference to stack
frame).

It actually needs to preserve the whole machine state; any
registers or flags that are live through the label must be
restored when the non-local GO TO is executed.

Question: if a file is open when the label is reached normally
and then closed before the GO TO is reached, is it automatically
reopened by the GO TO? (I hope not.)

Note when I write "must"
I mean that to handle all cases you need extra info (or
at least some replacement). There are frequent special
cases that could be implemented easier.

In general a label variable must maintain the full
information, unless the compiler can prove that there is
no non-local GO TO through this label variable, which in
the general case requires a whole-program compiler
(as when the label variable is declared EXTERNAL).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/26/22 11:56 AM, John Cowan wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it, >>> or any top-level procedure, but not a procedure H that is contained in some >>> other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot
directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed; that
code may then raise ERROR and/or FINISH. Therefore the
stack cannot be removed until a jump is reached within the
ON-unit.

So minimally label contains address of machine
instruction and position on the stack (reference to stack
frame).

It actually needs to preserve the whole machine state; any
registers or flags that are live through the label must be
restored when the non-local GO TO is executed.

Question: if a file is open when the label is reached normally
and then closed before the GO TO is reached, is it automatically
reopened by the GO TO? (I hope not.)

No. files are not on the stack in the first place. That’s why, in the OS/360–z/OS line, they are implemented using the pseudo-register vector.

Note when I write "must"
I mean that to handle all cases you need extra info (or
at least some replacement). There are frequent special
cases that could be implemented easier.

In general a label variable must maintain the full
information, unless the compiler can prove that there is
no non-local GO TO through this label variable, which in
the general case requires a whole-program compiler
(as when the label variable is declared EXTERNAL).

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot
directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actially.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR
condition nor the FINISH condition can be raised.
.

Therefore the
stack cannot be removed until a jump is reached within the
ON-unit.

So minimally label contains address of machine
instruction and position on the stack (reference to stack
frame).

It actually needs to preserve the whole machine state; any
registers or flags that are live through the label must be
restored when the non-local GO TO is executed.

Question: if a file is open when the label is reached normally
and then closed before the GO TO is reached, is it automatically
reopened by the GO TO? (I hope not.)

Note when I write "must"
I mean that to handle all cases you need extra info (or
at least some replacement). There are frequent special
cases that could be implemented easier.

In general a label variable must maintain the full
information, unless the compiler can prove that there is
no non-local GO TO through this label variable, which in
the general case requires a whole-program compiler
(as when the label variable is declared EXTERNAL).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it, >>>> or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot
directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actially.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR
condition nor the FINISH condition can be raised.

Not so. CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.

Therefore the
stack cannot be removed until a jump is reached within the
ON-unit.

So minimally label contains address of machine
instruction and position on the stack (reference to stack
frame).

It actually needs to preserve the whole machine state; any
registers or flags that are live through the label must be
restored when the non-local GO TO is executed.

Question: if a file is open when the label is reached normally
and then closed before the GO TO is reached, is it automatically
reopened by the GO TO? (I hope not.)

Note when I write "must"
I mean that to handle all cases you need extra info (or
at least some replacement). There are frequent special
cases that could be implemented easier.

In general a label variable must maintain the full
information, unless the compiler can prove that there is
no non-local GO TO through this label variable, which in
the general case requires a whole-program compiler
(as when the label variable is declared EXTERNAL).

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot
directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR
condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as
terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition
was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition
was raised. Instead the ERROR condition is raised, and then (directly
or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote: >>>> On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus >>>> stack discipline, and is a restatement of what you said. You cannot
directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR
condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition
was raised. Instead the ERROR condition is raised, and then (directly
or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 29, 2022 at 10:10:53 AM UTC+10, John W. Kennedy wrote:

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus >>>> stack discipline, and is a restatement of what you said. You cannot
directly call G from E, and even if you have a variable containing G, >>>> you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR
condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition
was raised. Instead the ERROR condition is raised, and then (directly
or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

.
What manual are you reading?
.
OVERFLOW CONDTION
Implicit action: A message is printed and the ERROR condition is raised.
Normal return: Control returns to the point immediately following the point at which the condition was raised.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/28/22 10:39 PM, Robin Vowels wrote:

On Thursday, September 29, 2022 at 10:10:53 AM UTC+10, John W. Kennedy wrote:

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus >>>>>> stack discipline, and is a restatement of what you said. You cannot >>>>>> directly call G from E, and even if you have a variable containing G, >>>>>> you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR
condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as
terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition >>> was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition
was raised. Instead the ERROR condition is raised, and then (directly
or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

.
What manual are you reading?
.
OVERFLOW CONDTION
Implicit action: A message is printed and the ERROR condition is raised. Normal return: Control returns to the point immediately following the point at
which the condition was raised.

The newest one. (6.1, I think.) It says very plainly that “normal
return” means that the on-unit falls out the bottom, and that what
happens after that depends on the condition, and the rules for each
condition are listed under that condition.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Cowan <cowan@ccil.org> wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said.

There can be intermadiate levels between toplevel and current procedure
and you can call them. Have you looked at "man or boy" test? In
the test toplevel procedure is 'morb', it contains 'a' (so 'a' is
not toplevel), 'a' contains 'b' (and 'b' does not contain 'a'),
'b' calls 'a'.

And you can use procedure variables to call procedures that are
not visible lexically.

You cannot
directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

They are or are not depending on program history. Of course, if
you mean specific trival program that contains nothing more than
procedures that you mention, then your statement is true, but it
is then statement about specific program, not a general rule that
I gave you.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed; that
code may then raise ERROR and/or FINISH. Therefore the
stack cannot be removed until a jump is reached within the
ON-unit.

Yes.

So minimally label contains address of machine
instruction and position on the stack (reference to stack
frame).

It actually needs to preserve the whole machine state; any
registers or flags that are live through the label must be
restored when the non-local GO TO is executed.

Yes. I wrote "minimally". PL1/F saves all registers to
save area on logical stack (more precisely, this is a linked
list, but is used as a stack). Having just pointer to stack
frame PL1/F can restore all registers. Other compilers may
do this differently and may need to store registers with
label. IIUC gcc implements nonlocal jumps ('setjmp' and 'longjmp')
in a way that stores small number of "critical" registers
in C-s equvalent of label ('jmp_buf').

Note when I write "must"
I mean that to handle all cases you need extra info (or
at least some replacement). There are frequent special
cases that could be implemented easier.

In general a label variable must maintain the full
information, unless the compiler can prove that there is
no non-local GO TO through this label variable, which in
the general case requires a whole-program compiler
(as when the label variable is declared EXTERNAL).

As I wrote, there as special cases. For example, if label
variable does not leak from given procedure, that just
looking at the procedure you can decide that all jumps
using this label will be local. IIRC PL1/F used simpler
representation of label used only for local jumps. Many
program contain only toplevel procedures, that simplify
quite a lot problems with implementing runtime aspects of
lexical scope. Or program may contain nested procedures
but only in trivial way, that is nested procedure only
uses its own variables or toplevel variables, but
no variables from intermediate scopes (it can still
call procedures at intermediate scopes). Such
special cases are easy to detect. OTOH it is not
clear if you _want_ to detect them: you still need
code for general case and if simpler cases are handled
by special code, then testing code handling general
case is harder.

In case of jumps replacing calls by copy of called
procedure (inline expansion) may turn nonlocal
jumps into local ones (OTOH old version of gcc
would not do inline expansion for functions
containing nonlocal jumps).

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John W Kennedy <john.w.kennedy@gmail.com> wrote:

On 9/28/22 10:39 PM, Robin Vowels wrote:

On Thursday, September 29, 2022 at 10:10:53 AM UTC+10, John W. Kennedy wrote:

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus >>>>>>> stack discipline, and is a restatement of what you said. You cannot >>>>>>> directly call G from E, and even if you have a variable containing G, >>>>>>> you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains,
but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR
condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as
terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition
was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition
was raised. Instead the ERROR condition is raised, and then (directly
or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

.
What manual are you reading?
.
OVERFLOW CONDTION
Implicit action: A message is printed and the ERROR condition is raised.
Normal return: Control returns to the point immediately following the point at
which the condition was raised.

The newest one. (6.1, I think.) It says very plainly that “normal
return” means that the on-unit falls out the bottom, and that what
happens after that depends on the condition, and the rules for each
condition are listed under that condition.

Previous manuals agree with Robin. I really hope IBM didn’t change the language spec.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/30/22 2:51 PM, Peter Flass wrote:

John W Kennedy <john.w.kennedy@gmail.com> wrote:

On 9/28/22 10:39 PM, Robin Vowels wrote:

On Thursday, September 29, 2022 at 10:10:53 AM UTC+10, John W. Kennedy wrote:

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus >>>>>>>> stack discipline, and is a restatement of what you said. You cannot >>>>>>>> directly call G from E, and even if you have a variable containing G, >>>>>>>> you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains, >>>>>>>>> but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR
condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as
terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition
was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition
was raised. Instead the ERROR condition is raised, and then (directly >>>>> or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

.
What manual are you reading?
.
OVERFLOW CONDTION
Implicit action: A message is printed and the ERROR condition is raised. >>> Normal return: Control returns to the point immediately following the point at
which the condition was raised.

The newest one. (6.1, I think.) It says very plainly that “normal
return” means that the on-unit falls out the bottom, and that what
happens after that depends on the condition, and the rules for each
condition are listed under that condition.

Previous manuals agree with Robin. I really hope IBM didn’t change the language spec.

IBM’s Language Spec hasn’t changed since 1968.

The IBM Language Reference has been this way at least since 3.5 in 2005. Unfortunately, I haven’t anything going back years before that.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John W Kennedy <john.w.kennedy@gmail.com> wrote:

On 9/30/22 2:51 PM, Peter Flass wrote:

John W Kennedy <john.w.kennedy@gmail.com> wrote:

On 9/28/22 10:39 PM, Robin Vowels wrote:

On Thursday, September 29, 2022 at 10:10:53 AM UTC+10, John W. Kennedy wrote:

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot >>>>>>>>> directly call G from E, and even if you have a variable containing G, >>>>>>>>> you cannot invoke it directly from E because the AUTOMATIC
variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains, >>>>>>>>>> but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR
condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as >>>>>> terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition
was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition >>>>>> was raised. Instead the ERROR condition is raised, and then (directly >>>>>> or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

.
What manual are you reading?
.
OVERFLOW CONDTION
Implicit action: A message is printed and the ERROR condition is raised. >>>> Normal return: Control returns to the point immediately following the point at
which the condition was raised.

The newest one. (6.1, I think.) It says very plainly that “normal
return” means that the on-unit falls out the bottom, and that what
happens after that depends on the condition, and the rules for each
condition are listed under that condition.

Previous manuals agree with Robin. I really hope IBM didn’t change the
language spec.

IBM’s Language Spec hasn’t changed since 1968.

The IBM Language Reference has been this way at least since 3.5 in 2005. Unfortunately, I haven’t anything going back years before that.

On reconsideration, I think you’re right. I have old manuals going back to the original PL/I spec and the PL/I(F) manuals (but only version 5, I
believe) but I haven’t had a chance to check yet.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/1/22 6:19 PM, Peter Flass wrote:

John W Kennedy <john.w.kennedy@gmail.com> wrote:

On 9/30/22 2:51 PM, Peter Flass wrote:

John W Kennedy <john.w.kennedy@gmail.com> wrote:

On 9/28/22 10:39 PM, Robin Vowels wrote:

On Thursday, September 29, 2022 at 10:10:53 AM UTC+10, John W. Kennedy wrote:

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot >>>>>>>>>> directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC >>>>>>>>>> variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains, >>>>>>>>>>> but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally,
it returns to the point where the condition was SIGNALed;

.
Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR >>>>>>>>> condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as >>>>>>> terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition
was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition >>>>>>> was raised. Instead the ERROR condition is raised, and then (directly >>>>>>> or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

.
What manual are you reading?
.
OVERFLOW CONDTION
Implicit action: A message is printed and the ERROR condition is raised. >>>>> Normal return: Control returns to the point immediately following the point at
which the condition was raised.

The newest one. (6.1, I think.) It says very plainly that “normal
return” means that the on-unit falls out the bottom, and that what
happens after that depends on the condition, and the rules for each
condition are listed under that condition.

Previous manuals agree with Robin. I really hope IBM didn’t change the >>> language spec.

IBM’s Language Spec hasn’t changed since 1968.

The IBM Language Reference has been this way at least since 3.5 in 2005.
Unfortunately, I haven’t anything going back years before that.

On reconsideration, I think you’re right. I have old manuals going back to the original PL/I spec and the PL/I(F) manuals (but only version 5, I believe) but I haven’t had a chance to check yet.

The Optimizer/Checkout Language Reference for 1974 gives the old rule. I
wish I had an OS/2 manual (the first public form of the Toronto
compiler) to see whether the change went in then. Other obvious
possibilities would be the introduction of the Toronto compiler to
OS/390 or whenever IEEE-740 support was added.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John W Kennedy <john.w.kennedy@gmail.com> wrote:

On 10/1/22 6:19 PM, Peter Flass wrote:

John W Kennedy <john.w.kennedy@gmail.com> wrote:

On 9/30/22 2:51 PM, Peter Flass wrote:

John W Kennedy <john.w.kennedy@gmail.com> wrote:

On 9/28/22 10:39 PM, Robin Vowels wrote:

On Thursday, September 29, 2022 at 10:10:53 AM UTC+10, John W. Kennedy wrote:

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl
wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot >>>>>>>>>>> directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC >>>>>>>>>>> variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains, >>>>>>>>>>>> but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally, >>>>>>>>>>> it returns to the point where the condition was SIGNALed; >>>>>>>>>> .

Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR >>>>>>>>>> condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as >>>>>>>> terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition
was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition >>>>>>>> was raised. Instead the ERROR condition is raised, and then (directly >>>>>>>> or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

.
What manual are you reading?
.
OVERFLOW CONDTION
Implicit action: A message is printed and the ERROR condition is raised. >>>>>> Normal return: Control returns to the point immediately following the point at
which the condition was raised.

The newest one. (6.1, I think.) It says very plainly that “normal
return” means that the on-unit falls out the bottom, and that what >>>>> happens after that depends on the condition, and the rules for each
condition are listed under that condition.

Previous manuals agree with Robin. I really hope IBM didn’t change the >>>> language spec.

IBM’s Language Spec hasn’t changed since 1968.

The IBM Language Reference has been this way at least since 3.5 in 2005. >>> Unfortunately, I haven’t anything going back years before that.

On reconsideration, I think you’re right. I have old manuals going back to >> the original PL/I spec and the PL/I(F) manuals (but only version 5, I
believe) but I haven’t had a chance to check yet.

The Optimizer/Checkout Language Reference for 1974 gives the old rule. I
wish I had an OS/2 manual (the first public form of the Toronto
compiler) to see whether the change went in then. Other obvious
possibilities would be the introduction of the Toronto compiler to
OS/390 or whenever IEEE-740 support was added.

I have it, I’ll check.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 2, 2022 at 9:19:30 AM UTC+11, bearlyabus...@gmail.com wrote:

John W Kennedy <john.w....@gmail.com> wrote:

On 9/30/22 2:51 PM, Peter Flass wrote:

John W Kennedy <john.w....@gmail.com> wrote:

On 9/28/22 10:39 PM, Robin Vowels wrote:

On Thursday, September 29, 2022 at 10:10:53 AM UTC+10, John W. Kennedy wrote:

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot
directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC >>>>>>>>> variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains, >>>>>>>>>> but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally, >>>>>>>>> it returns to the point where the condition was SIGNALed;

.
Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR >>>>>>>> condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as >>>>>> terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition
was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition >>>>>> was raised. Instead the ERROR condition is raised, and then (directly >>>>>> or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

.
What manual are you reading?
.
OVERFLOW CONDTION
Implicit action: A message is printed and the ERROR condition is raised.
Normal return: Control returns to the point immediately following the point at
which the condition was raised.

The newest one. (6.1, I think.) It says very plainly that “normal
return” means that the on-unit falls out the bottom, and that what
happens after that depends on the condition, and the rules for each
condition are listed under that condition.

Previous manuals agree with Robin. I really hope IBM didn’t change the >> language spec.

IBM’s Language Spec hasn’t changed since 1968.

The IBM Language Reference has been this way at least since 3.5 in 2005. Unfortunately, I haven’t anything going back years before that.

On reconsideration, I think you’re right. I have old manuals going back to the original PL/I spec and the PL/I(F) manuals (but only version 5, I believe) but I haven’t had a chance to check yet.

.
The early IBM PL/I manuals C28-6571-1 and -3 are not specific about
this. Current IBM one says that upon normal return from the OVERFLOW
ON-unit, the ERROR condition is raised, so it seems that there has been
a change there.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/2/22 10:00 AM, Robin Vowels wrote:

On Sunday, October 2, 2022 at 9:19:30 AM UTC+11, bearlyabus...@gmail.com wrote:

John W Kennedy <john.w....@gmail.com> wrote:

On 9/30/22 2:51 PM, Peter Flass wrote:

John W Kennedy <john.w....@gmail.com> wrote:

On 9/28/22 10:39 PM, Robin Vowels wrote:

On Thursday, September 29, 2022 at 10:10:53 AM UTC+10, John W. Kennedy wrote:

On 9/28/22 6:46 AM, Robin Vowels wrote:

On Wednesday, September 28, 2022 at 8:41:33 AM UTC+10, John W. Kennedy wrote:

On 9/26/22 10:08 PM, Robin Vowels wrote:

On Tuesday, September 27, 2022 at 1:56:20 AM UTC+10, co...@ccil.org wrote:

On Sunday, September 25, 2022 at 9:40:13 PM UTC-4, anti...@math.uni.wroc.pl wrote:

(a) A procedure E may call a procedure F that is directly contained in it,
or any top-level procedure, but not a procedure H that is contained in some
other procedure G, even if G is F. Attempts to dodge this rule using procedure
variables are unavailing.

(a) and (b) are false.

I don't see how (a) can be false: it follows from lexical scoping plus
stack discipline, and is a restatement of what you said. You cannot >>>>>>>>>>> directly call G from E, and even if you have a variable containing G,
you cannot invoke it directly from E because the AUTOMATIC >>>>>>>>>>> variables of F are not on the stack.

.
The stack is irrelevant. There could be STATIC variables.

Jumps (or exceptions)
remove all activations from source to target (target remains, >>>>>>>>>>>> but anything below target is removed).

Jumps, yes; exceptions, no. If an ON-unit exits normally, >>>>>>>>>>> it returns to the point where the condition was SIGNALed; >>>>>>>>>> .

Raised, actually.
.

that code may then raise ERROR and/or FINISH.

.
If the return from the ON-unit was normal, neither the ERROR >>>>>>>>>> condition nor the FINISH condition can be raised.

.

Not so.

.
Exactly so. This occurs for all conditions that are not regarded as >>>>>>>> terminal, such as UNDERFLOW, OVERFLOW, STRINGSIZE, etc.
Normal return is to a point immediately after the point where the condition
was raised. The ERROR condition cannot be raised, as I said.
.
For serious errors, such as SUBSCRIPTRANGE, control does not
return to the point immedately after the point where the condition >>>>>>>> was raised. Instead the ERROR condition is raised, and then (directly >>>>>>>> or indirectly) the FINISH condition is raised.
.

CONDITION, INVALIDOP, OVERFLOW, STORAGE, SUBSCRIPTRANGE,
UNDERFLOW (IEEE only), and ZERODIVIDE all raise ERROR.

.
OVERFLOW and ZERODIVIDE do not raise ERROR when there is an
active ON-unit in force. It is treated like UNDERFLOW.

That is not the definition of "Normal return" that the Language
Reference manual uses. For example:

OVERFLOW condition
...
Normal return
The ERROR condition is raised.

.
What manual are you reading?
.
OVERFLOW CONDTION
Implicit action: A message is printed and the ERROR condition is raised. >>>>>> Normal return: Control returns to the point immediately following the point at
which the condition was raised.

The newest one. (6.1, I think.) It says very plainly that “normal
return” means that the on-unit falls out the bottom, and that what >>>>> happens after that depends on the condition, and the rules for each
condition are listed under that condition.

Previous manuals agree with Robin. I really hope IBM didn’t change the >>>> language spec.

IBM’s Language Spec hasn’t changed since 1968.

The IBM Language Reference has been this way at least since 3.5 in 2005. >>> Unfortunately, I haven’t anything going back years before that.

On reconsideration, I think you’re right. I have old manuals going back to >> the original PL/I spec and the PL/I(F) manuals (but only version 5, I
believe) but I haven’t had a chance to check yet.

.
The early IBM PL/I manuals C28-6571-1 and -3 are not specific about
this. Current IBM one says that upon normal return from the OVERFLOW ON-unit, the ERROR condition is raised, so it seems that there has been
a change there.

And the same for 1968’s Y33-6003-0, the last version ever of the
Language Specification manual. So the question of what happens on a
normal return seems never to have been addressed in IBM’s Language Specification.

However,the Language Reference Manual for F (probably the last update), 1972’s GC28-8201-4, specifies return to the last point of interrupt.

The Language Reference Manual for Optimizer/Checkout (1974) specifies
the same.

But at some point between that and the 3.5 version of the Toronto
compiler (2005), it changed. Unfortunately, that’s a 31-year gap. My
best guess (but it is only a guess) is that the change came with the
OS/2 compiler, the port of the Toronto compiler to OS/390, or the
mainframe implementation of IEEE-754.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)