Restrictions of Subset G

[John Cowan]

Syntactic restrictions:
Only one label prefix with only one subscript
Condition prefixes on procedure and begin statements
End statements close only one group or block
No comma-lists in do statements
Assignment statements must have only one target
Get and put statements: one I/O list, zero or one format list
No third value for E and F format items
Into and from options on record I/O statements must not be unaligned
No dimensioned file constants
Unaligned types must be strings
Pictures must not be aligned
Static variables must not be initialized to constant labels, entries, or files
Automatic initializer for a dimensioned variable must have * iteration
No negative scale factors
Non-zero scale factors for FIXED DECIMAL only
No format constants except labels on format statements
Max and min: only two arguments
Pseudo-variables only on the left side of assignment statements
All precision, scale, or number-of-digits arguments must be
integers or defined constants

Semantic restrictions:
All functions yield scalar values
Do control variable must be arithmetic or pointer
If, while, or until expression must be bit string of length 1
Unconnected arrays cannot be passed as arguments
No return statements within on statements
All names must be declared except SYSIN, SYSOUT, and labels
All parameters and return types must be specified
All overlays must have identical type and extents, or be strings
Refer, if present, must appear at the end of a structure
Subscripts and extents must be integers
No conversions between arithmetic/pictured values and string values
No conversions between bit strings and character strings
No conversions between pointers and offsets except via addr function
Aggregate assignment must be between connected storage
of the same type

Excluded features:
default statement, entry statement,
binary constants, replicated string constants
conditions: name, stringrange, stringsize, subscriptrange
assignment by name
locate statement
open keyword: tab
get/put keyword: data
get keyword: copy
read keyword: ignore
c format item
attributes: complex, controlled, generic, like, local, position
picture characters: a, e, i, k, r, t, x, y
bit varying
iSUB defining
format variables

[Robin Vowels]

Again, the committee had no idea what it was doing to exclude these.
SUBSTR is essential in any program using arrays.
STRINGSIZE and STRINGRANGE are essential for the same reason
in string-handling.
Their omissions would take us back to the says of FORTRAN IV,
when stepping past the bounds of an array went undetected
and difficult to find.
.

> assignment by name
> locate statement
> open keyword: tab
> get/put keyword: data

.
Obviously the Committee had no idea what the facility was used for.
.

> get keyword: copy
> read keyword: ignore
> c format item
> attributes: complex, controlled, generic, like, local, position

.
Omitting COMPLEX and CONTROLLED would produce a mickey-mouse
language of little practical value.
.
Can't write a generic function? Ridiculous!
.

> picture characters: a, e, i, k, r, t, x, y
> bit varying
> iSUB defining

.
There are specific uses for iSUB that simplify programming.
One is to define an array that omits all the border elements.
.
IBM omitted iSUB from PL/I for OS/2, but put it in
upon request from user(s).

> format variables

[Peter Flass]

John Cowan <co...@ccil.org> wrote:
> Syntactic restrictions:
> default statement, entry statement

ENTRY statement is a misfeature anyway. Packages, introduced in subset G,
IIRC, are a much better way to achieve the same result.

There’s no way statically to relate an ENTRY statement to a RETURN, so all
RETURNS must be able to return any of the possible data types.

--
Pete

[Peter Flass]

Robin Vowels <robin....@gmail.com> wrote:
>
> Can't write a generic function? Ridiculous!

Your milage may vary, but I never found GENERIC to be of any use. It struck
me as a half-hearted attempt at object-oriented programming, but basically
it’s a form of macro.
>
--
Pete

[John Cowan]

On Sunday, September 11, 2022 at 8:27:55 PM UTC-4, Robin Vowels wrote:

> > conditions: name, stringrange, stringsize, subscriptrange

> Again, the committee had no idea what it was doing to exclude these.
> SUBSTR is essential in any program using arrays.
> STRINGSIZE and STRINGRANGE are essential for the same reason
> in string-handling.

Appendix D, which my post is a precis of, excludes them as "debugging conditions", which are useful in testing code that may be buggy, but not useful in production code.

> Their omissions would take us back to the says of FORTRAN IV,
> when stepping past the bounds of an array went undetected
> and difficult to find.

Not at all. It is one thing to detect an error, another to provide a way to intercept the error and take corrective action, which is why you need a CONDITION. Compilers have two possibilities in the absence of these conditions: one is to raise an ERROR condition with a suitable ONCODE, and another is to log the error and have the program fail. A third is to let the program dance the fandango on core, but that is certainly not a requirement.

