See the second column on the first page:

https://dl.acm.org/doi/pdf/10.1145/365230.365233

Louis

Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
> See the second column on the first page:
>
> https://dl.acm.org/doi/pdf/10.1145/365230.365233

Yes, and? B5500 ALGOL was a very good implementation of ALGOL-58, except
that stream procedures bypassed all the hardware protection mechanisms. I
think Burroughs fixed this on later machines. ALGOL was later sunk by the
development of ALGOL-68, which (AIUI) was more different from ALGOL-60 than
C++ is from C.

ALGOL and PL/I suffered from the same syndrome where FORTRAN programmers
wanted FORTRAN and COBOL programmers wanted COBOL, and that didn’t leave
much room for anything else at the time.

--
Pete

On 9/1/2022 4:13 PM, Peter Flass wrote:
> Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>> See the second column on the first page:
>>
>> https://dl.acm.org/doi/pdf/10.1145/365230.365233
> Yes, and? B5500 ALGOL was a very good implementation of ALGOL-58, except
> that stream procedures bypassed all the hardware protection mechanisms. I
> think Burroughs fixed this on later machines. ALGOL was later sunk by the
> development of ALGOL-68, which (AIUI) was more different from ALGOL-60 than
> C++ is from C.

Stream procedures could manipulate words that had the flag bit set, and
to the best of my recollection, that's the only hardware protection the
B5500 had. The Large System series -- the B6500/6700 on up -- had a more
complete capability architecture with three tag bits, and compilers that
generated user programs wouldn't emit operators that would touch words
with odd tags.

As a teenage nerd, I thought stream procedures were the coolest thing ever.

If Burroughs Large Systems -- or their Unisys successors -- had
attracted more users, especially at universities, there might have been
a reason to design a practical and portable version of ALGOL. Burroughs
Extended ALGOL and Large Systems' architecture were said to have been
designed together; I attended a few Burroughs users' conferences until
about 1982, and portability of source programs to other systems was a
concept I never heard discussed.

I would guess that most users of Burroughs Extended ALGOL had no idea
that the language had a history outside Burroughs and that things called
ALGOL-58 and ALGOL-60 existed. I certainly didn't have a clue.

> ALGOL and PL/I suffered from the same syndrome where FORTRAN programmers
> wanted FORTRAN and COBOL programmers wanted COBOL, and that didn’t leave
> much room for anything else at the time.
>

There was a PL/I compiler for Burroughs Large Systems, but it was big
and complex and slow and not entirely bug-free and relatively few people
used it.

Louis

Louis Krupp <lkrupp@invalid.pssw.com.invalid> schrieb:
> See the second column on the first page:
>
> https://dl.acm.org/doi/pdf/10.1145/365230.365233

Lack of standardized I/O was a huge design flaw, each compiler
had to roll its own, so there was no portability across systems.

Kernighan wrote this in "UNIX: A History and a Memoir" that there
are three possibilities of doing I/O in a langue: Integrated into
the language itself (Fortran, Pascal), implemented in a library (C)
or not specifyling this at all. The last he called (from memory)
the least desirable option.

And FORTRAN was not only groundbreaking in optimization and writing
formulas in a "natural" way. Its I/O was also radical and new,
the FORMAT statement was a big innovation.

On 9/1/2022 11:11 PM, Louis Krupp wrote:
> On 9/1/2022 4:13 PM, Peter Flass wrote:
>> Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>>> See the second column on the first page:
>>>
>>> https://dl.acm.org/doi/pdf/10.1145/365230.365233
>> Yes, and? B5500 ALGOL was a very good implementation of ALGOL-58, except
>> that stream procedures bypassed all the hardware protection mechanisms. I
>> think Burroughs fixed this on later machines. ALGOL was later sunk by the
>> development of ALGOL-68, which (AIUI) was more different from ALGOL-60
>> than
>> C++ is from C.
>
> Stream procedures could manipulate words that had the flag bit set, and
> to the best of my recollection, that's the only hardware protection the
> B5500 had. The Large System series -- the B6500/6700 on up -- had a more
> complete capability architecture with three tag bits, and compilers that
> generated user programs wouldn't emit operators that would touch words
> with odd tags.
>
> As a teenage nerd, I thought stream procedures were the coolest thing ever.
>
> If Burroughs Large Systems -- or their Unisys successors -- had
> attracted more users, especially at universities, there might have been
> a reason to design a practical and portable version of ALGOL.

