Languages influenced by PL/1

Hi,

not exactly new-news, but I noticed that the CL programming language (JCL/shell-script for the IBM iSeries/System i/whatever it's called now) had some enhancements a few releases ago.

You can now declare based and defined variables. If you don't declare the storage class, it defaults to automatic (which you can also declare explicitly) although the syntax is different, this seems very PL/1 like.

On Saturday, 14 July 2012 19:44:14 UTC+10, (unknown) wrote:

> not exactly new-news, but I noticed that the CL programming language (JCL/shell-script for the IBM iSeries/System i/whatever it's called now) had some enhancements a few releases ago.
>
> You can now declare based and defined variables. If you don't declare the storage class, it defaults to automatic (which you can also declare explicitly) although the syntax is different, this seems very PL/1 like.

Interesting.

Other older ones include PL/M and XPL. Any others?

On 2012-07-14 09:44:14 +0000, john_maybury@hotmail.com said:

> Hi,
>
> not exactly new-news, but I noticed that the CL programming language
> (JCL/shell-script for the IBM iSeries/System i/whatever it's called now)

"IBM i". There is no longer an iSeries as such because IBM i is written
to run on the very same systems (IBM Power Systems) that run AIX.

> had some enhancements a few releases ago.
>
> You can now declare based and defined variables. If you don't declare
> the storage class, it defaults to automatic (which you can also declare
> explicitly) although the syntax is different, this seems very PL/1 like.

And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But
CL is indeed strongly influenced by PL/I, as were most other IBM
command languages of the late 60s and 70s, such as TSO and IDCAMS.

--
John W Kennedy
"Only an idiot fights a war on two fronts. Only the heir to the throne
of the kingdom of idiots would fight a war on twelve fronts"
-- J. Michael Straczynski. "Babylon 5", "Ceremonies of Light and Dark"

On 2012-07-14 23:49:49 +0000, robin.vowels@gmail.com said:

> On Saturday, 14 July 2012 19:44:14 UTC+10, (unknown) wrote:
>
>> not exactly new-news, but I noticed that the CL programming language
>> (JCL/shell-script for the IBM iSeries/System i/whatever it's called
>> now) had some enhancements a few releases ago.
>>
>> You can now declare based and defined variables. If you don't declare
>> the storage class, it defaults to automatic (which you can also declare
>> explicitly) although the syntax is different, this seems very PL/1 like.
>
> Interesting.
>
> Other older ones include PL/M and XPL. Any others?

Some /very/ common features, such as "/* ... */" comments, can be
traced back to PL/I. On the other hand, many languages have been
influenced in a negative way by PL/I. All modern languages have typed
pointers, for example, because the experience with PL/I anonymous
pointers was so terrible. Similarly, all modern languages have lexical
scoping of exception handlers, and do not allow return to the point of
exception because the dynamic PL/I ON statement and the ability to
return from an ON-unit were so destructive. In many ways, PL/I was as
much a "great leap forward" experiment as anything else, and, as usual
in such cases, it was as valuable for its failures as for its successes.

--
John W Kennedy
"You can, if you wish, class all science-fiction together; but it is
about as perceptive as classing the works of Ballantyne, Conrad and W.
W. Jacobs together as the 'sea-story' and then criticizing _that_."
-- C. S. Lewis. "An Experiment in Criticism"

John W Kennedy <jwkenne@attglobal.net> wrote:

(snip, someone wrote)
>> You can now declare based and defined variables. If you don't declare
>> the storage class, it defaults to automatic
(snip)

> And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But
> CL is indeed strongly influenced by PL/I, as were most other IBM
> command languages of the late 60s and 70s, such as TSO and IDCAMS.

Fortran only defaults to automatic in RECURSIVE routines.
Otherwise, variables can be either static (SAVEd) or automatic.

-- glen

In <50020d5e$0$1223$607ed4bc@cv.net>, on 07/14/2012
at 08:22 PM, John W Kennedy <jwkenne@attglobal.net> said:

>And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But
> CL is indeed strongly influenced by PL/I, as were most other IBM
>command languages of the late 60s and 70s, such as TSO and IDCAMS.

No. It's true that CLIST uses /* */ to delimit comments, but there the
resemblance stops. JCL in DOS/360 and OS/360 looked nothing like PL/I
and had a vaguely assembler syntax. EXEC in CP/67 through z/VM looked
nothing like PL/I, nor did the later EXEC 2. The only IBM command
language that looked vaguely like PL/I was REXX, and even there their
were more differences than similarities.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

On 2012-07-15 00:42:51 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwkenne@attglobal.net> wrote:
>
> (snip, someone wrote)
>>> You can now declare based and defined variables. If you don't declare
>>> the storage class, it defaults to automatic
> (snip)
>
>> And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But
>> CL is indeed strongly influenced by PL/I, as were most other IBM
>> command languages of the late 60s and 70s, such as TSO and IDCAMS.
>
> Fortran only defaults to automatic in RECURSIVE routines.
> Otherwise, variables can be either static (SAVEd) or automatic.

I am not an expert on Fortran past Fortran IV, but what you say here
makes no sense. If SAVE means static, and otherwise means automatic,
then automatic is the default, on accounta that's what "default" means.
Now, if I recall aright, in 77, non-SAVE /could/ be static, and maybe
that's still true today, but that's not what you're saying.


--
John W Kennedy
Having switched to a Mac in disgust at Microsoft's combination of
incompetence and criminality.

John W Kennedy <jwkenne@attglobal.net> wrote:

(snip, I wrote)
>> Fortran only defaults to automatic in RECURSIVE routines.
>> Otherwise, variables can be either static (SAVEd) or automatic.

> I am not an expert on Fortran past Fortran IV, but what you say here
> makes no sense. If SAVE means static, and otherwise means automatic,
> then automatic is the default, on accounta that's what "default" means.
> Now, if I recall aright, in 77, non-SAVE /could/ be static, and maybe
> that's still true today, but that's not what you're saying.

That is what I was trying to say.

A Fortran 90 or later compiler, when compiling a routine without
the RECURSIVE option, is allowed to use either static or automatic
storage for local variables. (SAVE is the word used in the Fortran
standard for what everyone else calls static.) There is no keyword
for automatic. (Not that anyone uses auto in C, and rarely AUTOMATIC
in PL/I.)

-- glen

On 2012-07-15 01:33:42 +0000, Shmuel (Seymour J.) Metz said:

> In <50020d5e$0$1223$607ed4bc@cv.net>, on 07/14/2012
> at 08:22 PM, John W Kennedy <jwkenne@attglobal.net> said:
>
>> And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But
>> CL is indeed strongly influenced by PL/I, as were most other IBM
>> command languages of the late 60s and 70s, such as TSO and IDCAMS.
>
> No. It's true that CLIST uses /* */ to delimit comments, but there the
> resemblance stops. JCL in DOS/360 and OS/360 looked nothing like PL/I
> and had a vaguely assembler syntax. EXEC in CP/67 through z/VM looked
> nothing like PL/I, nor did the later EXEC 2.

Not "late 60s and 70s".

> The only IBM command
> language that looked vaguely like PL/I was REXX, and even there their
> were more differences than similarities.

You're neglecting the general schema of:

command [pos-arg...] [keyword(operand [, operand]...)]

Early 360-era command languages looked like assembler. Later ones
looked like PL/I

--
John W Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
-- Charles Williams. "Mount Badon"

Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <50020d5e$0$1223$607ed4bc@cv.net>, on 07/14/2012
> at 08:22 PM, John W Kennedy <jwkenne@attglobal.net> said:

>>And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But
>> CL is indeed strongly influenced by PL/I, as were most other IBM
>>command languages of the late 60s and 70s, such as TSO and IDCAMS.

> No. It's true that CLIST uses /* */ to delimit comments, but there the
> resemblance stops. JCL in DOS/360 and OS/360 looked nothing like PL/I
> and had a vaguely assembler syntax.

And as I read somewhere, I believe written by someone involved in
the decision, the JCL use of /* was unrelated to the PL/I use.

That is, neither knew about the other at the time.

It does complicate starting comments in column 1.

-- glen

On Monday, 16 July 2012 05:18:44 UTC+10, glen herrmannsfeldt wrote:

> It does complicate starting comments in column 1.

Not on Windows and other implementations.

Only on the mainframe. But isn't there a way around that?

On Sunday, 15 July 2012 10:32:51 UTC+10, John W Kennedy wrote:

> Some /very/ common features, such as "/* ... */" comments, can be
> traced back to PL/I. On the other hand, many languages have been
> influenced in a negative way by PL/I. All modern languages have typed
> pointers, for example, because the experience with PL/I anonymous
> pointers was so terrible.

Languages after PL/I offered untyped pointers.
My experience with the original pointers in PL/I was favorable.
Now you have the choice of both typed and untyped pointers.

> Similarly, all modern languages have lexical
> scoping of exception handlers, and do not allow return to the point of
> exception because the dynamic PL/I ON statement and the ability to
> return from an ON-unit were so destructive.

The trapping of an error condition in PL/I is like a procedure call.
There's nothing strange or unruly about that.
It provides the ability to handle the error and to recover from it.
That's especially useful in the case of conversion errors,
and in the case of stringrange and stringsize errors,
where the normal action is to continue execution from the
point where the error occurred. Similarly for underflow and overflow.

It's an essential feature of a real-time system.

At a time when waiting a week for a re-run of a non-PL/I program
that failed because of an error, the ability of PL/I to continue
processing from the point of interruption for certain non-fatal
classes of error was a masterful design.

> In many ways, PL/I was as
> much a "great leap forward" experiment as anything else, and, as usual
> in such cases, it was as valuable for its failures as for its successes.

PL/I wasn't an "experiment". It was a huge advance over
anything else at the time, and offered facilities that
until then had only been available in individual languages.

Where the language incorporated features from other languages,
they were considerably improved upon, most notably in the area
of I/O.

On 2012-07-16 00:09:44 +0000, robin.vowels@gmail.com said:

> On Monday, 16 July 2012 05:18:44 UTC+10, glen herrmannsfeldt wrote:
>
>> It does complicate starting comments in column 1.
>
> Not on Windows and other implementations.
>
> Only on the mainframe. But isn't there a way around that?

Only on //SYSIN DD * -- and the solution, going back to the very
beginning of PL/I, is to exclude column 1 from the input. (And soon
after, someone came up with the idea to put '1', '0', or '-' in column
1 to format the print listing.) Nowadays, source code is normally read
from a file (or PDS member), and '/*' in column 1 is not a problem.

--
John W Kennedy
"...when you're trying to build a house of cards, the last thing you
should do is blow hard and wave your hands like a madman."
-- Rupert Goodwins

robin.vowels@gmail.com wrote:
> On Sunday, 15 July 2012 10:32:51 UTC+10, John W Kennedy wrote:

(snip)
>> Similarly, all modern languages have lexical
>> scoping of exception handlers, and do not allow return to the point of
>> exception because the dynamic PL/I ON statement and the ability to
>> return from an ON-unit were so destructive.

> The trapping of an error condition in PL/I is like a procedure call.
> There's nothing strange or unruly about that.

On many systems, it isn't so easy to do.
Especially note the IBM 360/91 where I ran many PL/I programs.

> It provides the ability to handle the error and to recover from it.
> That's especially useful in the case of conversion errors,
> and in the case of stringrange and stringsize errors,
> where the normal action is to continue execution from the
> point where the error occurred. Similarly for underflow and overflow.

Overflow and underflow are not easy in the case of imprecise
interrupts. You can't get back to where the error actually
occured, and you can't get the address of the data to fix it.

> It's an essential feature of a real-time system.

> At a time when waiting a week for a re-run of a non-PL/I program
> that failed because of an error, the ability of PL/I to continue
> processing from the point of interruption for certain non-fatal
> classes of error was a masterful design.

Depending on how close you need to get. With the Java try/catch
system you get close, and to a known spot at the appropriate
time, but not exactly back to the point of interruption.

>> In many ways, PL/I was as much a "great leap forward"
>> experiment as anything else, and, as usual in such cases,
>> it was as valuable for its failures as for its successes.

> PL/I wasn't an "experiment". It was a huge advance over
> anything else at the time, and offered facilities that
> until then had only been available in individual languages.

It was a huge advance, but also an experiment. Many things
hadn't been done before and were defined into the language
before anyone had time to try them out and understand them.

> Where the language incorporated features from other languages,
> they were considerably improved upon, most notably in the area
> of I/O.

In that case, you can say it wasn't an experiment.

If you look at most language updates, the new features were
extensions in some previous version before being added.
That wan't done for much of PL/I.

-- glen

John W Kennedy <jwkenne@attglobal.net> wrote:

(snip regarding /* and OS/360 JCL)

>>> It does complicate starting comments in column 1.

>> Not on Windows and other implementations.

>> Only on the mainframe. But isn't there a way around that?

> Only on //SYSIN DD * -- and the solution, going back to the very
> beginning of PL/I, is to exclude column 1 from the input.

I once had a file that contained a PL/I program and a Fortran
callable assembler program. All the PL/I lines had * in column 1
(assembler comment) and the assembler program had /* and */
around it.

> (And soon after, someone came up with the idea to put '1', '0',
> or '-' in column 1 to format the print listing.)

I once did this, including '+' to double print (bold) some comments.
You can make nice looking program listings this way.

> Nowadays, source code is normally read
> from a file (or PDS member), and '/*' in column 1 is not a problem.

But you have to get it into the PDS.

Sometime later, I believe MVS, DD DATA,DLM=xx

was added, where you can supply your own two character delimiter.

DD * will stop at either /* or // (other JCL), DD DATA will
read through // (so you can read in JCL, such as PROCLIB).

-- glen