(That said, I have never been happy with the idea of having such tests in debug mode but removing them from production code: I think it was Fred Brooks who said it was like carrying lifeboats while you were tooling around the harbor and leaving them behind when you headed out to sea.)

> > get/put keyword: data

> Obviously the Committee had no idea what the facility was used for.

The Committee's job was not to remove useless features: every feature is useful to some programmer for writing some program, and generally more than one of each, or it wouldn't have been included. Their job was to remove features that, in their expert judgement, cost more (implicitly: under the conditions of programming 35 years ago) than the benefits they provided to the PL/I community as a whole. I assume the cost in question was runtime memory, something that isn't nearly as expensive as it was then.

Note also that the motivation for the 1987 revision of Subset G, which is what I'm working from, was primarily to add back features omitted from the original 1981 version that made the language excessively spare. Perhaps a later revision, if there had been one, would have added back GET/PUT DATA as memory restrictions loosened over time. That no such revision ever happened is beyond anyone's control today.

> > attributes: complex, controlled, generic, like, local, position
> .
> Omitting COMPLEX and CONTROLLED would produce a mickey-mouse
> language of little practical value.

To say that is to ignore the history of the last 45 years, my entire career in the trenches as a professional programmer, during which time I have used many, many languages and never needed either feature. Scientific programming is a niche, and in a relative sense is a smaller niche than ever. See above concerning costs and benefits. As for private stack allocation, which is what makes CONTROLLED unique, AREA seems to me to subsume much of that. (If this is not so, or anything else I say is wrong, please let me know.)

That said, I certainly do not scorn complex numbers, even if they represent half the arithmetic types of PL/I, which is why I proposed adding back COMPLEX FLOAT, far and away the typical use case.

> > iSUB defining
> .
> There are specific uses for iSUB that simplify programming.
> One is to define an array that omits all the border elements.

See above re: tradeoffs. I may have added this to my list with the restriction that it must specify a contiguous portion of the base array.

[Peter Flass]

John Cowan <co...@ccil.org> wrote:

First, I’d like to say that I’m happy to see this discussion about the
language. It’s like a breath of fredh air.

> On Sunday, September 11, 2022 at 8:27:55 PM UTC-4, Robin Vowels wrote:
>
>>> conditions: name, stringrange, stringsize, subscriptrange
>
>> Again, the committee had no idea what it was doing to exclude these.
>> SUBSTR is essential in any program using arrays.
>> STRINGSIZE and STRINGRANGE are essential for the same reason
>> in string-handling.
>
> Appendix D, which my post is a precis of, excludes them as "debugging
> conditions", which are useful in testing code that may be buggy, but not
> useful in production code.

IMNSHO, as a long-time PL/I programmer, STRINGSIZE is completely useless.
The good thing about PL/I string handling, as opposed to C et.al. is the
ability to move strings around without considerations of size, and have
generated code truncate or pad as necessary. I don’t use STRINGRANGE and
SUBSCRIPTRANGE very often. Where necessary I’ll code my own subscript
checks.

>
>> Their omissions would take us back to the says of FORTRAN IV,
>> when stepping past the bounds of an array went undetected
>> and difficult to find.
>
> Not at all. It is one thing to detect an error, another to provide a way
> to intercept the error and take corrective action, which is why you need
> a CONDITION. Compilers have two possibilities in the absence of these
> conditions: one is to raise an ERROR condition with a suitable ONCODE,
> and another is to log the error and have the program fail. A third is
> to let the program dance the fandango on core, but that is certainly not a requirement.
>
> (That said, I have never been happy with the idea of having such tests in
> debug mode but removing them from production code: I think it was Fred
> Brooks who said it was like carrying lifeboats while you were tooling
> around the harbor and leaving them behind when you headed out to sea.)

Probably not so much with these conditions, but I’m occasionally burned
when I pull out some debug code and discover it did something necessary.