Given that the original Algol didn't specify any I/O, so each
implementation did their own, it was hard to be portable. In fact one
"definition" of Pascal, was Algol plus I/O.

> Burroughs
> Extended ALGOL and Large Systems' architecture were said to have been
> designed together; I attended a few Burroughs users' conferences until
> about 1982, and portability of source programs to other systems was a
> concept I never heard discussed.
>
> I would guess that most users of Burroughs Extended ALGOL had no idea
> that the language had a history outside Burroughs and that things called
> ALGOL-58 and ALGOL-60 existed. I certainly didn't have a clue.

There were Algol compilers for many different architectures. For
example, the Univac 1100 series actually had two different ones. Lack
of compilers wasn't a major factor in Algol's lack of popularity.

>> ALGOL and PL/I suffered from the same syndrome where FORTRAN programmers
>> wanted FORTRAN and COBOL programmers wanted COBOL, and that didn’t leave
>> much room for anything else at the time.
>>
>
> There was a PL/I compiler for Burroughs Large Systems, but it was big
> and complex and slow and not entirely bug-free and relatively few people
> used it.

Same for other architectures. Pl/1 was/is a large and complex language.
Early compilers didn't do too well. I believe it never gained much
popularity outside of IBM, and even there its success was "modest".

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 9/2/2022 9:00 AM, Stephen Fuld wrote:
> On 9/1/2022 11:11 PM, Louis Krupp wrote:
>> On 9/1/2022 4:13 PM, Peter Flass wrote:
>>> Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>>>> See the second column on the first page:
>>>>
>>>> https://dl.acm.org/doi/pdf/10.1145/365230.365233
>>> Yes, and? B5500 ALGOL was a very good implementation of ALGOL-58,
>>> except
>>> that stream procedures bypassed all the hardware protection
>>> mechanisms. I
>>> think Burroughs fixed this on later machines. ALGOL was later sunk
>>> by the
>>> development of ALGOL-68, which (AIUI) was more different from
>>> ALGOL-60 than
>>> C++ is from C.
>>
>> Stream procedures could manipulate words that had the flag bit set,
>> and to the best of my recollection, that's the only hardware
>> protection the B5500 had. The Large System series -- the B6500/6700
>> on up -- had a more complete capability architecture with three tag
>> bits, and compilers that generated user programs wouldn't emit
>> operators that would touch words with odd tags.
>>
>> As a teenage nerd, I thought stream procedures were the coolest thing
>> ever.
>>
>> If Burroughs Large Systems -- or their Unisys successors -- had
>> attracted more users, especially at universities, there might have
>> been a reason to design a practical and portable version of ALGOL.
>
> Given that the original Algol didn't specify any I/O, so each
> implementation did their own, it was hard to be portable.  In fact one
> "definition" of Pascal, was Algol plus I/O.

Burroughs Extended ALGOL borrowed formatting from FORTRAN, changing
FORMAT statements to FORMAT declarations. It seemed natural and obvious
at the time; it would be surprising -- and unfortunate -- if no other
ALGOL implementations did something similar.

>
>
>> Burroughs Extended ALGOL and Large Systems' architecture were said to
>> have been designed together; I attended a few Burroughs users'
>> conferences until about 1982, and portability of source programs to
>> other systems was a concept I never heard discussed.
>>
>> I would guess that most users of Burroughs Extended ALGOL had no idea
>> that the language had a history outside Burroughs and that things
>> called ALGOL-58 and ALGOL-60 existed. I certainly didn't have a clue.
>
> There were Algol compilers for many different architectures.  For
> example, the Univac 1100 series actually had two different ones. Lack
> of compilers wasn't a major factor in Algol's lack of popularity.

Burroughs users tended to be an insular bunch, and I was no exception. I
recall one users conference attendee saying "If my firm changes systems,
I'll change firms." I never imagined that I'd ever be working on
anything else.

<snip>

Louis

