A doubly linked-list in C

[John W Kennedy]

In Dread Ink, the Grave Hand of robin Did Inscribe:

I'd be curious to know if that were a reaction to fortran's standardization
in the same year.

We're getting all jumbled here. I believe that PL/I (under the name NPL)
was announced in 1964, and that the OS/360 FORTRAN IV (E) and OS/360
FORTRAN IV (H) compilers were announced in 1964, as well. But, at the
very latest, they were all announced by July of 1965, when I actually
handled preliminary manuals.

 

[robin]

The PL/I "checkout compiler" was capable of "correcting" simple
Fortran programs into PL/I programs. For example, it would insert
semicolons at the end of lines, and insert declarations based on
the first letter of variable names.

The semicolons it could do.
There was no need to insert declarations, however, nor could it do it.
Default typing in PL/I was exactly the same as the FORTRAN default
(the I to N rule).
Therefore, undeclared identifiers in PL/I defaulted to the same type
as would FORTRAN.

That compiling some FORTRAN programs using a PL/I compiler
was possible was because FORTRAN was a small subset of PL/I.

 

[robin]

In Dread Ink, the Grave Hand of robin Did Inscribe:


Did PL/I become standardized too?

Yes, it did.

If so, how would you compare that
standard to either fortran's or C's?

In what sense?

 

[Richard Tobin]

The PL/I "checkout compiler" was capable of "correcting" simple
Fortran programs into PL/I programs. For example, it would insert
semicolons at the end of lines, and insert declarations based on
the first letter of variable names.

[/QUOTE]

The semicolons it could do.
There was no need to insert declarations, however, nor could it do it.

As I recall, it certainly produced warnings about the undeclared
variables and reported what types they would be given, though whether
that amounts to inserting declarations is probably undecidable.

That compiling some FORTRAN programs using a PL/I compiler
was possible was because FORTRAN was a small subset of PL/I.

I no longer recall the details, but I think compiling a Fortran
program as PL/I required more than that. For example, I think it
would tolerate Fortran boilerplate ("program main"), and the
absence of PL/I boilerplate - or were these the same?

-- Richard

 

[glen herrmannsfeldt]

We're getting all jumbled here. I believe that PL/I (under the name NPL)
was announced in 1964, and that the OS/360 FORTRAN IV (E) and OS/360
FORTRAN IV (H) compilers were announced in 1964, as well. But, at the
very latest, they were all announced by July of 1965, when I actually
handled preliminary manuals.

I don't disagree, though I haven't looked at any references yet.

Some interesting comments on the history of Fortran:

http://www.idinews.com/Backus.html

Among others:

"Some speculated that PL/I would have become the dominant
language for scientific/engineering applications if IBM had
chosen to call it Fortran VI. Of course that would have doomed
it in the business applications community."

-- glen

 

[Peter Flass]

That's at odds with the facts.
IBM did supply Fortran compilers with OS/360, right from the start,
including the E and G compilers. I'm not sure about the H compiler,
whether it was available initially.

No, "H" came later, around 1967 IIRC, and it was initially pretty buggy.
....

IBM's PL/I-F compiler was available very early.
It ran as fast as any of the compilers (E FORTRAN, G FORTRAN).

It could be fairly slow. It was very sensitive to the amount of memory
it had to run in.

 

[nmm1]

Among others:

"Some speculated that PL/I would have become the dominant
language for scientific/engineering applications if IBM had
chosen to call it Fortran VI. Of course that would have doomed
it in the business applications community."

That was about as likely as it dominating in the commercial one by
calling it COBOL whatever. In other words, stuff and nonsense!

There were very solid technical reasons that PL/I never made much
headway in the scientific/engineering community, and the name had
no influence on the saner of the people in that. Dammit, both
Algol 68 and Ada made much more headway ....


Regards,
Nick Maclaren.

 

[nmm1]

No, "H" came later, around 1967 IIRC, and it was initially pretty buggy.
...

Like, very buggy. But better than the Pl/I Optimizing Compiler ....


Regards,
Nick Maclaren.

 

[John W Kennedy]

No, "H" came later, around 1967 IIRC, and it was initially pretty buggy.

You are mixing actal delivery of the compiler with its announcement. G
was a rush development and shipment because H was behind schedule.

 

[Terence]

I remember the sequence of Fortran compilers as :-
Fortran I, Fortran II, "Fortran 4/1/61",Fortran IV, Fortran 66,

Where "4/1/61" was an internal name for what might have been an
unreleased Fortran III, or a possible trial version of Fortran IV. It
was the name on my working manuals and documents and the phrase we
used in conversation..

When I left IBM and ended up in Shell with both PL/1 and Fortran F-G-H
on the 7074,,/360 and /370's, I heard thorugh my old grapevine that
about 140 persons had worked on the PL/1 compiler, much as the Chinese
climbers assaulted Mt Everest.
It might be an exaggeration, but even 200 wouldn't have surprised me.

I used PL/1 it extensively in Shell until I founded my company, where
I switched to Fortran for the new micros and older minicomputers..

 

[Peter Flass]

You are mixing actal delivery of the compiler with its announcement. G
was a rush development and shipment because H was behind schedule.

I remember seeing a notice in my college computer center "Do not use
FORTRAN H until further notice.", and I graduated in January of 1968.

 

[nmm1]