>
>>> get/put keyword: data
>
>> Obviously the Committee had no idea what the facility was used for.
>
> The Committee's job was not to remove useless features: every feature is
> useful to some programmer for writing some program, and generally more
> than one of each, or it wouldn't have been included. Their job was to
> remove features that, in their expert judgement, cost more (implicitly:
> under the conditions of programming 35 years ago) than the benefits they
> provided to the PL/I community as a whole. I assume the cost in question
> was runtime memory, something that isn't nearly as expensive as it was then.
>
> Note also that the motivation for the 1987 revision of Subset G, which is
> what I'm working from, was primarily to add back features omitted from
> the original 1981 version that made the language excessively spare.
> Perhaps a later revision, if there had been one, would have added back
> GET/PUT DATA as memory restrictions loosened over time. That no such
> revision ever happened is beyond anyone's control today.

GET/PUT DATA without a data list is a nightmare. The program had to know
all the variables that are “known” at that point in the program and keep
the text of all fully-qualified names. I’ve seen “GET DATA;” used once or
twice, to good effect, but the scope has to be carefully limited.

>
>>> attributes: complex, controlled, generic, like, local, position
>> .
>> Omitting COMPLEX and CONTROLLED would produce a mickey-mouse
>> language of little practical value.
>
> To say that is to ignore the history of the last 45 years, my entire
> career in the trenches as a professional programmer, during which time I
> have used many, many languages and never needed either feature.
> Scientific programming is a niche, and in a relative sense is a smaller
> niche than ever. See above concerning costs and benefits. As for
> private stack allocation, which is what makes CONTROLLED unique, AREA
> seems to me to subsume much of that. (If this is not so, or anything
> else I say is wrong, please let me know.)

Robin has a scientific programming bias, so I can see where he’d need
COMPLEX. I’m still playing around with re-compiling IBM’s Scientific
Subroutine Package, and I’m adding the features it uses - COMPLEX and iSub
being the two major ones remaining. I now have all the math builtins done.

This is going fairly well. Within the limits of accuracy of FLOAT values
I’m getting the same results, with only minimal source changes. Working on
this, I’ve seen the usefulness of these features.

>
> That said, I certainly do not scorn complex numbers, even if they
> represent half the arithmetic types of PL/I, which is why I proposed
> adding back COMPLEX FLOAT, far and away the typical use case.
>

--
Pete

[Chris Van Fleet]

On Sunday, September 11, 2022 at 6:14:19 PM UTC-4, co...@ccil.org wrote:
> Syntactic restrictions:
> No dimensioned file constants

What is a "dimensioned file constant"?

> No format constants except labels on format statements

What is the disallowed "format constant"? Never heard of that.

> Pseudo-variables only on the left side of assignment statements

So no "substr" on the right? Seems I don't get it.

> Semantic restrictions:

> No conversions between arithmetic/pictured values and string values
> No conversions between bit strings and character strings

Why? Those aren't even hard to do.

> Excluded features:
> format variables

What is a "format variable"?

[John Cowan]

On Monday, September 12, 2022 at 10:57:05 AM UTC-4, bearlyabus...@gmail.com wrote:

> First, I’d like to say that I’m happy to see this discussion about the
> language. It’s like a breath of fredh air.

Thank you for saying so. I had feared that I was going to get nothing but scorn from making all these "impractical" and "useless" proposals.

> GET/PUT DATA without a data list is a nightmare.

I agree. What is worse, GET DATA without a list allows malicious input to corrupt the program's global state, which is a disaster. I've tentatively added GET DATA with an explicit list and PUT DATA to my extensions list, but I may remove them again.

> Robin has a scientific programming bias, so I can see where he’d need
> COMPLEX. I’m still playing around with re-compiling IBM’s Scientific
> Subroutine Package, and I’m adding the features it uses - COMPLEX and iSub
> being the two major ones remaining. I now have all the math builtins done.

Excellent! I'd like to see a list of what you needed to add already, if that's easy to do.

> > adding back COMPLEX FLOAT, far and away the typical use case.

I actually mean "only COMPLEX BIN FLOAT", by the way. One of the criteria for me to add an item to my extensions list is that it will be easy to implement in pli2c; gcc comes with a complex.h header file (standardized by C99, but made optional in C11).

[Robin Vowels]

On Tuesday, September 13, 2022 at 12:36:59 AM UTC+10, co...@ccil.org wrote:
> On Sunday, September 11, 2022 at 8:27:55 PM UTC-4, Robin Vowels wrote:
>
> > > conditions: name, stringrange, stringsize, subscriptrange
>
> > Again, the committee had no idea what it was doing to exclude these.
> > SUBSTR is essential in any program using arrays.
> > STRINGSIZE and STRINGRANGE are essential for the same reason
> > in string-handling.
> Appendix D, which my post is a precis of, excludes them as "debugging conditions", which are useful in testing code that may be buggy, but not useful in production code.