On 9/2/2022 11:05 AM, Louis Krupp wrote:
> On 9/2/2022 9:00 AM, Stephen Fuld wrote:
>> On 9/1/2022 11:11 PM, Louis Krupp wrote:
>>> On 9/1/2022 4:13 PM, Peter Flass wrote:
>>>> Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>>>>> See the second column on the first page:
>>>>>
>>>>> https://dl.acm.org/doi/pdf/10.1145/365230.365233
>>>> Yes, and? B5500 ALGOL was a very good implementation of ALGOL-58,
>>>> except
>>>> that stream procedures bypassed all the hardware protection
>>>> mechanisms. I
>>>> think Burroughs fixed this on later machines. ALGOL was later sunk
>>>> by the
>>>> development of ALGOL-68, which (AIUI) was more different from
>>>> ALGOL-60 than
>>>> C++ is from C.
>>>
>>> Stream procedures could manipulate words that had the flag bit set,
>>> and to the best of my recollection, that's the only hardware
>>> protection the B5500 had. The Large System series -- the B6500/6700
>>> on up -- had a more complete capability architecture with three tag
>>> bits, and compilers that generated user programs wouldn't emit
>>> operators that would touch words with odd tags.
>>>
>>> As a teenage nerd, I thought stream procedures were the coolest thing
>>> ever.
>>>
>>> If Burroughs Large Systems -- or their Unisys successors -- had
>>> attracted more users, especially at universities, there might have
>>> been a reason to design a practical and portable version of ALGOL.
>>
>> Given that the original Algol didn't specify any I/O, so each
>> implementation did their own, it was hard to be portable.  In fact one
>> "definition" of Pascal, was Algol plus I/O.
>
> Burroughs Extended ALGOL borrowed formatting from FORTRAN, changing
> FORMAT statements to FORMAT declarations. It seemed natural and obvious
> at the time; it would be surprising -- and unfortunate -- if no other
> ALGOL implementations did something similar.

I don't know about any other Algol implementations, but Pascal certainly
made a different choice.

>>
>>> Burroughs Extended ALGOL and Large Systems' architecture were said to
>>> have been designed together; I attended a few Burroughs users'
>>> conferences until about 1982, and portability of source programs to
>>> other systems was a concept I never heard discussed.
>>>
>>> I would guess that most users of Burroughs Extended ALGOL had no idea
>>> that the language had a history outside Burroughs and that things
>>> called ALGOL-58 and ALGOL-60 existed. I certainly didn't have a clue.
>>
>> There were Algol compilers for many different architectures.  For
>> example, the Univac 1100 series actually had two different ones. Lack
>> of compilers wasn't a major factor in Algol's lack of popularity.
>
> Burroughs users tended to be an insular bunch, and I was no exception. I
> recall one users conference attendee saying "If my firm changes systems,
> I'll change firms." I never imagined that I'd ever be working on
> anything else.

I think that wasn't uncommon with programmers of many different systems.
The mainframes, and even mini-computer systems from different
manufacturers were so different from each other that once you spent a
lot of time and energy learning one, you were reluctant to "waste" all
the learning.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Louis Krupp <lkrupp@invalid.pssw.com.invalid> schrieb:
>> See the second column on the first page:
>>
>> https://dl.acm.org/doi/pdf/10.1145/365230.365233
>
> Lack of standardized I/O was a huge design flaw, each compiler
> had to roll its own, so there was no portability across systems.

On the other hand, in reality simple I/O is pretty common across systems:
read a line/write a line, etc. It’s only the more exotic operations that
differ. If I were writing an ALGOL compiler I’d look at what the other guys
did and imitate it, as compatibly as possible.

>
> Kernighan wrote this in "UNIX: A History and a Memoir" that there
> are three possibilities of doing I/O in a langue: Integrated into
> the language itself (Fortran, Pascal), implemented in a library (C)
> or not specifyling this at all. The last he called (from memory)
> the least desirable option.
>
> And FORTRAN was not only groundbreaking in optimization and writing
> formulas in a "natural" way. Its I/O was also radical and new,
> the FORMAT statement was a big innovation.
>