I remember seeing a notice in my college computer center "Do not use
FORTRAN H until further notice.", and I graduated in January of 1968.

It was still buggy well into the 1970s, as was the PL/I Optimizing
Compiler.


Regards,
Nick Maclaren.

 

[Guest]

??
Matching the types on procedure calls is an important
characteristic of any language, and in PL/I was designed to
eliminate a common class of error.

I never programmed in PL/I but I do remember a lot of articals
in technical magazines that always seemed to be along the lines
of:-

<innocuous seeming PL/I snippet> What Does This Do?

And it always seemed to do something terrible or unobvious
(or both) due to unexpected implicit type conversions.

But then Herb Sutter's C++ articals were a bit like this...

 

[Gordon Sande]

You are mixing actal delivery of the compiler with its announcement. G
was a rush development and shipment because H was behind schedule.

G was a commercial product that was retargetted to IBM by its developer. H was
an internal development.

The error messages from G were of the form "Error here" under the line with a
quite accurate location shown by print symbols. In practice quite helpful.
The generated code was "good unoptimized" with short compile times.

The error messages from H were very long and quite detailed but at the end of
the listing. Almost useless. The opt level 0 code was rather bad. At level 1 it
was slightly better than G's but with slow compiles and at level 2 it
ran faster
and compiled even slower. You had to check the output of higher opt
levels as there
were many problems.

For a long time there was object level incompatability between the two over the
handling of passed subroutine addresses as they had differing levels of
indirection.

 

[nmm1]

G was a commercial product that was retargetted to IBM by its developer. H was
an internal development.

In an extended dialect of Fortran ....


Regards,
Nick Maclaren.

 

[robin]

That was about as likely as it dominating in the commercial one by
calling it COBOL whatever. In other words, stuff and nonsense!

There were very solid technical reasons that PL/I never made much
headway in the scientific/engineering community, and the name had
no influence on the saner of the people in that. Dammit, both
Algol 68 and Ada made much more headway ....

There were no "solid technical reasons". PL/I had far more to offer,
and especially in scientific and engineering fields,
and greater flexibility.

Looking as some of the old FORTRAN codes, it amazes me
that people went to such lengths to make their codes
machine independent and still didn't have the portability
and generality of PL/I.

As for Algol 68, it was a damp squib.

 

[nmm1]

There were no "solid technical reasons". PL/I had far more to offer,
and especially in scientific and engineering fields,
and greater flexibility.

One thing that most people learn is that flexibility comes at a cost.
The cost almost always includes increased difficulty of debugging and
increased cost/difficulty of implementation, and very often worse
performance. PL/I had all of those problems, badly, as everyone who
had the relevant experience can witness.

Looking as some of the old FORTRAN codes, it amazes me
that people went to such lengths to make their codes
machine independent and still didn't have the portability
and generality of PL/I.

The mind boggles. Almost every system had a Fortran 66 compiler,
but not more than one in ten had a PL/I compiler - and the dialects
they accepted were all very different. The latter was because most
non-IBM vendors omitted many of the features to reduce the cost of
implementing it.

You would know that if you have been in the game of writing truly
portable applications - I was, and my code has been run on hundreds
of (different) systems over several decades.

As for Algol 68, it was a damp squib.

True, but not as much as PL/I


Regards,
Nick Maclaren.

 

[nmm1]

I lived through that era and was part of a PL/I beta site. My
recollection is that several years after the introduction of the suite
of S/360 compilers (PL/I, Fortran, Cobol, etc.) IBM announced at SHARE
(or maybe it was GUIDE?) that in a certain time frame (2 years?) IBM
was going to drop support for Fortran and Cobol because they could
migrate to PL/I. The group handed IBM its head on a platter and that
ended any further attempts by IBM to make PL/I the 'one size fits all
language of choice.'

IBM did, but that didn't end the policy. What ended the policy was
the customers putting their money where their mouth was.

What is it about "get stuffed" that you don't understand? Or words
to that effect, couched in contractual terms.

PS: PL/I is still my first choice.

Once it settled down, it wasn't a bad language, but with some EVIL
"gotchas" - very like Algol 68, but starting from the exactly
opposite approach to design The things that killed it were its
lack of portability and poor performance - the latter wouldn't have
been an issue a decade later and with some slightly better designed
calling sequences.


Regards,
Nick Maclaren.

 

[BartC]

There were no "solid technical reasons". PL/I had far more to offer,
and especially in scientific and engineering fields,
and greater flexibility.

Looking as some of the old FORTRAN codes, it amazes me
that people went to such lengths to make their codes
machine independent and still didn't have the portability
and generality of PL/I.

As for Algol 68, it was a damp squib.

It had class though...

 

[robin]

I never programmed in PL/I but I do remember a lot of articals
in technical magazines that always seemed to be along the lines
of:-

<innocuous seeming PL/I snippet> What Does This Do?

And it always seemed to do something terrible or unobvious
(or both) due to unexpected implicit type conversions.

There were few of such articles. They were usually written
by people who failed to turn on overflow detection with
fixed-point working.
They then wondered why the result was wrong,
instead of getting an overflow message.

Sort of like the surprises one got in the old days with Fortran,
such as forgetting to put in a 1X as the first descriptor in a FORMAT
statement, and wondering where the minus sign went,
or the leading digit went when the result was printed.
But in FORTRAN, there was no error message for that error,
and no way of telling the compiler to detect it.