.
On the contrary, it is important to have the checks (subscriptrange, stringrange, stringsize, etc)
available in production mode. True, they help in debugging, but they help ensure that some obscure
bug does not pass unnoticed during production.
.
Gord Ross relates that an error occurring during production took a week to track down.
Since that event, the inclusion of SUBSCRIPTRANGE and STRINGRANGE
was made a default for all their production runs.
"The problem would have been caught by the range checks." he wrote.
(full details in "Introduction to PL/I and Structured Programming", facing p. 572)
.
Says IBM:
"If STRINGSIZE is disabled and the length of the source
and/or the target is determined at run time, and the target is
too short to contain the source, unpredictable results can occur."

.
> > Their omissions would take us back to the says of FORTRAN IV,
> > when stepping past the bounds of an array went undetected
> > and difficult to find.

.
> Not at all.
.
I strongly disagree.

.
> It is one thing to detect an error, another to provide a way to intercept the error and take corrective action, which is why you need a CONDITION. Compilers have two possibilities in the absence of these conditions:

.
Rubbish.
Without the means of detecting such an error, there can be no error message
nor any warning that an error occurred.
Which happened regularly in the days of FORTRAN. Programs just crashed.
.

> one is to raise an ERROR condition with a suitable ONCODE, and another is to log the error and have the program fail. A third is to let the program dance the fandango on core, but that is certainly not a requirement.
>
> (That said, I have never been happy with the idea of having such tests in debug mode but removing them from production code: I think it was Fred Brooks who said it was like carrying lifeboats while you were tooling around the harbor and leaving them behind when you headed out to sea.)
>
> > > get/put keyword: data
> > Obviously the Committee had no idea what the facility was used for.
> The Committee's job was not to remove useless features: every feature is useful to some programmer for writing some program, and generally more than one of each, or it wouldn't have been included. Their job was to remove features that, in their expert judgement, cost more (implicitly: under the conditions of programming 35 years ago)

.
That argument is fallacious.
PL/I was introduced in 1966; that's 55 years ago, not 35, when memory
was adequate to run PL/I and not hugely expensive.
.

> than the benefits they provided to the PL/I community as a whole. I assume the cost in question was runtime memory, something that isn't nearly as expensive as it was then.
>
> Note also that the motivation for the 1987 revision of Subset G, which is what I'm working from, was primarily to add back features omitted from the original 1981 version that made the language excessively spare. Perhaps a later revision, if there had been one, would have added back GET/PUT DATA as memory restrictions loosened over time. That no such revision ever happened is beyond anyone's control today.
.
> > > attributes: complex, controlled, generic, like, local, position
> > .
> > Omitting COMPLEX and CONTROLLED would produce a mickey-mouse
> > language of little practical value.
.
> To say that is to ignore the history of the last 45 years, my entire career in the trenches as a professional programmer, during which time I have used many, many languages and never needed either feature.
.

To say that is to ignore history of the past 70 years.
Complex arithmetic computation has been in use during this time.
even in the early days of Algol, and before.
(And FORTRAN had complex.)
.
I have used complex arithmetic for many projects.
Do fractals come to mind?

[Robin Vowels]

On Tuesday, September 13, 2022 at 12:57:05 AM UTC+10, bearlyabus...@gmail.com wrote:
.

> Robin has a scientific programming bias, so I can see where he’d need
> COMPLEX. I’m still playing around with re-compiling IBM’s Scientific
> Subroutine Package, and I’m adding the features it uses - COMPLEX and iSub
> being the two major ones remaining. I now have all the math builtins done.

.
I can write commercial PL/I code as well as anyone.

[Robin Vowels]

On Tuesday, September 13, 2022 at 6:39:25 AM UTC+10, Chris Van Fleet wrote:
> On Sunday, September 11, 2022 at 6:14:19 PM UTC-4, co...@ccil.org wrote:
.
> > Pseudo-variables only on the left side of assignment statements

.
Pseudo-variables can only be on the LHS of an assignment, etc.
On the RHS of an assignment, they are built-in function names.
.

[Robin Vowels]

On Tuesday, September 13, 2022 at 12:57:05 AM UTC+10, bearlyabus...@gmail.com wrote:

> John Cowan <co...@ccil.org> wrote:
>
> First, I’d like to say that I’m happy to see this discussion about the
> language. It’s like a breath of fredh air.
> > On Sunday, September 11, 2022 at 8:27:55 PM UTC-4, Robin Vowels wrote:
> >
> >>> conditions: name, stringrange, stringsize, subscriptrange
> >
> >> Again, the committee had no idea what it was doing to exclude these.
> >> SUBSTR is essential in any program using arrays.
> >> STRINGSIZE and STRINGRANGE are essential for the same reason
> >> in string-handling.
> >
> > Appendix D, which my post is a precis of, excludes them as "debugging
> > conditions", which are useful in testing code that may be buggy, but not
> > useful in production code.
.
> IMNSHO, as a long-time PL/I programmer, STRINGSIZE is completely useless.

.
Maybe you never did this:
.
IBM: "If STRINGSIZE is disabled, and the length of the source and/or
the target is determined at run time, and the target s too short to

[Peter Flass]

Chris Van Fleet <zeni...@gmail.com> wrote:
> On Sunday, September 11, 2022 at 6:14:19 PM UTC-4, co...@ccil.org wrote:
>> Syntactic restrictions:
>> No dimensioned file constants
>
> What is a "dimensioned file constant"?
>

Doesn’t make sense. I read this as “file variable.”

>> No format constants except labels on format statements
>
> What is the disallowed "format constant"? Never heard of that.

You’re not alone.

>
>> Pseudo-variables only on the left side of assignment statements
>
> So no "substr" on the right? Seems I don't get it.

If it’s on the right it’s a builtin function, not a pseudovariable. I don’t
understand this either. Where else could yo use them? Maybe in DO
statements, etc?

>
>> Semantic restrictions:
>> No conversions between arithmetic/pictured values and string values
>> No conversions between bit strings and character strings
>
> Why? Those aren't even hard to do.
>
>> Excluded features:
>> format variables
>
> What is a "format variable"?

Again wot?
>



--
Pete

[Peter Flass]

John Cowan <co...@ccil.org> wrote:
> On Monday, September 12, 2022 at 10:57:05 AM UTC-4, bearlyabus...@gmail.com wrote:
>
>> First, I’d like to say that I’m happy to see this discussion about the
>> language. It’s like a breath of fredh air.
>
> Thank you for saying so. I had feared that I was going to get nothing
> but scorn from making all these "impractical" and "useless" proposals.
>
>> GET/PUT DATA without a data list is a nightmare.
>
> I agree. What is worse, GET DATA without a list allows malicious input
> to corrupt the program's global state, which is a disaster. I've
> tentatively added GET DATA with an explicit list and PUT DATA to my
> extensions list, but I may remove them again.
>
>> Robin has a scientific programming bias, so I can see where he’d need
>> COMPLEX. I’m still playing around with re-compiling IBM’s Scientific
>> Subroutine Package, and I’m adding the features it uses - COMPLEX and iSub
>> being the two major ones remaining. I now have all the math builtins done.
>
> Excellent! I'd like to see a list of what you needed to add already, if that's easy to do.

I’ll try to review. This project has been spread over quite a while, so
it’s not simple to see. It’s mostly builtins. I had to add a slew of
mathematical builtins that I had postponed, since I had no use for them.
Most recently I added the array builtins SUM, PROD, and POLY. I’ll look to
see what else.

>
>>> adding back COMPLEX FLOAT, far and away the typical use case.
>
> I actually mean "only COMPLEX BIN FLOAT", by the way. One of the
> criteria for me to add an item to my extensions list is that it will be
> easy to implement in pli2c; gcc comes with a complex.h header file
> (standardized by C99, but made optional in C11).
>

Until recently almost everyone implemented FLOAT DECIMAL as FLOAT BINARY,
with only formatting differences on output. I would assume now that IBM is
using the IEEE DECIMAL FLOAT spec.


--
Pete

[Peter Flass]

I do this all the time, and every implementation I’ve seen just truncates
on assignment, as you’d expect (and as COBOL does). To do anything else
would be absolute madness.

--
Pete

[Robin Vowels]

.
Possibly you need to check the results.

[Robin Vowels]

.
ENTRY was included to mimic a similar feature in FORTRAN.
Its purpose was to minimise code duplication.
.
There is probably not much need for the feature now.