--
Pete

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> On 9/1/2022 11:11 PM, Louis Krupp wrote:
>> On 9/1/2022 4:13 PM, Peter Flass wrote:
>>> Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>>>> See the second column on the first page:
>>>>
>>>> https://dl.acm.org/doi/pdf/10.1145/365230.365233
>>> Yes, and? B5500 ALGOL was a very good implementation of ALGOL-58, except
>>> that stream procedures bypassed all the hardware protection mechanisms. I
>>> think Burroughs fixed this on later machines. ALGOL was later sunk by the
>>> development of ALGOL-68, which (AIUI) was more different from ALGOL-60
>>> than
>>> C++ is from C.
>>
>> Stream procedures could manipulate words that had the flag bit set, and
>> to the best of my recollection, that's the only hardware protection the
>> B5500 had. The Large System series -- the B6500/6700 on up -- had a more
>> complete capability architecture with three tag bits, and compilers that
>> generated user programs wouldn't emit operators that would touch words
>> with odd tags.
>>
>> As a teenage nerd, I thought stream procedures were the coolest thing ever.
>>
>> If Burroughs Large Systems -- or their Unisys successors -- had
>> attracted more users, especially at universities, there might have been
>> a reason to design a practical and portable version of ALGOL.
>
> Given that the original Algol didn't specify any I/O, so each
> implementation did their own, it was hard to be portable. In fact one
> "definition" of Pascal, was Algol plus I/O.
>
>
>> Burroughs
>> Extended ALGOL and Large Systems' architecture were said to have been
>> designed together; I attended a few Burroughs users' conferences until
>> about 1982, and portability of source programs to other systems was a
>> concept I never heard discussed.
>>
>> I would guess that most users of Burroughs Extended ALGOL had no idea
>> that the language had a history outside Burroughs and that things called
>> ALGOL-58 and ALGOL-60 existed. I certainly didn't have a clue.
>
> There were Algol compilers for many different architectures. For
> example, the Univac 1100 series actually had two different ones. Lack
> of compilers wasn't a major factor in Algol's lack of popularity.

Univac went completely off the deep end. They had at least two 1100 COBOL
compilers, too.

--
Pete

Peter Flass wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>> On 9/1/2022 11:11 PM, Louis Krupp wrote:
>>> On 9/1/2022 4:13 PM, Peter Flass wrote:
>>>> Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>>>>> See the second column on the first page:
>>>>>
>>>>> https://dl.acm.org/doi/pdf/10.1145/365230.365233
>>>> Yes, and? B5500 ALGOL was a very good implementation of ALGOL-58, except
>>>> that stream procedures bypassed all the hardware protection mechanisms. I
>>>> think Burroughs fixed this on later machines. ALGOL was later sunk by the
>>>> development of ALGOL-68, which (AIUI) was more different from ALGOL-60
>>>> than
>>>> C++ is from C.
>>>
>>> Stream procedures could manipulate words that had the flag bit set, and
>>> to the best of my recollection, that's the only hardware protection the
>>> B5500 had. The Large System series -- the B6500/6700 on up -- had a more
>>> complete capability architecture with three tag bits, and compilers that
>>> generated user programs wouldn't emit operators that would touch words
>>> with odd tags.
>>>
>>> As a teenage nerd, I thought stream procedures were the coolest thing ever.
>>>
>>> If Burroughs Large Systems -- or their Unisys successors -- had
>>> attracted more users, especially at universities, there might have been
>>> a reason to design a practical and portable version of ALGOL.
>>
>> Given that the original Algol didn't specify any I/O, so each
>> implementation did their own, it was hard to be portable. In fact one
>> "definition" of Pascal, was Algol plus I/O.
>>
>>
>>> Burroughs
>>> Extended ALGOL and Large Systems' architecture were said to have been
>>> designed together; I attended a few Burroughs users' conferences until
>>> about 1982, and portability of source programs to other systems was a
>>> concept I never heard discussed.
>>>
>>> I would guess that most users of Burroughs Extended ALGOL had no idea
>>> that the language had a history outside Burroughs and that things called
>>> ALGOL-58 and ALGOL-60 existed. I certainly didn't have a clue.
>>
>> There were Algol compilers for many different architectures. For
>> example, the Univac 1100 series actually had two different ones. Lack
>> of compilers wasn't a major factor in Algol's lack of popularity.
>
> Univac went completely off the deep end. They had at least two 1100 COBOL
> compilers, too.
>

That's an outsiders view, if you knew the reasons it made perfect sense.

