ARRAY ARITHMETIC IN PL/I

[Robin Vowels]

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

[John W Kennedy]

Even the Checkout Compiler does not specifically list an ONCODE for it.
All IBM compilers going back to F specifically say that it is not
allowed, but I can find no documentation that it’s specifically checked.
They may have supposed that it’s too improbable, given that any sensible
user will check either file input or parameter values early on, so as to
give a meaningful diagnostic.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

[Iron Spring Software]

On 6/5/21 12:51 PM, John W Kennedy wrote:
> On 6/5/21 12:03 AM, Robin Vowels wrote:
>> In whole-array operations, IBM's Windows compiler does not check
>> that arrays are compatible.
>> Even if SUBSCRIPTRANGE  is enabled, there is no check.
>> Have there been any PL/I compilers that performed such a check?
>
>
> Even the Checkout Compiler does not specifically list an ONCODE for it.
> All IBM compilers going back to F specifically say that it is not
> allowed, but I can find no documentation that it’s specifically checked.
> They may have supposed that it’s too improbable, given that any sensible
> user will check either file input or parameter values early on, so as to
> give a meaningful diagnostic.
>

I learned not to count on sensible users sometime during my first
programming job!

I suppose someone could fire up "F" on Hercules to see what happens, but
in my experience IBM cut quite a few corners with the Enterprise
compilers. Some of them they fixed as they went along, but maybe not all.

[John W Kennedy]

Well, all I know for sure is that no IBM compiler seems to have an
ONCODE for the situation. I can’t find a run-time error message, either,
but I have not tried to search the Checkout Compiler messages because I
have only an image of the manual, and it’s just to long to search by eye.

[Robin Vowels]

On Sunday, June 6, 2021 at 5:51:11 AM UTC+10, John W. Kennedy wrote:
> On 6/5/21 12:03 AM, Robin Vowels wrote:
> > In whole-array operations, IBM's Windows compiler does not check
> > that arrays are compatible.
> > Even if SUBSCRIPTRANGE is enabled, there is no check.
> > Have there been any PL/I compilers that performed such a check?

.

> Even the Checkout Compiler does not specifically list an ONCODE for it.

.
Any condition that is raised should be the SUBSCRIPTRANGE condition,
of course.

.
> All IBM compilers going back to F specifically say that it is not
> allowed,

.
The bounds of arrays must be identical.
.

> but I can find no documentation that it’s specifically checked.
> They may have supposed that it’s too improbable,

.
Given that the equivalent operation is spelled out in terms of
loops, one would expect that SUBSCRIPTRANGE be raised
when the equivalent code experiences a subscript out of range
for an array whose bounds do not conform.
.
At the very least, any bounds check ought to be carried out
once prior to executing code for the operation.
.

> given that any sensible
> user will check either file input or parameter values early on, so as to
> give a meaningful diagnostic.

.
A user would only know to include such a check if it were stated in the manual
that a check would not be carried out by the compiler. (or, if he/she
discovered it by accident).

[John W Kennedy]