[Robin Vowels]

.
I have used it a lot.

[Robin Vowels]

On Tuesday, September 13, 2022 at 12:36:59 AM UTC+10, co...@ccil.org wrote:

.
That would be worse than useless.

[John Cowan]

On Monday, September 12, 2022 at 4:39:25 PM UTC-4, Chris Van Fleet wrote:
> On Sunday, September 11, 2022 at 6:14:19 PM UTC-4, co...@ccil.org wrote:

> What is a "dimensioned file constant"?

> What is the disallowed "format constant"? Never heard of that.

> What is a "format variable"?

Apparently pretty much what it says on the tin:

declare foo dimension(2) title('foo1.txt, foo2.txt) [...];
declare bar format value(d(4,2, d(3.2));
declare baz format variable;

> > Pseudo-variables only on the left side of assignment statements
> So no "substr" on the right? Seems I don't get it.

No, that's the corresponding built-in function. I think it means that you can't have a pseudo-variable in a SIZETO clause or similar place.

> > No conversions between arithmetic/pictured values and string values
> > No conversions between bit strings and character strings
> Why? Those aren't even hard to do.

These are implicit conversions: explicit conversions via the built-in functions are still fine. I'm not sure why these were dropped; either to simplify the compiler or to reduce the number of unintentional conversions, perhaps.

[John Cowan]

On Monday, September 12, 2022 at 7:21:25 PM UTC-4, Robin Vowels wrote:

> > It is one thing to detect an error, another to provide a way to intercept the error and take corrective action, which is why you need a CONDITION. Compilers have two possibilities in the absence of these conditions:
> .
> Rubbish.
> Without the means of detecting such an error, there can be no error message
> nor any warning that an error occurred.

You really didn't read what I said, did you.

> Which happened regularly in the days of FORTRAN. Programs just crashed.

Unless you used a Fortran checkout compiler such as WATFIV, in which case the program still crashed, but with an error message.

> PL/I was introduced in 1966; that's 55 years ago, not 35, when memory
> was adequate to run PL/I and not hugely expensive.

Adequate to run it on the small problems of the day. This laptop I'm using right now has 1024 KB (modulo 32 vs. 36 bit); how much would a System/360 of that size have cost then?

> To say that is to ignore history of the past 70 years.
> Complex arithmetic computation has been in use during this time.

In a niche that grows tinier and tinier as time passes. Granted, quaternions have substantially more uses nowadays.

> even in the early days of Algol

No complex numbers in Algol 60, except for a few implementations like Georgia Tech version of Burroughs Algol, where they were added as a student project. If you look at which other languages support them today, the answers are Common Lisp, C/C++, and Python, all scientific programming languages.

[John Cowan]

On Monday, September 12, 2022 at 9:55:39 PM UTC-4, Robin Vowels wrote:

> [iSUB] with the restriction that it must specify a contiguous portion of the base array.

> .
> That would be worse than useless.

You're right. I have removed it again.

[Peter Flass]

John Cowan <co...@ccil.org> wrote:
> On Monday, September 12, 2022 at 7:21:25 PM UTC-4, Robin Vowels wrote:
>
>>> It is one thing to detect an error, another to provide a way to
>>> intercept the error and take corrective action, which is why you need a
>>> CONDITION. Compilers have two possibilities in the absence of these conditions:
>> .
>> Rubbish.
>> Without the means of detecting such an error, there can be no error message
>> nor any warning that an error occurred.
>
> You really didn't read what I said, did you.
>
>> Which happened regularly in the days of FORTRAN. Programs just crashed.
>
> Unless you used a Fortran checkout compiler such as WATFIV, in which case
> the program still crashed, but with an error message.
>
>> PL/I was introduced in 1966; that's 55 years ago, not 35, when memory
>> was adequate to run PL/I and not hugely expensive.
>
> Adequate to run it on the small problems of the day. This laptop I'm
> using right now has 1024 KB (modulo 32 vs. 36 bit); how much would a
> System/360 of that size have cost then?

1024 “K”? That’s only a megabyte. What are you using, an original IBM PC?

1MB would have been a very big system in 1964. PL/I(F) was designed to run
(slowly) in a 64K partition.

>
>> To say that is to ignore history of the past 70 years.
>> Complex arithmetic computation has been in use during this time.
>
> In a niche that grows tinier and tinier as time passes. Granted,
> quaternions have substantially more uses nowadays.
>
>> even in the early days of Algol
>
> No complex numbers in Algol 60, except for a few implementations like
> Georgia Tech version of Burroughs Algol, where they were added as a
> student project. If you look at which other languages support them
> today, the answers are Common Lisp, C/C++, and Python, all scientific
> programming languages.
>

--
Pete

[Robin Vowels]

On Wednesday, September 14, 2022 at 3:00:26 AM UTC+10, co...@ccil.org wrote:
> On Monday, September 12, 2022 at 7:21:25 PM UTC-4, Robin Vowels wrote:
>
> > > It is one thing to detect an error, another to provide a way to intercept the error and take corrective action, which is why you need a CONDITION. Compilers have two possibilities in the absence of these conditions:
> > .
> > Rubbish.
> > Without the means of detecting such an error, there can be no error message
> > nor any warning that an error occurred.
.
> You really didn't read what I said, did you.

.
I did.
And I responded to what you wrote.

.
> > Which happened regularly in the days of FORTRAN. Programs just crashed.
> Unless you used a Fortran checkout compiler such as WATFIV,

.
WATFIV came quite late in the piece -- c. 1970 or so.
Before WATFOR and WATFIV, IBM's compilers merely crashed at
run time, with no information about where the error occurred.
Hence the immediate advantage of PL/I, which not only told you
WHERE an error occurred (which LINE) but also allowed you
to print some values of variables (e.g., those used as subscripts),
and, in the case of such things as OVERFLOW, allowed a program to
continue and yield further useful information.
When it was necessary to wait for a week's turn-around, such
facilities were a godsend.
.
And, by the way, WATFOR and WATFIV were memory hogs.
WATFOR would not run in a 128 machine.
So, our site was left with useless FORTRAN compilers
and a brilliant PL/I compiler.
.

> in which case the program still crashed, but with an error message.
> > PL/I was introduced in 1966; that's 55 years ago, not 35, when memory
> > was adequate to run PL/I and not hugely expensive.
.
> Adequate to run it on the small problems of the day.

.
They were not "small" problems.

.
> This laptop I'm using right now has 1024 KB (modulo 32 vs. 36 bit);

.
That's tiny for a laptop.
1Mb was available in the 1960s. It was called LCS.
And it was cheap.
.

> how much would a System/360 of that size have cost then?

.

> > To say that is to ignore history of the past 70 years.
> > Complex arithmetic computation has been in use during this time.
.
> In a niche that grows tinier and tinier as time passes.

I doubt it.

.
> Granted, quaternions have substantially more uses nowadays.

> > even in the early days of Algol.
.

> No complex numbers in Algol 60,

.
That didn't/doesn't stop complex arithmetic from being performed in Algol.
Look in Handbook for Automatic Computation.
.

> except for a few implementations like Georgia Tech version of Burroughs Algol, where they were added as a student project. If you look at which other languages support them today, the answers are Common Lisp, C/C++, and Python, all scientific programming languages.

.
and PL/I.

[John Cowan]

On Tue, Sep 13, 2022 at 1:58 PM Robin Vowels <robin....@gmail.com> wrote:

> WATFIV came quite late in the piece -- c. 1970 or so.
> Before WATFOR and WATFIV, IBM's compilers merely crashed at
> run time, with no information about where the error occurred.

​Luckily, I never had to suffer with such POS systems when I was writing Fortran.

​
> > Adequate to run it on the small problems of the day.
.
>They were not "small" problems.

By modern standards, of course they were. But you know that.

​
> > This laptop I'm using right now has 1024 KB (modulo 32 vs. 36 bit);

​And that was a typo/thinko. But you knew that too.

​
> In a niche that grows tinier and tinier as time passes.

> I doubt it.

​In the very beginning, all programming was scientific programming. What proportion of *all* programming do you think is scientific programming now?

​
> > No complex numbers in Algol 60,
.
> That didn't/doesn't stop complex arithmetic from being performed in Algol.
​​

​By the same token you could do complex numbers in PL/I without COMPLEX. The Algol Bulletin that I was thinking of was Supplement #12 <https://dl.acm.org/doi/pdf/10.5555/1064054.1064055>, and lays out three methods for doing it that were already proposed before urging that a COMPLEX keyword be added to the language. But it didn't happen.

​
> > If you look at which other languages support them today, the answers are Common Lisp, C/C++, and Python, all scientific programming languages.
.
> and PL/I.

*Other* languages.

[Robin Vowels]

On Wednesday, September 14, 2022 at 6:16:41 AM UTC+10, co...@ccil.org wrote:
> On Tue, Sep 13, 2022 at 1:58 PM Robin Vowels <robin....@gmail.com> wrote:
>
> > WATFIV came quite late in the piece -- c. 1970 or so.
> > Before WATFOR and WATFIV, IBM's compilers merely crashed at
> > run time, with no information about where the error occurred.
> ​Luckily, I never had to suffer with such POS systems when I was writing Fortran.
> ​
> > > Adequate to run it on the small problems of the day.
> .
> >They were not "small" problems.
> By modern standards, of course they were. But you know that.
> ​
> > > This laptop I'm using right now has 1024 KB (modulo 32 vs. 36 bit);
> ​And that was a typo/thinko. But you knew that too.
> ​
> > In a niche that grows tinier and tinier as time passes.
>
> > I doubt it.
> ​In the very beginning, all programming was scientific programming.

.
You'd need to check that with Ada.
.
You'd need to check that with Ada. What proportion of *all* programming do you think is scientific programming now?
.

> > > No complex numbers in Algol 60,
> .
> > That didn't/doesn't stop complex arithmetic from being performed in Algol.
> ​​
> ​By the same token you could do complex numbers in PL/I without COMPLEX.

.
Of course you can; PL/I is a very versatile language. But I think you knew that.
.
And, yes I did program complex numbers in PL/I, because there was a bug in
either PL/I for OS/2 or VA PL/I for Windows, for multiplication and/or division.

.
>The Algol Bulletin that I was thinking of was Supplement #12 <https://dl.acm.org/doi/pdf/10.5555/1064054.1064055>, and lays out three methods for doing it that were already proposed before urging that a COMPLEX keyword be added to the language. But it didn't happen.

.
Long before Algol and anything else, people knew how to do complex arithmetic.

.
> > > If you look at which other languages support them today, the answers are Common Lisp, C/C++, and Python, all scientific programming languages.
> .
> > and PL/I.
> *Other* languages.

.
You excluded it from your list.

[Robin Vowels]

On Wednesday, September 14, 2022 at 3:46:59 AM UTC+10, bearlyabus...@gmail.com wrote:
> John Cowan <co...@ccil.org> wrote:
> > On Monday, September 12, 2022 at 7:21:25 PM UTC-4, Robin Vowels wrote:
> >
> >>> It is one thing to detect an error, another to provide a way to
> >>> intercept the error and take corrective action, which is why you need a
> >>> CONDITION. Compilers have two possibilities in the absence of these conditions:
> >> .
> >> Rubbish.
> >> Without the means of detecting such an error, there can be no error message
> >> nor any warning that an error occurred.
> >
> > You really didn't read what I said, did you.
> >
> >> Which happened regularly in the days of FORTRAN. Programs just crashed.
> >
> > Unless you used a Fortran checkout compiler such as WATFIV, in which case
> > the program still crashed, but with an error message.
> >
> >> PL/I was introduced in 1966; that's 55 years ago, not 35, when memory
> >> was adequate to run PL/I and not hugely expensive.
> >
> > Adequate to run it on the small problems of the day. This laptop I'm
> > using right now has 1024 KB (modulo 32 vs. 36 bit); how much would a
> > System/360 of that size have cost then?
> 1024 “K”? That’s only a megabyte. What are you using, an original IBM PC?
>
> 1MB would have been a very big system in 1964. PL/I(F) was designed to run
> (slowly) in a 64K partition.

.
PL/I did not run slowly.
Everything ran slowly in 64K.
And not everything ran in 64K - not FORTRAN H, not FORTRAN G.
(I think that the only FORTRAN compiler that did was E --
and that didn't run at all in Release 13.)
The real problem was the link editor.
.
The S/360 models 50 and below were not fast machines.
Even small programs took around 72 seconds to compile-execute-run.
Our old computer solved such problems quicker than on OS/360.
.
When we added 1Mb LCS, the S360 ran even slower,
because OS MVT took around 100K of the available 128K of fast core,
and user programs consequently ran in slow core.

[John W Kennedy]

Object-oriented programming wasn’t even on the table in the mid-60s.
GENERIC is a half-hearted attempt at overloading.

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