The 1100/2200 side has two addressing modes, the original one dating
back to the post-Noah's Ark cleanup (Basic Mode), and one which I first
noticed in the 1980s (Extended Mode, aka UCS). UCS allows you to access
far more memory than BM does, BM has no problems with instructions but
the amount of data you can have visible is really limited by today's
standards.

Univac also started off with a 6-bit character set called Fieldata.

- COB (or FCOB not sure) - BM, Fieldata
- ACOB - BM, Ascii but can handle Fieldata
- UCOB - EM/UCS, Ascii with rudimentary Fdata capabilities
- OO-COB - EM/UCS with an IDE, I never used it.
The various compilers also implement different COBOL standards, I
believe OO-COB no longer understands the ALTER command for instance.

Interaction between BM and EM/UCS is "difficult", switching between the
two requires the use of MASM (assembler). MASM is also the only program
which can generate BM code and UCS code, or a mixture of the two.

Converting ACOB programs to UCOB can be trivial or it can be fraught -
depending on the use of certain features by the programmer, there is
also a compatability mode you can use.

On 9/2/2022 11:05 AM, Louis Krupp wrote:
> On 9/2/2022 9:00 AM, Stephen Fuld wrote:
>> On 9/1/2022 11:11 PM, Louis Krupp wrote:
>>> On 9/1/2022 4:13 PM, Peter Flass wrote:
>>>> Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>>>>> See the second column on the first page:
>>>>>
>>>>> https://dl.acm.org/doi/pdf/10.1145/365230.365233
>>>> Yes, and? B5500 ALGOL was a very good implementation of
>>>> ALGOL-58, except that stream procedures bypassed all the
>>>> hardware protection mechanisms. I think Burroughs fixed this on
>>>> later machines. ALGOL was later sunk by the development of
>>>> ALGOL-68, which (AIUI) was more different from ALGOL-60 than
>>>> C++ is from C.

No, B5000 and B5500 ALGOL were implementations of ALGOL-60, not
ALGOL-58, but the hardware and compiler were designed and implemented
before the Revised Report was published in January 1963.

Burroughs 220 BALGOL was closely based on ALGOL-58 (although it wasn't
called that originally -- it was the International Algorithmic Language,
or IAL). ALGOL-58 was never a real language design, just a progress
report on the work that eventually produced ALGOL-60.
>>>
>>> Stream procedures could manipulate words that had the flag bit
>>> set, and to the best of my recollection, that's the only hardware
>>> protection the B5500 had. The Large System series -- the
>>> B6500/6700 on up -- had a more complete capability architecture
>>> with three tag bits, and compilers that generated user programs
>>> wouldn't emit operators that would touch words with odd tags.
>>>
>>> As a teenage nerd, I thought stream procedures were the coolest
>>> thing ever.

Yes, Stream Procedures were very cool, and very useful, and very, very
dangerous. They were included in Burroughs Extended ALGOL to give access
to the B5000's Character Mode instructions, which had been a (somewhat
panicked) late addition to the architecture to support the large market
that Burroughs had in commercial business applications, and to support
the then very-new language COBOL. Bypassing hardware-enforced memory
protection was the price for that addition.

The B6500/6700/7700 did indeed fix the lack of memory protection with
the B5000/5500s Character Mode. It also fixed what I think was a more
serious ALGOL-related problem -- the inability of the B5000/5500 to
address intermediate nested scopes in a program. The older machine could
only address the global (outer block) variables and those in the current
local procedure. The hardware simply didn't have the ability to address
any nesting levels between those two.
>>>
>>> If Burroughs Large Systems -- or their Unisys successors -- had
>>> attracted more users, especially at universities, there might
>>> have been a reason to design a practical and portable version of
>>> ALGOL.
>>
>> Given that the original Algol didn't specify any I/O, so each
>> implementation did their own, it was hard to be portable. In fact
>> one "definition" of Pascal, was Algol plus I/O.
>
> Burroughs Extended ALGOL borrowed formatting from FORTRAN, changing
> FORMAT statements to FORMAT declarations. It seemed natural and
> obvious at the time; it would be surprising -- and unfortunate -- if
> no other ALGOL implementations did something similar.

Actually, the B5000/5500's formatting came from 220 BALGOL and was no
doubt heavily influenced by FORTRAN, although FORMAT declarations in
B5000 Extended ALGOL were certainly made more FORTRAN-like than they
were in BALGOL.