The specification of SUBSCRIPTRANGE speaks of the evaluation of the
subscript. But in an array operation, there is no subscript variable
visible to the user. And the object code penalty would be obscene to
evaluate each individual case when it can be checked by LBOUND = LBOUND
and HBOUND = HBOUND. As far as I can tell, IBM PL/I has worked the way
it does now for over 50 years, so I don’t think you’ll see a change, but
if you want to submit it to IBM, you’re welcome to try. And I suggest
you suggest, at least as a alternative, a new ON-condition, perhaps to
be named ARRAYRANGE or at least a new ONCODE value. (I’m in no position
to do it; I have 30 years of experience with PL/I on DOS/360 and OS/360
and their descendants (and a little on OS/2), but I live in the Apple
world nowadays, and am far more interested in Swift and Cocoa.

> At the very least, any bounds check ought to be carried out
> once prior to executing code for the operation.
> .
>> given that any sensible
>> user will check either file input or parameter values early on, so as to
>> give a meaningful diagnostic.
> .
> A user would only know to include such a check if it were stated in the manual
> that a check would not be carried out by the compiler. (or, if he/she
> discovered it by accident).

Still smarter to do reasonableness checks first, so that the data error
is expressed to the user in a user-readable form that explains that
there is an input error, instead of a mysterious IBM error message that
can only be interpreted by the original programmer.

[Robin Vowels]

.
But it is specified to the user in the detailed explanation of
such an array operation. So would still be appropriate to raise
the SUBSCRIPTRANGE condition.

> And the object code penalty would be obscene to
> evaluate each individual case

.
No need to evaluate each individual case.
In any case, even if this were done, it would not be any worse
compared with the equivalent piece of code written with
explicit DO loops.
.

> when it can be checked by LBOUND = LBOUND
> and HBOUND = HBOUND.

.
Of course it can, and that is the obvious way to do it (as I already
suggested below).

.
> As far as I can tell, IBM PL/I has worked the way
> it does now for over 50 years, so I don’t think you’ll see a change, but
> if you want to submit it to IBM, you’re welcome to try. And I suggest
> you suggest, at least as a alternative, a new ON-condition, perhaps to
> be named ARRAYRANGE or at least a new ONCODE value.

.
No need to introduce yet more conditions / keywords.

.
> (I’m in no position
> to do it; I have 30 years of experience with PL/I on DOS/360 and OS/360
> and their descendants (and a little on OS/2), but I live in the Apple
> world nowadays, and am far more interested in Swift and Cocoa.
.
> > At the very least, any bounds check ought to be carried out
> > once prior to executing code for the operation.
> > .
> >> given that any sensible
> >> user will check either file input or parameter values early on, so as to
> >> give a meaningful diagnostic.
> > .
> > A user would only know to include such a check if it were stated in the manual
> > that a check would not be carried out by the compiler. (or, if he/she
> > discovered it by accident).
.
> Still smarter to do reasonableness checks first,

.
but only if the programmer sees such limitation spelled out in the manual --
which it wasn't (or discovered it by accident).
.
In the case of procedures to which arguments might be passed,
it's very sensible to do that.
.

> so that the data error
> is expressed to the user in a user-readable form that explains that
> there is an input error,

.
Indeed.
.

> instead of a mysterious IBM error message that
> can only be interpreted by the original programmer.

.
It can be interpreted by any programmer.

[Thomas David Rivers]

Hi Robin,

If you post an example we can try it with the current IBM compiler.

- Dave R. -

--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

[Robin Vowels]

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:
> Robin Vowels wrote:
>
> >In whole-array operations, IBM's Windows compiler does not check
> >that arrays are compatible.
> >Even if SUBSCRIPTRANGE is enabled, there is no check.
> >Have there been any PL/I compilers that performed such a check?
> >
> >
> Hi Robin,
>
> If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

[Peter Flass]

What happens if you do A=B+C; in the main procedure, without a call to
ARITH?

--
Pete

[Robin Vowels]

.
I tried that as well. As expected, a compilation error message.
.
S: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,5) FLOAT, C(5,6) FLOAT;
B = 1; C= 2;

A = B + C;

PUT LIST (A);

END S;

[Thomas David Rivers]

I compiled this on z/OS 2.4 with this version of IBM PL/I:


15655-PL5 IBM(R) Enterprise PL/I for z/OS V5.R3.M0 (Built:20190726)

and I got no errors, no warnings.

When I run it though, I get this:


About to perform addition
IBM0421S ONCODE=520 The SUBSCRIPTRANGE condition was raised.
From entry point ARITH at compile unit offset +000003FE at
entry offset +000003FE at address 1F90B62E.
[1] + Done(137) ./incompat_array
50397979 Killed ./incompat_array

(under USS, which is why it's "Killed").

[Jessica Colman]

I can confirm Dave (same architecture, slightly minor compiler level):

IBM0421S ONCODE=520 The SUBSCRIPTRANGE condition was raised.

From compile unit T at entry point ARITH at statement 10 at
compile unit offset +000005BA at entry offset
+0000040A at address 20400DE2.
<> LEAID ENTERED (LEVEL 02/26/2016 AT 17.55)
<> LEAID PROCESSING COMPLETE. RC=0

Jessica

[Peter Flass]

That’s what I would have expected. Without extensive code analysis, that
probably no compiler does it, would have been impossible to detect the
error until runtime.

--
Pete

[Robin Vowels]

.
Thanks, Dave. It's a considerable improvement over PL/I-F and PL/I for Windows.
Would it be possible to post the assembly listing?
(If it would be too long, please email me.) Many thanks.

[carlos feldman]

Actually it has no meaning in math or phisicaly to multipy 2 arrays of incompatible size, so why bother?
The only thing I think of is multiplying one array of measurements, by some weight coeffcient, for digital filtering, even a 2 dimmension. But since the size is declared previously it's trivial to check them before using it

[Peter Flass]

I’ve seen all kinds of bad code that doesn’t check things. Heck, I’ve
WRITTEN lots of bad code. It’s always better for the compiler to check
whatever it can and not depend on the user. PL/i (among other languages, I
guess) is nice because it allows the programmer to turn off these checks to
improve efficiency when desired, assuming that they make sure to do the
checks themselves.

--
Pete

[Robin Vowels]

.
It's still necessary to check that the bounds are compatible.
.
Without a check, wrong results are guaranteed, or none at all.
.

> The only thing I think of is multiplying one array of measurements, by some weight coeffcient,
> for digital filtering, even a 2 dimmension. But since the size is declared previously it's trivial
> to check them before using it

.
Cross-sections of arrays are often required in solving equations, matrix inversion, etc.

[Robin Vowels]

On Tuesday, June 15, 2021 at 4:02:51 AM UTC+10, bearlyabus...@gmail.com wrote:

> carlos feldman <carlf...@gmail.com> wrote:

> > Actually it has no meaning in math or phisicaly to multipy 2 arrays of
> > incompatible size, so why bother?
> > The only thing I think of is multiplying one array of measurements, by
> > some weight coeffcient, for digital filtering, even a 2 dimmension. But
> > since the size is declared previously it's trivial to check them before using it
>
> I’ve seen all kinds of bad code that doesn’t check things.

.
Remember Murphy's Law? "If anything can go wrong it will."
.
And then there's Roberts's Law: "Even if it can't go wrong it will."
.
Recall the Ariadne disaster? It failed because they did not include
a check for integer overflow.

[carlos feldman]

that's part of debugging the code, thing is most programmers, forget they are working in real environments, and don't do real testing, where things happens. Like calculating a PID in metric units ans a process expecting imperial units ?

[peter....@gmail.com]

Sorry I'm so late, I finally got around to checking.

Iron Spring PL/I checks. For non-adjustable arrays it causes an error at compile time:
"(ERR418)Mismatched array dimension or bounds in assignment statement."

For adjustable arrays it raises the ERROR condition at execution time. I guess the consensus is that it should be SUBSCRIPTRANGE if enabled. It probably should raise ERROR if SUBSCRIPTRANGE is not enabled?

[peter....@gmail.com]

My bad, this was for assignments. I don't yet do array arithmetic, that's still upcoming, but the behavior will be the same as for assignments.

[Robin Vowels]

On Saturday, July 3, 2021 at 2:22:56 AM UTC+10, peter....@gmail.com wrote:
> On Friday, June 4, 2021 at 9:03:13 PM UTC-7, Robin Vowels wrote:
> > In whole-array operations, IBM's Windows compiler does not check
> > that arrays are compatible.
> > Even if SUBSCRIPTRANGE is enabled, there is no check.
> > Have there been any PL/I compilers that performed such a check?
> Sorry I'm so late, I finally got around to checking.
>
> Iron Spring PL/I checks. For non-adjustable arrays it causes an error at compile time:
> "(ERR418)Mismatched array dimension or bounds in assignment statement."

.
Very good.
.

> For adjustable arrays it raises the ERROR condition at execution time.

.
If any condition can be raised, it should be the SUBSCRIPTRANGE condition.
.
The normal action from that is to raise the ERROR condition.

> I guess the consensus is that it should be SUBSCRIPTRANGE if enabled.

.
Indeed so.

.
> It probably should raise ERROR if SUBSCRIPTRANGE is not enabled?

.
In IBM's compilers, anything can happen if SUBRG is not enabled
and a subscript is out of bounds.