In the original B5000 ALGOL implementation, formatted I/O was the only
kind available. There was an ability to do unformatted reads and writes
via the RELEASE statement, but that manipulated physical buffers, much
like Direct I/O does on the later systems, and required the use of
Stream Procedures to access the data. The "array-row I/O" we all know
didn't arrive until the MCP was rewritten (in a higher-level language,
ESPOL) for the B5500.
>
>>
>>
>>> Burroughs Extended ALGOL and Large Systems' architecture were
>>> said to have been designed together; I attended a few Burroughs
>>> users' conferences until about 1982, and portability of source
>>> programs to other systems was a concept I never heard discussed.
>>>
>>> I would guess that most users of Burroughs Extended ALGOL had no
>>> idea that the language had a history outside Burroughs and that
>>> things called ALGOL-58 and ALGOL-60 existed. I certainly didn't
>>> have a clue.
>>
>> There were Algol compilers for many different architectures. For
>> example, the Univac 1100 series actually had two different ones.
>> Lack of compilers wasn't a major factor in Algol's lack of
>> popularity.

Let's not forget that there were two ALGOL compilers for the B5500 as
well, the original Extended ALGOL with Stream Procedures (plus several
other extensions with which you could undo both yourself and the system
if used improperly), and Compatible ALGOL (or XALGOL), which was
designed to be much safer to use, especially with timesharing systems,
and which would be much easier to port to the upcoming B6500. It used
the syntax that had been developed to support the B6500's string
operators, but was implemented for the B5500 by means of intrinsic
functions.

Let's also remember that the B5500 had two COBOL compilers -- the
original COBOL-61 and the later ANSI COBOL-68 compiler. So Univac's sins
in that regard, as mentioned in a later post to this thread, were hardly
unique.
>
> Burroughs users tended to be an insular bunch, and I was no
> exception. I recall one users conference attendee saying "If my firm
> changes systems, I'll change firms." I never imagined that I'd ever
> be working on anything else.
>
> <snip>
>
> Louis

Paul

-------- Original Message --------
Subject: Re: "In Defense of ALGOL"
From: Peter Flass <peter_flass@yahoo.com>
To:
Date: Fri Sep 02 2022 15:25:08 GMT-0700 (Pacific Daylight Time)

> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Louis Krupp <lkrupp@invalid.pssw.com.invalid> schrieb:
>>> See the second column on the first page:
>>>
>>> https://dl.acm.org/doi/pdf/10.1145/365230.365233
>>
>> Lack of standardized I/O was a huge design flaw, each compiler
>> had to roll its own, so there was no portability across systems.
>
> On the other hand, in reality simple I/O is pretty common across systems:
> read a line/write a line, etc. It’s only the more exotic operations that
> differ. If I were writing an ALGOL compiler I’d look at what the other guys
> did and imitate it, as compatibly as possible.

Which is pretty much what Burroughs did with the B5000/5500. Admittedly
it was FORTRAN-like, but that was the market they had to compete in. If
there ever was a "market" for ALGOL implementations, it certainly didn't
exist in the U.S. in the early 1960s.
>
>>
>> Kernighan wrote this in "UNIX: A History and a Memoir" that there
>> are three possibilities of doing I/O in a langue: Integrated into
>> the language itself (Fortran, Pascal), implemented in a library (C)
>> or not specifyling this at all. The last he called (from memory)
>> the least desirable option.
>>
>> And FORTRAN was not only groundbreaking in optimization and writing
>> formulas in a "natural" way. Its I/O was also radical and new,
>> the FORMAT statement was a big innovation

Paul

On 2022-09-03, Paul Kimpel <paul.kimpel@digm.com> wrote:

> Let's also remember that the B5500 had two COBOL compilers -- the
> original COBOL-61 and the later ANSI COBOL-68 compiler. So Univac's sins
> in that regard, as mentioned in a later post to this thread, were hardly
> unique.

Nor were Univac's "sins" unique to their 1100 series. The 90/30
(whose non-privileged instruction set was a clone of the IBM 360/50)
had three COBOL compilers: Basic COBOL, Extended COBOL, and COBOL-74.

In either case, though, I don't consider it a sin to release
a compiler that supports a later version of a language, while
retaining the old one for compatibility.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.