[TUHS] What would early alternatives to C have been?

[TUHS] What would early alternatives to C have been?

[Dan Cross]

As I mentioned in the discussion about C, it's easy to look back with
a modern perspective and cast aspersions on C. But this got me
thinking, what would possible alternatives have been? In the context
of the very late 1960s heading into the early 70s, and given the
constraints of the PDP-7 and early PDP-11s, what languages would one
consider for implementing a system like early Unix? Dennis's history
paper mentioned a very short-lived effort at Fortran, and I asked
about that a few years ago, but no one really remembered much about
it; I gather this was an experiment that lasted a few days or weeks
and was quickly abandoned. But what else?

My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was
already mentioned. I don't think PL/1 (or PL/I) could have fit on
those machines. Pascal was really targeted towards teaching and would
have required pretty extensive work to be usable. The big question
mark in my mind is Algol/W; how well known was it at the time? Was any
consideration for it made?

Obviously, the decision to go with BCPL (as the basis for B, which
beget C) was made and the rest is history. But I'm really curious
about how, in the research culture at the time, information about new
programming languages made its way through the community.

        - Dan C.

[TUHS] Re: What would early alternatives to C have been?

[George Michaelson]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

Bliss. After all, DEC stuck to it either Bliss 32.

On Sun, 9 Mar 2025, 1:47 pm Dan Cross, <crossd@gmail.com> wrote:

> As I mentioned in the discussion about C, it's easy to look back with
> a modern perspective and cast aspersions on C. But this got me
> thinking, what would possible alternatives have been? In the context
> of the very late 1960s heading into the early 70s, and given the
> constraints of the PDP-7 and early PDP-11s, what languages would one
> consider for implementing a system like early Unix? Dennis's history
> paper mentioned a very short-lived effort at Fortran, and I asked
> about that a few years ago, but no one really remembered much about
> it; I gather this was an experiment that lasted a few days or weeks
> and was quickly abandoned. But what else?
>
> My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was
> already mentioned. I don't think PL/1 (or PL/I) could have fit on
> those machines. Pascal was really targeted towards teaching and would
> have required pretty extensive work to be usable. The big question
> mark in my mind is Algol/W; how well known was it at the time? Was any
> consideration for it made?
>
> Obviously, the decision to go with BCPL (as the basis for B, which
> beget C) was made and the rest is history. But I'm really curious
> about how, in the research culture at the time, information about new
> programming languages made its way through the community.
>
>         - Dan C.
>

[-- Attachment #2: Type: text/html, Size: 1842 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

ESPOL was basically first, with BCPL, PL/360, and, as George mentioned,
BLISS showing up soon thereafter.

On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote:

> The big question mark in my mind is Algol/W; how well known was it at the
> time?

Any 360 shop, particularly if it was targeted for teaching students, would
likely have had Wirth's compiler.  Remember, as BCPL was to CPL, PL/360 was
to Algol-W.  Unlike BCPL, I don't know of any port of PL/360 outside of the
IBM world.  Algol-W would later be implemented in C, but that was later
after Wirth tried again with Pascal.


> Was any consideration for it made?
>
Only Ken can answer that.   My guess is that Algol-W would have failed for
the same reasons Pascal ultimately failed.   It really was directed at
students and lacked many of the tools C had.  Many of the issues exposed in
Brian's treatise *"Why is Pascal not my favorite programming language"* also
apply to Algol-W.

At the time, BLISS had the advantage of the first "Green Book" style
optimizer, so in comparison to the original B and later C compilers, their
code generators were almost toys. I believe that the killer for BLISS was
DEC's choice to charge $5K per/cpu and to few places were willing to pay
it. But as Paul points out BLISS was word-oriented, which, from a technical
point of view, made it more difficult to use than C.
ᐧ

[-- Attachment #2: Type: text/html, Size: 3609 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]

At 2025-03-09T08:29:43-0400, Clem Cole wrote:
> On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote:
> > Was any consideration for it made?
> >
> Only Ken can answer that.   My guess is that Algol-W would have failed
> for the same reasons Pascal ultimately failed.   It really was
> directed at students and lacked many of the tools C had.  Many of the
> issues exposed in Brian's treatise *"Why is Pascal not my favorite
> programming language"* also apply to Algol-W.

I think it's worth noting that, as I undertand it from having read the
paper, old Pascal manuals, and ISO 7185 (and, a long time ago,
experience with Borland Turbo Pascal), most or all of the defects
Kernighan pointed out were addressed by vendored versions of Pascal and
ultimately by its ISO standard form.  I think even UCSD Pascal had
extensions, though I don't recall what they were.

My grasp of the chronology is poor, though, and I'd concede that Wirth's
Pascal of his 1973 memorandum wears most or all of the mud Kernighan
threw at it.  For the most part, solving the problems Kerngihan observed
did not require doing violence to the language (in other words, they
could be solved with extensions rather than by altering the semantics of
valid 1973 Pascal syntax).

Maybe this is what it means to have been "directed at students"--that
easy wins in terms of language improvement were not implemented because
covering them topically in a semester-long university course would not
have been practical.  If so, that may make the tragedy of Pascal
greater, not smaller.

Though even that doesn't explain why Wirth didn't spec Pascal functions
to admit polymorphism (perhaps optionally) in array length.  That's an
essential property for all sorts of work, even that undertaken by
students.  (Say you want them to write a function that multiplies
matrices.  You shouldn't have to specialize the function by matrix
dimensions.  The obvious pinch point for a Unix programmer is massive
inconvenience if you want to handle variable-length strings.)

Perusing its manual some months ago, it occurred to me that if someone
had had the foresight to implement the language core of Turbo Pascal
7.0, ignoring the libraries/"modules" entirely, and omitting the crap
necessary to work with the x86 segmented memory model, I don't think
Kernighan would have had much, if anything, to complain about.  And, in
my opinion, we'd be living in a better timeline.

But I guess Pascal just didn't get good enough, soon enough.

And I wonder how big such a compiler would be, even if coded
competently.

Chronology bedevils us in another way.  A _lot_ of C language features
its advocates are proud of were not present in 1973 or even when
Kernighan wrote CSTR #100 around 1980.  It is an error to substitute the
ANSI C of 1989 for the C that actually existed at the time when asking
who'd win in a fight between C and Pascal taking place in, say, 1977.

https://gunkies.org/wiki/Typesetter_C

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 10132 bytes --]

On Sun, Mar 9, 2025 at 9:18 AM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> At 2025-03-09T08:29:43-0400, Clem Cole wrote:
> > On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote:
> > > Was any consideration for it made?
> > >
> > Only Ken can answer that.   My guess is that Algol-W would have failed
> > for the same reasons Pascal ultimately failed.   It really was
> > directed at students and lacked many of the tools C had.  Many of the
> > issues exposed in Brian's treatise *"Why is Pascal not my favorite
> > programming language"* also apply to Algol-W.
>
> I think it's worth noting that, as I undertand it from having read the
> paper, old Pascal manuals, and ISO 7185 (and, a long time ago,
> experience with Borland Turbo Pascal), most or all of the defects
> Kernighan pointed out were addressed by vendored versions of Pascal and
> ultimately by its ISO standard form.  I think even UCSD Pascal had
> extensions, though I don't recall what they were.
>
Branden — respectfully, if you download the standard
https://archive.org/details/iso-iec-7185-1990-Pascal or look at versions
that have been converted to HTML such as
https://wiki.freepascal.org/Standard_Pascal,  that statement is a tad
hollow. Sadly, that is the issue with Pascal.  The fundamental flaws of the
core Pascal language remained as described in Brian’s paper as:

1. Since the size of an array is part of its type, it is not possible to
write general-purpose routines, that is, to deal with arrays of different
sizes. In particular, string handling is very difficult.

2. The lack of static variables, initialization, and a way to communicate
non-hierarchically combine to destroy the ‘‘locality’’ of a program —
variables require much more scope than they ought to.

3. The language's one-pass nature forces procedures and functions to be
presented in an unnatural order; the enforced separation of various
declarations scatters program components that logically belong together.

4. The lack of separate compilation impedes the development of large
programs and makes using external libraries impossible.

5. The order of logical expression evaluation cannot be controlled, which
leads to convoluted code and extraneous variables.

6. The case statement is emasculated because there is no default clause.

7. The standard I/O is defective. There is no sensible provision for
dealing with files or program arguments as part of the standard language
and no extension mechanism.

8. The language lacks most of the tools needed for assembling large
programs, most notably file inclusion.

9. There is no escape.



> My grasp of the chronology is poor, though, and I'd concede that Wirth's
> Pascal of his 1973 memorandum wears most or all of the mud Kernighan
> threw at it.  For the most part, solving the problems Kerngihan observed
> did not require doing violence to the language (in other words, they
> could be solved with extensions rather than by altering the semantics of
> valid 1973 Pascal syntax).
>
You >>are<< correct that many (not all) of the defects Brian and Dave ran
into when updating/rewriting the Software Tools book from FORTRAN (Ratfor)
to Pascal >>could<< have been fixed.  The core issue with Pascal is that if
an implementation did add an extension,* every implementation did it
differently.*

Now, the truth is that having different implementations from different
vendors was not unusual.  The whole reason ASA developed FORTRAN-66, which
begat the many versions that followed [I believe FORTRAN-2018 is the last
verified version, but I'm told by Dr. FORTRAN [Steve Lionel] that they are
preparing an updated draft. BASIC had it in spades.  In fact, at one of the
early 'Hatfield/McCoy" parties between my friends at HP and Tektronix, we
count 14 different flavors of "HP BASIC" and 6 different flavors of "Tek
Pascal."

>
> Maybe this is what it means to have been "directed at students"--that
> easy wins in terms of language improvement were not implemented because
> covering them topically in a semester-long university course would not
> have been practical.  If so, that may make the tragedy of Pascal
> greater, not smaller.
>
History.  Wirth was teaching at Stanford when Algol-X was proposed. In the
late 1960s, the International Federation for Information Processing (IFIP)
held the International responsibility for the definition of the programming
language ALGOL 60, chartered IFIP Working Group 2.1 to develop a
replacement for the language which had been identified, notably the lack of
a standardized string subsystem. This effort was dubbed ALGOL X. You can
use an internet search to find several of them, but one of the proposals
was submitted by Niklaus Wirth and Tony Hoare. When their proposal was not
accepted, the language ALGOL 68 would be developed under these auspices.

The committee decided that the Wirth/Hoare proposal was an insufficient
advance over ALGOL 60, and the proposal was published as a contribution to
the development of ALGOL in CACM after making slight modifications to the
language.  Wirth eventually decided to develop his proposal and created an
implementation targeting the IBM System/360 at Stanford University. He
called the new language Algol-W [used in many universities, and I used it
at CMU, and I have friends that used it at Cornell and Princeton].

At the time, Wirth's original target was a tool to teach his students at
Stanford. It was not a "production quality" compiler in the sense of IBM's
FORTRAN-H, which was considered the "best" production compiler at the time.
Also, remember the whole assembler/compiled code was hardly a settled
debate.  Wulf's findings showed BLISS was as good as the best PDP-10/PDP-11
programmers, which was still a few years in the future.  As I've said
elsewhere, it took enough students trained in the ideas from the Green Book
a few years to get into the world to start to develop the optimizers we now
expect as the norm.

>
> Though even that doesn't explain why Wirth didn't spec Pascal functions
> to admit polymorphism (perhaps optionally) in array length.  That's an
> essential property for all sorts of work, even that undertaken by
> students.  (Say you want them to write a function that multiplies
> matrices.  You shouldn't have to specialize the function by matrix
> dimensions.  The obvious pinch point for a Unix programmer is massive
> inconvenience if you want to handle variable-length strings.)
>
Again, it was not considered an issue for what they were trying to solve.
 Read the IFPS meeting notes.

>
> Perusing its manual some months ago, it occurred to me that if someone
> had had the foresight to implement the language core of Turbo Pascal
> 7.0, ignoring the libraries/"modules" entirely, and omitting the crap
> necessary to work with the x86 segmented memory model, I don't think
> Kernighan would have had much, if anything, to complain about.  And, in
> my opinion, we'd be living in a better timeline.
>
Turbo Pascal was a flavor of Pascal that came much later. At the time, UCB
Pascal and UCSD Pascal were the two popular implementations for students,
and commercial folks used Whitesmiths and, later, OMSI. The first three
were the compilers Brian and PJ used (I believe all were running a V7 Unix,
but I'm not positive about the target OS).

FWIW: today's popular Pascal is Free Pascal (freepascal.org), and it
accepts all of the syntax of Turbo, Object Pascal, and Delphi as input. But
it was too late.

>
> But I guess Pascal just didn't get good enough, soon enough.
>
No, it was not agreed upon.  Everyone developing a Pascal implementation
was pushing their flavor (sound familiar).  Turbo "won" when they targeted
DOS, which, at the time, was being ignored by the traditional
"professional" programmers (DOS was too much of a "toy" to be serious. -
Minicomputers were the bread and butter).  When PharLap created an OS
extension that allowed for a real 32-bit C for the 386, UNIX and C had
already taken the mantel, and Pascal was losing favor in the DOS world.

>
> And I wonder how big such a compiler would be, even if coded
> competently.
>
Look at OMSI, which primarily targeted the PDP-11.  It has many of these
extensions [it basically started as one of the Tek Pascal's, BTW.  Jon and
I worked with some folks who developed it.]

>
> Chronology bedevils us in another way.  A _lot_ of C language features
> its advocates are proud of were not present in 1973 or even when
> Kernighan wrote CSTR #100 around 1980.

Please be careful here. The point is that in 1980, Pascal and C, as
described by Brain, C did not have the issues I listed above, but the
popular Pascal implementations being used in the wild did.



> It is an error to substitute the ANSI C of 1989 for the C that actually
> existed at the time when asking
> who'd win in a fight between C and Pascal taking place in, say, 1977.
>
I don't since I lived it.

>
> https://gunkies.org/wiki/Typesetter_C

Need to work with Noel to update that page -- that name was because it came
with the original ditroff - which used libS.a to replace Lesk's portable
I/O library.    It was less an issue of new compiler language features and
more the requirement for a new I/O library.  Remember, C and BLISS, as
examples are defined without an I/O library in their origin stories.  They
both use the local OS's IO interface.  C does not formally get an I/O
library until Typesetter C and White Book.   Simply, until C moved to the
Honeywell and 360  nd people started to "port" code, that Lesk started to
codify an IO library that could be used regardless of the local OS.   Look
at the documentation in V6. You'll see some interesting like fd = -1 and
other artifacts that Mike had in so that earlier code would recompile and
relink. With typesetter C, Dennis forced a small rewrite of your code to use
libS.a.

As I said, I lived this whole war.
Crumudgingly yours,
Clem
ᐧ

[-- Attachment #2: Type: text/html, Size: 17636 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Ken Thompson]

[-- Attachment #1: Type: text/plain, Size: 11150 bytes --]

how about smalgol?

it was an algol-like language with just int and float types.
i dont know its history, but it came out of berkeley near
when Niklaus Wirth was there. it compiled for the ibm 7094
in normal batch processing fashion. i converted it to a jit
into memory in order to skip the loading phase. i used
it for a lot of my fun-work. (1965-66)

mainframe time, then, was a big factor in the computing process.
smalgol could compile, load, and run in about 1 cpu-second.

smalgol was all ibm-cards, but it was on my mind through
the bcpl to b to nb phases. i would use the modern word
"influencer."



On Sun, Mar 9, 2025 at 10:37 AM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Sun, Mar 9, 2025 at 9:18 AM G. Branden Robinson <
> g.branden.robinson@gmail.com> wrote:
>
>> At 2025-03-09T08:29:43-0400, Clem Cole wrote:
>> > On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote:
>> > > Was any consideration for it made?
>> > >
>> > Only Ken can answer that.   My guess is that Algol-W would have failed
>> > for the same reasons Pascal ultimately failed.   It really was
>> > directed at students and lacked many of the tools C had.  Many of the
>> > issues exposed in Brian's treatise *"Why is Pascal not my favorite
>> > programming language"* also apply to Algol-W.
>>
>> I think it's worth noting that, as I undertand it from having read the
>> paper, old Pascal manuals, and ISO 7185 (and, a long time ago,
>> experience with Borland Turbo Pascal), most or all of the defects
>> Kernighan pointed out were addressed by vendored versions of Pascal and
>> ultimately by its ISO standard form.  I think even UCSD Pascal had
>> extensions, though I don't recall what they were.
>>
> Branden — respectfully, if you download the standard
> https://archive.org/details/iso-iec-7185-1990-Pascal or look at versions
> that have been converted to HTML such as
> https://wiki.freepascal.org/Standard_Pascal,  that statement is a tad
> hollow. Sadly, that is the issue with Pascal.  The fundamental flaws of
> the core Pascal language remained as described in Brian’s paper as:
>
> 1. Since the size of an array is part of its type, it is not possible to
> write general-purpose routines, that is, to deal with arrays of different
> sizes. In particular, string handling is very difficult.
>
> 2. The lack of static variables, initialization, and a way to communicate
> non-hierarchically combine to destroy the ‘‘locality’’ of a program —
> variables require much more scope than they ought to.
>
> 3. The language's one-pass nature forces procedures and functions to be
> presented in an unnatural order; the enforced separation of various
> declarations scatters program components that logically belong together.
>
> 4. The lack of separate compilation impedes the development of large
> programs and makes using external libraries impossible.
>
> 5. The order of logical expression evaluation cannot be controlled, which
> leads to convoluted code and extraneous variables.
>
> 6. The case statement is emasculated because there is no default clause.
>
> 7. The standard I/O is defective. There is no sensible provision for
> dealing with files or program arguments as part of the standard language
> and no extension mechanism.
>
> 8. The language lacks most of the tools needed for assembling large
> programs, most notably file inclusion.
>
> 9. There is no escape.
>
>
>
>> My grasp of the chronology is poor, though, and I'd concede that Wirth's
>> Pascal of his 1973 memorandum wears most or all of the mud Kernighan
>> threw at it.  For the most part, solving the problems Kerngihan observed
>> did not require doing violence to the language (in other words, they
>> could be solved with extensions rather than by altering the semantics of
>> valid 1973 Pascal syntax).
>>
> You >>are<< correct that many (not all) of the defects Brian and Dave ran
> into when updating/rewriting the Software Tools book from FORTRAN (Ratfor)
> to Pascal >>could<< have been fixed.  The core issue with Pascal is that
> if an implementation did add an extension,* every implementation did it
> differently.*
>
> Now, the truth is that having different implementations from different
> vendors was not unusual.  The whole reason ASA developed FORTRAN-66, which
> begat the many versions that followed [I believe FORTRAN-2018 is the last
> verified version, but I'm told by Dr. FORTRAN [Steve Lionel] that they are
> preparing an updated draft. BASIC had it in spades.  In fact, at one of the
> early 'Hatfield/McCoy" parties between my friends at HP and Tektronix, we
> count 14 different flavors of "HP BASIC" and 6 different flavors of "Tek
> Pascal."
>
>>
>> Maybe this is what it means to have been "directed at students"--that
>> easy wins in terms of language improvement were not implemented because
>> covering them topically in a semester-long university course would not
>> have been practical.  If so, that may make the tragedy of Pascal
>> greater, not smaller.
>>
> History.  Wirth was teaching at Stanford when Algol-X was proposed. In
> the late 1960s, the International Federation for Information Processing
> (IFIP) held the International responsibility for the definition of the
> programming language ALGOL 60, chartered IFIP Working Group 2.1 to develop
> a replacement for the language which had been identified, notably the lack
> of a standardized string subsystem. This effort was dubbed ALGOL X. You
> can use an internet search to find several of them, but one of the
> proposals was submitted by Niklaus Wirth and Tony Hoare. When their
> proposal was not accepted, the language ALGOL 68 would be developed under
> these auspices.
>
> The committee decided that the Wirth/Hoare proposal was an insufficient
> advance over ALGOL 60, and the proposal was published as a contribution to
> the development of ALGOL in CACM after making slight modifications to the
> language.  Wirth eventually decided to develop his proposal and created an
> implementation targeting the IBM System/360 at Stanford University. He
> called the new language Algol-W [used in many universities, and I used it
> at CMU, and I have friends that used it at Cornell and Princeton].
>
> At the time, Wirth's original target was a tool to teach his students at
> Stanford. It was not a "production quality" compiler in the sense of IBM's
> FORTRAN-H, which was considered the "best" production compiler at the time.
> Also, remember the whole assembler/compiled code was hardly a settled
> debate.  Wulf's findings showed BLISS was as good as the best PDP-10/PDP-11
> programmers, which was still a few years in the future.  As I've said
> elsewhere, it took enough students trained in the ideas from the Green Book
> a few years to get into the world to start to develop the optimizers we now
> expect as the norm.
>
>>
>> Though even that doesn't explain why Wirth didn't spec Pascal functions
>> to admit polymorphism (perhaps optionally) in array length.  That's an
>> essential property for all sorts of work, even that undertaken by
>> students.  (Say you want them to write a function that multiplies
>> matrices.  You shouldn't have to specialize the function by matrix
>> dimensions.  The obvious pinch point for a Unix programmer is massive
>> inconvenience if you want to handle variable-length strings.)
>>
> Again, it was not considered an issue for what they were trying to solve.
>  Read the IFPS meeting notes.
>
>>
>> Perusing its manual some months ago, it occurred to me that if someone
>> had had the foresight to implement the language core of Turbo Pascal
>> 7.0, ignoring the libraries/"modules" entirely, and omitting the crap
>> necessary to work with the x86 segmented memory model, I don't think
>> Kernighan would have had much, if anything, to complain about.  And, in
>> my opinion, we'd be living in a better timeline.
>>
> Turbo Pascal was a flavor of Pascal that came much later. At the time, UCB
> Pascal and UCSD Pascal were the two popular implementations for students,
> and commercial folks used Whitesmiths and, later, OMSI. The first three
> were the compilers Brian and PJ used (I believe all were running a V7 Unix,
> but I'm not positive about the target OS).
>
> FWIW: today's popular Pascal is Free Pascal (freepascal.org), and it
> accepts all of the syntax of Turbo, Object Pascal, and Delphi as input.
> But it was too late.
>
>>
>> But I guess Pascal just didn't get good enough, soon enough.
>>
> No, it was not agreed upon.  Everyone developing a Pascal implementation
> was pushing their flavor (sound familiar).  Turbo "won" when they targeted
> DOS, which, at the time, was being ignored by the traditional
> "professional" programmers (DOS was too much of a "toy" to be serious. -
> Minicomputers were the bread and butter).  When PharLap created an OS
> extension that allowed for a real 32-bit C for the 386, UNIX and C had
> already taken the mantel, and Pascal was losing favor in the DOS world.
>
>>
>> And I wonder how big such a compiler would be, even if coded
>> competently.
>>
> Look at OMSI, which primarily targeted the PDP-11.  It has many of these
> extensions [it basically started as one of the Tek Pascal's, BTW.  Jon
> and I worked with some folks who developed it.]
>
>>
>> Chronology bedevils us in another way.  A _lot_ of C language features
>> its advocates are proud of were not present in 1973 or even when
>> Kernighan wrote CSTR #100 around 1980.
>
> Please be careful here. The point is that in 1980, Pascal and C, as
> described by Brain, C did not have the issues I listed above, but the
> popular Pascal implementations being used in the wild did.
>
>
>
>> It is an error to substitute the ANSI C of 1989 for the C that actually
>> existed at the time when asking
>> who'd win in a fight between C and Pascal taking place in, say, 1977.
>>
> I don't since I lived it.
>
>>
>> https://gunkies.org/wiki/Typesetter_C
>
> Need to work with Noel to update that page -- that name was because it
> came with the original ditroff - which used libS.a to replace Lesk's
> portable I/O library.    It was less an issue of new compiler language
> features and more the requirement for a new I/O library.  Remember, C and
> BLISS, as examples are defined without an I/O library in their origin
> stories.  They both use the local OS's IO interface.  C does not formally
> get an I/O library until Typesetter C and White Book.   Simply, until C
> moved to the Honeywell and 360  nd people started to "port" code, that Lesk
> started to codify an IO library that could be used regardless of the local
> OS.   Look at the documentation in V6. You'll see some interesting like fd
> = -1 and other artifacts that Mike had in so that earlier code would
> recompile and relink. With typesetter C, Dennis forced a small rewrite of
> your code to use libS.a.
>
> As I said, I lived this whole war.
> Crumudgingly yours,
> Clem
> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 18695 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 20373 bytes --]

Hi Clem,

Thanks for you detailed response.  I appreciate getting perspectives
from people who fought in the wars I'm too young to remember; I visit
the memorials and try to imagine what things were like.

At 2025-03-09T13:29:55-0400, Clem Cole wrote:
> On Sun, Mar 9, 2025 at 9:18 AM G. Branden Robinson <
> g.branden.robinson@gmail.com> wrote:
> > At 2025-03-09T08:29:43-0400, Clem Cole wrote:
> > > On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote:
> > > > Was any consideration for it made?
> > > Only Ken can answer that.   My guess is that Algol-W would have
> > > failed for the same reasons Pascal ultimately failed.   It really
> > > was directed at students and lacked many of the tools C had.  Many
> > > of the issues exposed in Brian's treatise *"Why is Pascal not my
> > > favorite programming language"* also apply to Algol-W.
> >
> > I think it's worth noting that, as I undertand it from having read
> > the paper, old Pascal manuals, and ISO 7185 (and, a long time ago,
> > experience with Borland Turbo Pascal), most or all of the defects
> > Kernighan pointed out were addressed by vendored versions of Pascal
> > and ultimately by its ISO standard form.  I think even UCSD Pascal
> > had extensions, though I don't recall what they were.
> >
> Branden — respectfully, if you download the standard
> https://archive.org/details/iso-iec-7185-1990-Pascal

I keep a copy on my tablet!  Alongside two Free Pascal and the Turbo
Pascal 7.0 manuals.  I didn't have to fight in the trenches using Pascal
for very long (and when I did, it was with Borland's generously expanded
dialects, a few years apart).

> or look at versions that have been converted to HTML such as
> https://wiki.freepascal.org/Standard_Pascal,  that statement is a tad
> hollow. Sadly, that is the issue with Pascal.

Okay.  I'll take it as homework to double-check how feedble ISO Pascal
is compared to the version critiqued by Kernighan.

Hmm, I can already see that I might have confused ISO Standard Pascal
(ISO 7185) with ISO Extended Pascal (ISO 10206).  Both standards, but
only one named "Standard".  I apologize for my error.

> The fundamental flaws of the core Pascal language remained as
> described in Brian’s paper as:
> 
> 1. Since the size of an array is part of its type, it is not possible
> to write general-purpose routines, that is, to deal with arrays of
> different sizes. In particular, string handling is very difficult.

Yeah.  That's a brutal flaw that every defender of Wirth Pascal has to
concede at the risk of not being taken seriously.

> 2. The lack of static variables, initialization, and a way to
> communicate non-hierarchically combine to destroy the ‘‘locality’’ of
> a program — variables require much more scope than they ought to.

That's also a flaw, but C doesn't distinguish itself strongly here;
`static` function linkage should have been the default.  We should have
had a `public` keyword (or synonym) instead.  (Rust, to my great
surprise, seems to have convinced people that `const` default is good
too--hence `let mut`--and it is, for many reasons including concurrency.
Even my beloved Ada was not so forward-looking.)

> 3. The language's one-pass nature forces procedures and functions to
> be presented in an unnatural order; the enforced separation of various
> declarations scatters program components that logically belong
> together.

But that was true of C for a long time as well; as I understand it,
one-pass C compilers were important enough that intermixed statements
and declarations were allowed into the standard only in C99.  That's a
long time after CSTR #100.

And for me, writing to minimize forward declarations _is_ the natural
order.  Just as in documentation, we want to avoid employing concepts
before we've introduced them.

(If your `main()` is either really short or strictly a sequence of calls
to functions returning `void`, such that it reads like a procedural
checklist, only then would I tolerate it at the top of the source file.)

> 4. The lack of separate compilation impedes the development of large
> programs and makes using external libraries impossible.

This one's about as brutal as point 1.  It requires concession.
Modularity is critical.

> 5. The order of logical expression evaluation cannot be controlled,
> which leads to convoluted code and extraneous variables.

Some of this blows back onto C.  Yes, short-circuit logical evaluation
operators are desirable, but apart from that the order of expression
evaluation in C (a) is frequenly not specified so that compilers can
generate fast code for the hardware; or (b) demands that the programmer
remember something like 15 levels of operator precedence, which is
savage cruelty in my opinion.

Here I am recently correcting a dopey mistake of mine along those lines.

https://git.savannah.gnu.org/cgit/groff.git/commit/?id=a0171c9dc12daa8e70b9178bfac63aa11745110b

> 6. The case statement is emasculated because there is no default
> clause.

I'll freely grant this one, too, and go still farther and say that both
Pascal _and_ C should have required Haskell-style exhaustive coverage of
the controlling variable's domain.

C's support for sum types was (and is) bad, and Pascal's started down
the right road but then gave it up partway, to amplify Kernighan's
point.

> 7. The standard I/O is defective. There is no sensible provision for
> dealing with files or program arguments as part of the standard language
> and no extension mechanism.

To my horror, when learning Java I discovered that it had managed to
discard the basic competence of console/terminal I/O supported by C's
stdio library.  I don't dispute that C shone here.  I think Korn and Vo
have solid critiques of other aspects of stdio, and I find the
irregularity of function names, argument order, and some aspects of
behavior (such as whether an output function appends a newline or not)
annoying, but I would not dispute that it's easier than in most
languages I've dealt with to get a simple "conversational" terminal
application stood up with C.  Yes, you often want a "serious" UI in
curses or a windowing system later (or none at all, relying on argv[]
and the standard I/O streams to do everything as in the filter model),
but that's no reason to fumble the ball on simple Teletype-style I/O.
Yet too many languages did.

Still, scanf() was a bad idea, or at least overapplied, and should not
be taught to students as a tool for interactive I/O handling (as it was
to me--did anyone else have this misfortune?).  For that, a simple
lexical analyzer is necessary because humans produce undisciplined
input.  It's never too early to teach a beginner how to write a finite
state machine.

> 8. The language lacks most of the tools needed for assembling large
> programs, most notably file inclusion.

Once you have separate compilation, this seems mostly like either (a) a
linker problem or (b) a problem better solved by a real macro language
like m4.  The C preprocessor was merely adequate when it could have been
brilliant.

In case anyone feels a dark premonition of where that idea leads: yes,
I'm saying the CSRC should have given us Autoconf instead of the C
preprocessor.  >:-)  If they had, it would be far less hated.

> 9. There is no escape.

And that's why everybody added inline assembly and some added foreign
function interfaces.

> You >>are<< correct that many (not all) of the defects Brian and Dave
> ran into when updating/rewriting the Software Tools book from FORTRAN
> (Ratfor) to Pascal >>could<< have been fixed.  The core issue with
> Pascal is that if an implementation did add an extension,* every
> implementation did it differently.*
> 
> Now, the truth is that having different implementations from different
> vendors was not unusual.  The whole reason ASA developed FORTRAN-66,
> which begat the many versions that followed [I believe FORTRAN-2018 is
> the last verified version, but I'm told by Dr. FORTRAN [Steve Lionel]
> that they are preparing an updated draft. BASIC had it in spades.  In
> fact, at one of the early 'Hatfield/McCoy" parties between my friends
> at HP and Tektronix, we count 14 different flavors of "HP BASIC" and 6
> different flavors of "Tek Pascal."

I guess standardization of Pascal started too late; but both C and C++
took a long time to get to their initial standards too.  What do you
think accounts for C and C++'s greater success, in the specific sense
that vendor extensions didn't cripple the language's development?  What
force kept these languages better governed?

> > Maybe this is what it means to have been "directed at
> > students"--that easy wins in terms of language improvement were not
> > implemented because covering them topically in a semester-long
> > university course would not have been practical.  If so, that may
> > make the tragedy of Pascal greater, not smaller.
> >
> History.  Wirth was teaching at Stanford when Algol-X was proposed. In
> the late 1960s, the International Federation for Information
> Processing (IFIP) held the International responsibility for the
> definition of the programming language ALGOL 60, chartered IFIP
> Working Group 2.1 to develop a replacement for the language which had
> been identified, notably the lack of a standardized string subsystem.
> This effort was dubbed ALGOL X. You can use an internet search to find
> several of them, but one of the proposals was submitted by Niklaus
> Wirth and Tony Hoare. When their proposal was not accepted, the
> language ALGOL 68 would be developed under these auspices.

I've read Lindsey's "A history of ALGOL 68" in HOPL 2 (1996).
Intriguing stuff.  I have no strong opinions about any of it, probably
because no one's either forced me to write in ALGOL 68, nor forbidden me
from doing so.  I do admire its nearly universal loop structure:

[ for index ] [ from first ] [ by increment ] [ to last ] [ while condition ] do statements od

"Nearly" because it's not obvious to me how you'd simulate C's do-while,
which is underrated and under-taught.

And in case anyone's not aware of it, you can play with Algol 68 today.

https://www.theregister.com/2025/01/07/algol_68_comes_to_gcc/

> The committee decided that the Wirth/Hoare proposal was an
> insufficient advance over ALGOL 60, and the proposal was published as
> a contribution to the development of ALGOL in CACM after making slight
> modifications to the language.  Wirth eventually decided to develop
> his proposal and created an implementation targeting the IBM
> System/360 at Stanford University. He called the new language Algol-W
> [used in many universities, and I used it at CMU, and I have friends
> that used it at Cornell and Princeton].
> 
> At the time, Wirth's original target was a tool to teach his students
> at Stanford. It was not a "production quality" compiler in the sense
> of IBM's FORTRAN-H, which was considered the "best" production
> compiler at the time.  Also, remember the whole assembler/compiled
> code was hardly a settled debate.

That was still a live issue when I was learning, but back then (on home
8-bit micros), you had to shell out money to get anything but the BASIC
interpreter that was stored in ROM.  We penurious kids, if pressed,
would hand-assemble code to and poke it into memory to escape the
shackles of the vendor's languid BASIC interpreter (usually under
license from Microsoft).  Made a lot of mistakes and froze the machine
that way.  No illegal instruction traps and no handler for such traps if
we'd had 'em.  Just push reset and hope you'd saved your work.

"a.out?" https://www.nokia.com/bell-labs/about/dennis-m-ritchie/odd.html

> Wulf's findings showed BLISS was as good as the best PDP-10/PDP-11
> programmers, which was still a few years in the future.  As I've said
> elsewhere, it took enough students trained in the ideas from the Green
> Book a few years to get into the world to start to develop the
> optimizers we now expect as the norm.

I'd like to talk to some of that cohort about Ada.

> > Though even that doesn't explain why Wirth didn't spec Pascal
> > functions to admit polymorphism (perhaps optionally) in array
> > length.  That's an essential property for all sorts of work, even
> > that undertaken by students.  (Say you want them to write a function
> > that multiplies matrices.  You shouldn't have to specialize the
> > function by matrix dimensions.  The obvious pinch point for a Unix
> > programmer is massive inconvenience if you want to handle
> > variable-length strings.)
> >
> Again, it was not considered an issue for what they were trying to
> solve.  Read the IFPS meeting notes.

That shocks me, but okay.  I realize I'm probably abusing the term
"polymorphism" here, since that's usually applied to distinguishable
data types.  It bluescreens my brain to think that "iterate along this
vector of identically typed elements until reaching a known terminating
value" was regarded as a technique with any hint of the exotic.  What am
I missing?

> > Perusing its manual some months ago, it occurred to me that if
> > someone had had the foresight to implement the language core of
> > Turbo Pascal 7.0, ignoring the libraries/"modules" entirely, and
> > omitting the crap necessary to work with the x86 segmented memory
> > model, I don't think Kernighan would have had much, if anything, to
> > complain about.  And, in my opinion, we'd be living in a better
> > timeline.
> >
> Turbo Pascal was a flavor of Pascal that came much later.

Yes, TP 1.0 was late 1983; Wirth's spec paper was 1973, UCSD Pascal
1977, and I can't find a date for UCB Pascal, but...

> At the time, UCB Pascal

...Thompson had a hand in writing that one, didn't he?  During his
sabbatical that spawned the CSRG?  If so, that was 1975.

> and UCSD Pascal were the two popular implementations for students, and
> commercial folks used Whitesmiths and, later, OMSI. The first three
> were the compilers Brian and PJ used (I believe all were running a V7
> Unix, but I'm not positive about the target OS).
> 
> FWIW: today's popular Pascal is Free Pascal (freepascal.org), and it
> accepts all of the syntax of Turbo, Object Pascal, and Delphi as
> input. But it was too late.

It's still a highly active project, and one I keep an eye on.  On the
one hand, ports to RISC-V and WASM, and on the other, fixes to its m68k
backend and TP-style text-mode IDE have all seen commits in the past
month.  They also seem to take their documentation seriously, a
significant sign of health in my view.

I have no expectation that it will displace C, but its developers have
my admiration for pushing forward.  Maybe that's because, in maintaining
a typesetting system that _isn't_ TeX, I recognize potentially kindred
spirits.

> > But I guess Pascal just didn't get good enough, soon enough.
> >
> No, it was not agreed upon.  Everyone developing a Pascal
> implementation was pushing their flavor (sound familiar).  Turbo "won"
> when they targeted DOS, which, at the time, was being ignored by the
> traditional "professional" programmers (DOS was too much of a "toy" to
> be serious. -

Well, the professionals weren't wrong.  MS-DOS was a crap OS on a crap
ISA.  They were both market placeholders.  But we don't work, or live,
in a meritocracy.  As ever, the surest route to the head of the line is
to be deposited there at birth by your ancestor.

> Minicomputers were the bread and butter).  When PharLap created an OS
> extension that allowed for a real 32-bit C for the 386, UNIX and C had
> already taken the mantel, and Pascal was losing favor in the DOS
> world.
> 
> > And I wonder how big such a compiler would be, even if coded
> > competently.
> >
> Look at OMSI, which primarily targeted the PDP-11.  It has many of
> these extensions [it basically started as one of the Tek Pascal's,
> BTW.  Jon and I worked with some folks who developed it.]

Oof, for RT-11.  I've booted RSX-11--once--on my PiDP-11.  It was a
jarring experience.  Booting 2.11BSD was headily nostalgic, and took me
_way_ back.  I haven't seen a boot sequence like that in a long time.

> > Chronology bedevils us in another way.  A _lot_ of C language
> > features its advocates are proud of were not present in 1973 or even
> > when Kernighan wrote CSTR #100 around 1980.
> 
> Please be careful here. The point is that in 1980, Pascal and C, as
> described by Brain, C did not have the issues I listed above,

I can't completely agree with you here because as I understand the
critique, C still has _some_ of them _today_.  Often not as badly as in
the past, and almost certainly not as bad as the Pascals of the day.

> but the popular Pascal implementations being used in the wild did.
> 
> > It is an error to substitute the ANSI C of 1989 for the C that
> > actually existed at the time when asking who'd win in a fight
> > between C and Pascal taking place in, say, 1977.
>
> I don't since I lived it.

Yes, but I'm not always aiming at you personally.  :)

> > https://gunkies.org/wiki/Typesetter_C
> 
> Need to work with Noel to update that page -- that name was because it
> came with the original ditroff - which used libS.a to replace Lesk's
> portable I/O library.

I was (am) a bit confused because like you I thought "Typesetter C" was
something else, something later, that was described in the 1-page
article in the V7 manual "Recent Changes to C", which introduced (per
its headings) "Structure assignment" and [an] "Enumeration type".

_But_, that's dated November 15, 1978, which seems a tad early for
Kernighan's device-independent troff work.

"...in the spring of 1979, I set about to modify TROFF so that it would
run henceforth without change on a variety of typesetters." (CSTR #97)

London and Reiser's 1979 paper describing their group's port of Unix to
the VAX-11 (I gather from other sources that the CSRC was upset with DEC
and refused to do it) identifies barriers that the C of the day erected
to portable programming.  Most of them were addressed by ANSI C.

I had thought that device-independent troff directly drove some changes
to the C language (not just support libraries), but maybe I'm wrong.  I
have no idea how the Ritchie compiler or PCC evolved after Seventh
Edition (1979).  Apart from a couple of books (Hancock & Krieger, _C
Primer Plus_, and _Notes on the Draft C Standard_, Tom Plum), I have no
insight into 1980s C.  The main thing I know about it is that if an
implementation targeted x86, it added `near` and `far` keywords to
accommodate segmented memory and/or DOS-style object file formats.  I'd
have learned C (or tried to) a lot younger if I could have afforded a
compiler for it.  Instead I had to wait for GCC.  And a real computer.

> It was less an issue of new compiler language features and more the
> requirement for a new I/O library.  Remember, C and BLISS, as examples
> are defined without an I/O library in their origin stories.  They both
> use the local OS's IO interface.  C does not formally get an I/O
> library until Typesetter C and White Book.   Simply, until C moved to
> the Honeywell and 360  nd people started to "port" code, that Lesk
> started to codify an IO library that could be used regardless of the
> local OS.   Look at the documentation in V6. You'll see some
> interesting like fd = -1 and other artifacts that Mike had in so that
> earlier code would recompile and relink. With typesetter C, Dennis
> forced a small rewrite of your code to use libS.a.

Well, you _could_ bypass it and use read() and write() directly.  Say,
in cat(1), the way Pike intended.  ;-)

> As I said, I lived this whole war.

I appreciate hearing it and I don't mind being corrected (or challenged
on my questionable taste).  I'm a contrarian about C because
triumphalism and other forms of sore winning are not good looks for
engineers.  Every time I blunder into Pascal-style pseudocode, I
experience a pleasant jolt of recognition.

Warmest regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Bakul Shah via TUHS]

On Mar 9, 2025, at 12:41 PM, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> 
> And in case anyone's not aware of it, you can play with Algol 68 today.
> 
> https://www.theregister.com/2025/01/07/algol_68_comes_to_gcc/

a68 has been available for quite a while on Unix (FreeBSD):
See https://www.freshports.org/lang/algol68g

  The Algol 68 Genie project preserves Algol 68 out of educational
  as well as scientific-historical interest, by making a modern,
  well-featured hybrid compiler-interpreter written from scratch,
  which ranks among the most complete Algol 68 implementations.
  It features arbitrary precision arithmetic, complex numbers,
  parallel processing, partial parameterization, and formatted 
  transput, as well as support for curses, regular expressions,
  and sound.

[TUHS] Re: What would early alternatives to C have been?

[John Levine]

It appears that Dan Cross <crossd@gmail.com> said:
>My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was
>already mentioned. I don't think PL/1 (or PL/I) could have fit on
>those machines. ...

There were a lot of PL/I subsets or variants used for system
programming. Intel had PL/M, used to write CP/M. IBM had PL/S, used to
write some parts of OS/360, and reimplemented at RAND in the early
1970s. XPL was writeen at Stanford in the late 1960s, intended for
writing compilers with a small one-pass compiler written in itself.

PL/360 was sort of PL/I-ish although it was really an IBM 360 assembler with
Algol like syntax, used to write Algol W.

One of these could have been a reasonable basis for a system language, but I
don't think the result would have been any better than C.

R's,
John

[TUHS] Re: What would early alternatives to C have been?

[Luther Johnson]

I believe CP/M was written entirely in 8080 assembly language. PL/M was
a PL/1 subset, I think Gary Kildall was the main programmer behind that,
and I'm sure there was a version for CP/M, but I doubt CP/M was written
in it, just due to what I've seen of it. I have a port of CP/M for a
machine I've made and sold, where another programmer and I did the
porting work, and from what I've seen of early DOS and how it was in
many ways modeled after CP/M, it doesn't seem like CP/M was written in
anything other than 8080 assembly. However I've only seen the BIOS (not
IBM PC BIOS, but the original coining of the term for CP/M, standing for
"basic input/output system"), so on the other side, inside of CP/M, I
guess it might be anything, but it seems like it is most likely 8080
assembly language too.

On 03/09/2025 01:13 PM, John Levine wrote:
> It appears that Dan Cross <crossd@gmail.com> said:
>> My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was
>> already mentioned. I don't think PL/1 (or PL/I) could have fit on
>> those machines. ...
> There were a lot of PL/I subsets or variants used for system
> programming. Intel had PL/M, used to write CP/M. IBM had PL/S, used to
> write some parts of OS/360, and reimplemented at RAND in the early
> 1970s. XPL was writeen at Stanford in the late 1960s, intended for
> writing compilers with a small one-pass compiler written in itself.
>
> PL/360 was sort of PL/I-ish although it was really an IBM 360 assembler with
> Algol like syntax, used to write Algol W.
>
> One of these could have been a reasonable basis for a system language, but I
> don't think the result would have been any better than C.
>
> R's,
> John
>

[TUHS] Re: What would early alternatives to C have been?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

On Sun, Mar 9, 2025 at 4:35 PM Luther Johnson <luther.johnson@makerlisp.com>
wrote:

> I believe CP/M was written entirely in 8080 assembly language.

Not initially -- see below.

> PL/M wasa PL/1 subset, I think Gary Kildall was the main programmer behind
> that,
>
Gary was a language person not an OS person.  PL/M was developed by him
under contract with Intel for the original Intel 8080 development system.

> and I'm sure there was a version for CP/M, but I doubt CP/M was written
> in it, just due to what I've seen of it.

From the readme: https://github.com/brouhaha/cpm22

Introduced in 1974, CP/M by Digital Research was one of the first
microcomputer operating systems that was not tied to a single computer
vendor. It could be adapted to run on almost any 8080 or Z80 microcomputer
that had at least 16KB of RAM starting at address 0000h.


Originally much of CP/M was written in the PL/M programming language. With
the introduction of CP/M 2.0, the command processor (CCP) and kernel (BDOS)
were rewritten in 8080 assembly language.



> I have a port of CP/M for a
> machine I've made and sold, where another programmer and I did the
> porting work, and from what I've seen of early DOS and how it was in
> many ways modeled after CP/M, it doesn't seem like CP/M was written in
> anything other than 8080 assembly. However I've only seen the BIOS (not
> IBM PC BIOS, but the original coining of the term for CP/M, standing for
> "basic input/output system"),

Again, the term came from the Intel 8008 development system.



> so on the other side, inside of CP/M, I
> guess it might be anything, but it seems like it is most likely 8080
> assembly language too.
>

As a compiler guy, Kidall was once quoted as the reason who originally
wrote CP/M to sell more copies of his compiler.
ᐧ

[-- Attachment #2: Type: text/html, Size: 4355 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Luther Johnson]

[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]

I see, thank you for the history and clarification. The CP/M I have
worked with is CP/M 2.2. But as I said, the OS inside could have been
written in anything, and now I know in earlier versions, it was
something else, thank you.

On 03/09/2025 01:58 PM, Clem Cole wrote:
>
>
> On Sun, Mar 9, 2025 at 4:35 PM Luther Johnson
> <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>>
> wrote:
>
>     I believe CP/M was written entirely in 8080 assembly language.
>
> Not initially -- see below.
>
>     PL/M wasa PL/1 subset, I think Gary Kildall was the main
>     programmer behind that,
>
> Gary was a language person not an OS person.  PL/M was developed by
> him under contract with Intel for the original Intel 8080 development
> system.
>
>     and I'm sure there was a version for CP/M, but I doubt CP/M was
>     written
>     in it, just due to what I've seen of it.
>
> From the readme: https://github.com/brouhaha/cpm22
>
>     Introduced in 1974, CP/M by Digital Research was one of the first
>     microcomputer operating systems that was not tied to a single
>     computer vendor. It could be adapted to run on almost any 8080 or
>     Z80 microcomputer that had at least 16KB of RAM starting at
>     address 0000h.
>
>
>     Originally much of CP/M was written in the PL/M programming
>     language. With the introduction of CP/M 2.0, the command processor
>     (CCP) and kernel (BDOS) were rewritten in 8080 assembly language.
>
>     I have a port of CP/M for a
>     machine I've made and sold, where another programmer and I did the
>     porting work, and from what I've seen of early DOS and how it was in
>     many ways modeled after CP/M, it doesn't seem like CP/M was written in
>     anything other than 8080 assembly. However I've only seen the BIOS
>     (not
>     IBM PC BIOS, but the original coining of the term for CP/M,
>     standing for
>     "basic input/output system"),
>
> Again, the term came from the Intel 8008 development system.
>
>     so on the other side, inside of CP/M, I
>     guess it might be anything, but it seems like it is most likely 8080
>     assembly language too.
>
>
> As a compiler guy, Kidall was once quoted as the reason who originally
> wrote CP/M to sell more copies of his compiler.
> ᐧ


[-- Attachment #2: Type: text/html, Size: 6570 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Dave Horsfall]

On Sun, 9 Mar 2025, G. Branden Robinson wrote:

> [...] I appreciate getting perspectives from people who fought in the 
> wars I'm too young to remember; I visit the memorials and try to imagine 
> what things were like.

I really enjoyed using ALGOLW in my student days, but not so much Pascal 
(especially the one that ran under CDC KRONOS, as its read-ahead meant 
that you were presented with a "?" prompt before any output was seen).

-- Dave

[TUHS] Re: What would early alternatives to C have been?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

On Sun, Mar 9, 2025 at 2:59 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Sun, Mar 9, 2025 at 4:35 PM Luther Johnson <
> luther.johnson@makerlisp.com> wrote:
>
>> I believe CP/M was written entirely in 8080 assembly language.
>
> Not initially -- see below.
>
>> PL/M wasa PL/1 subset, I think Gary Kildall was the main programmer
>> behind that,
>>
> Gary was a language person not an OS person.  PL/M was developed by him
> under contract with Intel for the original Intel 8080 development system.
>
>> and I'm sure there was a version for CP/M, but I doubt CP/M was written
>> in it, just due to what I've seen of it.
>
> From the readme: https://github.com/brouhaha/cpm22
>
> Introduced in 1974, CP/M by Digital Research was one of the first
> microcomputer operating systems that was not tied to a single computer
> vendor. It could be adapted to run on almost any 8080 or Z80 microcomputer
> that had at least 16KB of RAM starting at address 0000h.
>
>
> Originally much of CP/M was written in the PL/M programming language. With
> the introduction of CP/M 2.0, the command processor (CCP) and kernel (BDOS)
> were rewritten in 8080 assembly language.
>
>
>
>> I have a port of CP/M for a
>> machine I've made and sold, where another programmer and I did the
>> porting work, and from what I've seen of early DOS and how it was in
>> many ways modeled after CP/M, it doesn't seem like CP/M was written in
>> anything other than 8080 assembly. However I've only seen the BIOS (not
>> IBM PC BIOS, but the original coining of the term for CP/M, standing for
>> "basic input/output system"),
>
> Again, the term came from the Intel 8008 development system.
>
>
>
>> so on the other side, inside of CP/M, I
>> guess it might be anything, but it seems like it is most likely 8080
>> assembly language too.
>>
>
> As a compiler guy, Kidall was once quoted as the reason who originally
> wrote CP/M to sell more copies of his compiler.
>

Isn't that what Unix did for C
<duck/>

Warner

> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 4848 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 12350 bytes --]

On Sun, Mar 9, 2025 at 3:42 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> Hi Clem,
>
> Thanks for you detailed response.

Most welcome.


> I appreciate getting perspectives
> from people who fought in the wars I'm too young to remember; I visit
> the memorials and try to imagine what things were like.
>
I think a huge issue is your introduction to computing was on a PC, not on
a mainframe or even a mini.  IMHO the #1 biggest issue with the PC were so
little learnings from either systems was used and so much was re-invented.
As some on once said, instead of standing on the shoulders of the
giants from before, computer scientists seems to step each other other toes.

>
> Hmm, I can already see that I might have confused ISO Standard Pascal
> (ISO 7185) with ISO Extended Pascal (ISO 10206).  Both standards, but
> only one named "Standard".  I apologize for my error.
>
No worries, by 1990 when ISO 10206 came about, Pascal had already morphed
even by Wirth himself.  I liked Modula-II  (and so called Mod-III  the DEC
SRC implementation).   One of my favorite early workstations was Wirth's
Lilith a Mod-22 based system that was an Alto clone like  the Perq (a.k.a
the PascAlto).

>
>
> That's also a flaw, but C doesn't distinguish itself strongly here;
> `static` function linkage should have been the default.

You can argue both ways.   Asmblers of the day worked like C did.



>
> But that was true of C for a long time as well; as I understand it,
>
Hmm look at the sources or at least at Dennis' Tour document.  Ken or Steve
Bourne can correct me he as I started  with Fifth Edition and pretty sure
Dennis' compiler was multipass.  Some passed were separate programs due to
the address space limits of the PDP-11.  But by 1978 and Typesetter C, much
less 80/81 when Brian and PJ did SW  Tools in Pascal, Brian's statement
hold.

>
> And for me, writing to minimize forward declarations _is_ the natural
> order.

Hey, I was taught that way also.  I knew FORTRAN, Algol-W, SAIL, BLISS, as
well as Pascal (much less a few assembler languages) before I learned C and
the PDP-11.  The White book did not exist, BTW. I started learning before
Lesk's IO library - although we got V6, I have few memories of anything
interesting by me being written without using Lesk's library or later libS.a
from Typesetter C.  I understand Brian's complaint, and coming from
Ratfor/FORTRAN, Pascal's rigor certainly would have been awkward, but I
liked having the flexibility that C provided. Frankly, I hate more modern C
code when the first thing you see is a lot of functions, and then main() is
declared much later. But then again, I like to keep main() and maybe one or
two primary functions in the program.c file and all my subroutines in
either subr.c or like, then in program.h declare everything.

>
>
> > 5. The order of logical expression evaluation cannot be controlled,
> > which leads to convoluted code and extraneous variables.
>
> Some of this blows back onto C.  Yes, short-circuit logical evaluation
> operators are desirable,

Absolutely.



> but apart from that the order of expression
> evaluation in C (a) is frequenly not specified so that compilers can
> generate fast code for the hardware; or (b) demands that the programmer
> remember something like 15 levels of operator precedence, which is
> savage cruelty in my opinion.
>
That's more about the implementation of a coding style. Post students of
Wulf's Green Book, the compiler should not care. It should generate optimal
code.  Anyway, I frankly prefer to see explicit parens, so the precedence
is clear — it's easier to read and less error-prone for the maintainer.


>
> Still, scanf() was a bad idea, or at least overapplied,

Remember printf() and scanf() come from FORTRAN in heritage. The idea was
that the format statements worked in both places. I'll not argue that
scanf() is a mess; I have generally avoided it.

> and should not
> be taught to students as a tool for interactive I/O handling (as it was
> to me--did anyone else have this misfortune?).

I seriously hope you were not given the C Programming Language as a
teaching language — shame on your instructors. We don't put new pilots in
an F15. Even in the military, they start on straightforward fixed-wing
aircraft similar to the Piper Cub or Cessna 150 [just as my father did when
he was a fighter instructor for the Army in the 1940s, BTW].

Use the tools for what they were designed for. I still think Pascal is the
best teaching language around, and Clancy and Cooper's book "Oh Pascal" is
the best way to introduce programmers to systems thinking. But give them
professional tools as they start to do harder things, and their skills will
improve.

It's funny as she has since graduated college and works for a local SW
firm, but a young woman I mentored a few years ago; I taught her using "Oh
Pascal" while her HS was trying to use C++ (and she was very confused by it
- the teacher was poor and the book wasn't great either — Dietel
and Dietel).  She later went to WPI, and she thanked me for "forcing her"
to learn to do the simple stuff and understand it.   She saw Java in
college courses, and things made much more sense to her.



> For that, a simple
> lexical analyzer is necessary because humans produce undisciplined
> input.  It's never too early to teach a beginner how to write a finite
> state machine.
>
I agree — everyone should write for their first compiler in Pascal for a
simple language and no cheating using YACC.  You need to write the whole
thing if you want to understand how parsing really works.

>
> I guess standardization of Pascal started too late; but both C

There was a standard. Everyone had the sources to Dennis and later Steve's
compilers.  😉



> and C++ took a long time to get to their initial standards too.  What do
> you
> think accounts for C and C++'s greater success, in the specific sense
> that vendor extensions didn't cripple the language's development?  What
> force kept these languages better governed?
>
In C's case, the committees were controlled as long as Dennis was
there. Two of Dennis's most famous quotes are:  *"When I read commentary
about suggestions for where C should go, I often think back and give thanks
that it wasn't developed under the advice of a worldwide crowd."*  and  *“C
is quirky, flawed, and an enormous success.”*

I find where the C standard folks falling into the C++ trap and letting
people pee it. CC++ is a  disaster — primarily because everyone added their
favorite feature.   That's while I like Go for applications work, and if I
were to do OS (near the HW development)  today and not use C, I would have
to consider Rust.

>
>
> I've read Lindsey's "A history of ALGOL 68" in HOPL 2 (1996).
> Intriguing stuff.  I have no strong opinions about any of it, probably
> because no one's either forced me to write in ALGOL 68, nor forbidden me
> from doing so.  I do admire its nearly universal loop structure:
>
I'll leave it to srb to reply to that. CMU  had a budding A68 team led by
Peter Hibbard, but I never used it. I had Peter for compilers, so we read a
number of the papers at the time, but after I graduated, work that led to
Ada had started.   I liked what I saw with Red; it follows 'Tartan,' which
Wulf and his students, like Hilfiger, put together. as a "Hail Mary" when
it started to be clear Green was going to "win."  When  I was a grad
student, and Paul had finished his PhD and started teaching at UCB,  I took
his comparative language seminar.   I learned to hate Ada  (*a.k.a.*
"Green")  a bit less.  But that's a different email thread with fewer Unix
orientations, so it belongs elsewhere.

>
>
> That was still a live issue when I was learning, but back then (on home
> 8-bit micros), you had to shell out money to get anything but the BASIC
> interpreter that was stored in ROM.
>
I understand. The more significant issue is that "production quality"
compilers did not target those systems (yet).   This came  up a while back
on Quora:
https://www.quora.com/When-did-C-compilers-start-generating-optimized-code-that-runs-faster-than-average-assembly-programmers-code/answer/Clem-Cole

I'd like to talk to some of that cohort about Ada.
>
Sure, move it, COFF.


>
> That shocks me, but okay  ...   What am I missing?
>
Simple: a different set of problems at the time.  Read my answer:
https://www.quora.com/How-did-we-make-the-first-computer-operating-system-if-we-didnt-have-computers-to-make-them-on/answer/Clem-Cole

>
>
>
> ...Thompson had a hand in writing that one, didn't he?  During his
> sabbatical that spawned the CSRG?  If so, that was 1975.
>
Pascal escapes  UCB with what we now call "1BSD," the original  BSD tape
that Joy wrote either 77 or 78.   It's written in a flavor  of
pre-typesetter C - which was a UCB modified V6 dmr compiler (and eyacc UCB'
extended Yacc IIRC)

>
> I have no expectation that it will displace C, but its developers have
> my admiration for pushing forward.  Maybe that's because, in maintaining
> a typesetting system that _isn't_ TeX, I recognize potentially kindred
> spirits.
>
I've used Free Pascal as a teaching tool for the last few years. They did a
nice job.

>
> Well, the professionals weren't wrong.  MS-DOS was a crap OS on a crap
> ISA.  They were both market placeholders.  But we don't work, or live,
> in a meritocracy.  As ever, the surest route to the head of the line is
> to be deposited there at birth by your ancestor.
>
Cole's Law:  "*Simple Economics always beats Sophisticated Design*"
The PCs were cheap, and >>eventually<< people got them to do the things
they needed. This is classic Christenson 'Disruptive Technology." The
"lessor" technology beat the "better"  one by creating a new market with
different set of customer and can build faster and over time the features
of the 'lessor' technology will catch up because its on a faster growth
curve.


> Oof, for RT-11.

OMSI Pascal ran on RT/RSX/RSTS and Unix. But they sold the most copies for
RT  and RSX.



> I've booted RSX-11--once--on my PiDP-11.  It was a jarring experience.

Yep.



> Booting 2.11BSD was headily nostalgic, and took me
> _way_ back.  I haven't seen a boot sequence like that in a long time.
>
Did you try V5, V6  or  V7?

>
>
> I can't completely agree with you here because as I understand the
> critique, C still has _some_ of them _today_.  Often not as badly as in
> the past, and almost certainly not as bad as the Pascals of the day.
>
See Dennis' quotes from above.

>
> I had thought that device-independent troff directly drove some changes
> to the C language (not just support libraries), but maybe I'm wrong.

It likely did. Steve may be able to add color here.



>  I  have no idea how the Ritchie compiler or PCC evolved after Seventh
> Edition (1979).

PCC took the mantel, and eventually, PCC2 took that -- look in SVR4 sources
for the latter.



> The main thing I know about it is that if an
> implementation targeted x86, it added `near` and `far` keywords to
> accommodate segmented memory and/or DOS-style object file formats.

I think Lattice C did that first, and it was picked up by the DOS crew.
Most of us thought it was an abomination, but we had switched to 32-bits by
then and Vaxen and 68000s.



> Well, you _could_ bypass it and use read() and write() directly.  Say,
> in cat(1), the way Pike intended.  ;-)
>
And people did since that was the >>UNIX<< IO system, but it was not the
Honeywell or MVS system (or ITS for the Synder PDP-10 compiler). As I said,
please remember that systems programming languages were like assemblers;
the local OS supplied the I/O library.

Lesk codified a scheme that could be made to work on multiple target OSes.
Dennis rethought and reimplemented a similar idea with fewer issues: libS.a.
With the White Book, libS.a was formalized, and only then did C have an IO
library. In fact, when Lattice did their first DOS compiler, they provided
an IO scheme for DOS and only sort of kinda did Standard I/O.

Best wishes.
Clem

[-- Attachment #2: Type: text/html, Size: 24258 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Larry McVoy]

> Anyway, I frankly prefer to see explicit parens, so the precedence
> is clear ??? it's easier to read and less error-prone for the maintainer.

This, a thousand times, this.  I taught my guys "think of coding as write
once, read many.  I could care less how much more work it is, write code
such that it is the easiest to understand".

[TUHS] Re: What would early alternatives to C have been?

[Steve Nickolas]

On Sun, 9 Mar 2025, Larry McVoy wrote:

>> Anyway, I frankly prefer to see explicit parens, so the precedence
>> is clear ??? it's easier to read and less error-prone for the maintainer.
>
> This, a thousand times, this.  I taught my guys "think of coding as write
> once, read many.  I could care less how much more work it is, write code
> such that it is the easiest to understand".
>

I assume compiler braindeath and always code around it.  An extra pair of 
parentheses never hurt.

-uso.

[TUHS] Re: What would early alternatives to C have been?

[Lawrence Stewart]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

The C operator precedence table has 15 precedence levels, from “++" down to “,"
(see https://en.cppreference.com/w/c/language/operator_precedence)

This is nuts.  I don’t remember them and I wouldn’t trust an engineer who claimed to.

Around 2005, when I was doing some chip verification, I found a hard to notice operator precedence bug (in VHDL, but it is the same issue) that would have cost us a half-million dollar mask spin.

If there is more than one operator, I use parens (I do write a[x] + b[x], that one I know.)

Our K-12 system isn’t doing us any favors when they think PEMDAS is “mathematics”.

-L

PS I’ve been a little angry about this since my 6th grader got marked down for using “extra” parentheses in class.
https://larry.stewart.org/2010/12/05/order-of-operations-evil-and-pernicious/


> On Mar 9, 2025, at 19:12, Larry McVoy <lm@mcvoy.com> wrote:
> 
>> Anyway, I frankly prefer to see explicit parens, so the precedence
>> is clear ??? it's easier to read and less error-prone for the maintainer.
> 
> This, a thousand times, this.  I taught my guys "think of coding as write
> once, read many.  I could care less how much more work it is, write code
> such that it is the easiest to understand".


[-- Attachment #2.1: Type: text/html, Size: 4703 bytes --]

[-- Attachment #2.2: favicon.ico --]
[-- Type: image/vnd.microsoft.icon, Size: 4119 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Stuff Received]

On 2025-03-09 19:39, Lawrence Stewart wrote:
> The C operator precedence table has 15 precedence levels, from “++" down 
> to “,"
> (see https://en.cppreference.com/w/c/language/operator_precedence 
> <https://en.cppreference.com/w/c/language/operator_precedence>)
> 
> This is nuts.  I don’t remember them and I wouldn’t trust an engineer 
> who claimed to.
> 
> Around 2005, when I was doing some chip verification, I found a hard to 
> notice operator precedence bug (in VHDL, but it is the same issue) that 
> would have cost us a half-million dollar mask spin.
> 
> If there is more than one operator, I use parens (I do write a[x] + 
> b[x], that one I know.)
> 
> Our K-12 system isn’t doing us any favors when they think PEMDAS is 
> “mathematics”.
> 
> -L
> 
> PS I’ve been a little angry about this since my 6th grader got marked 
> down for using “extra” parentheses in class.

Parentheses around expressions were required in our coding style.

S.

[TUHS] Re: What would early alternatives to C have been?

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

I have a shell script that helps:

% cat bin/ops

#!/usr/local/plan9/bin/rc

cat <<!

1 () [] -> . left

2 ! ~ ++ -- - (type) * & sizeof right

3 * / % left

4 + - left

5 >> << left

6 < <= > >= left

7 == != left

8 & left

9 ^ left

10 | left

11 && left

12 || left

13 ?: right

14 = op= right

15 , left

!

%


I used to use it regularly. Later I did the obvious followup:


% cat bin/goops

#!/bin/sh

cat <<!

6             *  /  %  <<  >>  &  &^

5             +  -  |  ^

4             ==  !=  <  <=  >  >=

3             <-

2             &&

1             ||

!

%


The difference besides the obvious is that it turned out I never need
goops. (Also gofmt uses spaces cleverly to show grouping.)


-rob

[-- Attachment #2: Type: text/html, Size: 20595 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Bakul Shah via TUHS]

Criticisms of C should not be viewed as "casting aspersions". We
can't change the past but we can certainly assess the effect of
past decisions. [Not sure that would change anything though, but
we are just chitchatting!]

IMHO with C what we have is a tragedy of scale. A pleasant to use
language that worked/works well for a small group of highly competent
people with skills beyond programming doesn't work so well for
much larger groups of people with varying level of competency & skill.

Just as the informality and few implicit rules of a village doesn't
scale to large cities.

I believe Apollo's Domain/OS was implemented in Pascal. Tunis
that Greg Woods alluded to was implemented in Concurrent Euclid.
KeyKOS (a capability based system) was implemented in PL/I. Per
Brinch Hansen implemented a couple of OSes in Concurrent Pascal.
And so on. I think the original Mac OS was in Pascal?

Of course, most of these efforts came later or were on much larger
systems.

The beauty of Unix is in its relatively few but well defined
components & their composability. I wouldn't know if the design
of C had something to do with that or if it was just the pure
genius of Thompson, Ritchie and their cohorts at Bell Labs.

> On Mar 8, 2025, at 7:46 PM, Dan Cross <crossd@gmail.com> wrote:
> 
> As I mentioned in the discussion about C, it's easy to look back with
> a modern perspective and cast aspersions on C. But this got me
> thinking, what would possible alternatives have been? In the context
> of the very late 1960s heading into the early 70s, and given the
> constraints of the PDP-7 and early PDP-11s, what languages would one
> consider for implementing a system like early Unix? Dennis's history
> paper mentioned a very short-lived effort at Fortran, and I asked
> about that a few years ago, but no one really remembered much about
> it; I gather this was an experiment that lasted a few days or weeks
> and was quickly abandoned. But what else?
> 
> My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was
> already mentioned. I don't think PL/1 (or PL/I) could have fit on
> those machines. Pascal was really targeted towards teaching and would
> have required pretty extensive work to be usable. The big question
> mark in my mind is Algol/W; how well known was it at the time? Was any
> consideration for it made?
> 
> Obviously, the decision to go with BCPL (as the basis for B, which
> beget C) was made and the rest is history. But I'm really curious
> about how, in the research culture at the time, information about new
> programming languages made its way through the community.
> 
>        - Dan C.

[TUHS] Re: What would early alternatives to C have been?

[John Levine]

It appears that Luther Johnson <luther.johnson@makerlisp.com> said:
>I believe CP/M was written entirely in 8080 assembly language. PL/M was
>a PL/1 subset, I think Gary Kildall was the main programmer behind that,
>and I'm sure there was a version for CP/M, but I doubt CP/M was written
>in it, ...

See this Wikipedia article on PL/M, which summarizes the history that
Kildall wrote up in a 1993 manuscript now online at the CHM. If he
says he wrote it in PL/M I am inclined to believe him.

https://en.wikipedia.org/wiki/PL/M#CITEREFKildall1993

R's,
John

[TUHS] Re: What would early alternatives to C have been?

[Luther Johnson]

Got it. My misunderstanding, acknowledged.

On 03/09/2025 06:51 PM, John Levine wrote:
> It appears that Luther Johnson <luther.johnson@makerlisp.com> said:
>> I believe CP/M was written entirely in 8080 assembly language. PL/M was
>> a PL/1 subset, I think Gary Kildall was the main programmer behind that,
>> and I'm sure there was a version for CP/M, but I doubt CP/M was written
>> in it, ...
> See this Wikipedia article on PL/M, which summarizes the history that
> Kildall wrote up in a 1993 manuscript now online at the CHM. If he
> says he wrote it in PL/M I am inclined to believe him.
>
> https://en.wikipedia.org/wiki/PL/M#CITEREFKildall1993
>
> R's,
> John
>

[TUHS] Re: What would early alternatives to C have been?

[Larry McVoy]

On Sun, Mar 09, 2025 at 08:55:20PM -0400, Stuff Received wrote:
> On 2025-03-09 19:39, Lawrence Stewart wrote:
> >The C operator precedence table has 15 precedence levels, from ???++" down
> >to ???,"
> >(see https://en.cppreference.com/w/c/language/operator_precedence
> ><https://en.cppreference.com/w/c/language/operator_precedence>)
> >
> >This is nuts. ??I don???t remember them and I wouldn???t trust an engineer
> >who claimed to.
> >
> >Around 2005, when I was doing some chip verification, I found a hard to
> >notice operator precedence bug (in VHDL, but it is the same issue) that
> >would have cost us a half-million dollar mask spin.
> >
> >If there is more than one operator, I use parens (I do write a[x] + b[x],
> >that one I know.)
> >
> >Our K-12 system isn???t doing us any favors when they think PEMDAS is
> >???mathematics???.
> >
> >-L
> >
> >PS I???ve been a little angry about this since my 6th grader got marked
> >down for using ???extra??? parentheses in class.
> 
> Parentheses around expressions were required in our coding style.

Good for you, we were the same.  It's not that hard to make the code
easier to read.

--lm

[TUHS] Re: What would early alternatives to C have been?

[arnold]

Larry McVoy <lm@mcvoy.com> wrote:

> > Parentheses around expressions were required in our coding style.
>
> Good for you, we were the same.  It's not that hard to make the code
> easier to read.

I think, as in all things, "always use parentheses" can be carried
too far.  I find

	if (a == b && c == d)

perfectly reasonable, but

	if ((a == b) && (c == d))

to be just silly.  That said, when mixing && and ||, I do
parenthesize:

	if ((a == b && c == d) || (p == q && x == y))

If there are lots of OR conditions, I break lines:

	if (   (a == b && c == d)
	    || (e == f && g == h)
	    || (i == j && k == l)
	    || (p == q && x == y))

I will also use parentheses with the bitwise operators.

As in many things related to style, taste and judgement are needed, not
just slavish adherence to instructions without any understanding of them.
My two cents.

Arnold

(P.S. Don't get me started on `if (NULL == pointer)' and `if (42 != foo)'.
Grrrr...)

[TUHS] Re: What would early alternatives to C have been?

[Larry McVoy]

On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote:
> I think, as in all things, "always use parentheses" can be carried
> too far.  I find
> 
> 	if (a == b && c == d)
> 
> perfectly reasonable, but
> 
> 	if ((a == b) && (c == d))
> 
> to be just silly.  

Color me silly then.  My eyes parse the "silly" form faster.  And I was the
boss so my eyes won.  Over time, everyone at my shop came to agree with me.
One mans silly is another mans faster reading.

If you worked for me, you did the silly form.  And everyone came around to
liking it.  It's just faster to read.

[TUHS] Re: What would early alternatives to C have been?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Mon, Mar 10, 2025 at 10:41 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote:
> > I think, as in all things, "always use parentheses" can be carried
> > too far.  I find
> >
> >       if (a == b && c == d)
> >
> > perfectly reasonable, but
> >
> >       if ((a == b) && (c == d))
> >
> > to be just silly.
>
> Color me silly then.

Me too.

> My eyes parse the "silly" form faster.

Exactly.

> And I was the boss so my eyes won.  Over time, everyone at my shop came
> to agree with me.
> One mans silly is another mans faster reading.
>
The problem is that in the first form, you have to slow down to ensure you
have the order correctly,  Maybe it's my dyslexia speaking, but the "extra"
parens make it clear without having to slow down.
ᐧ

[-- Attachment #2: Type: text/html, Size: 2488 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Dan Cross]

On Mon, Mar 10, 2025 at 10:41 AM Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote:
> > I think, as in all things, "always use parentheses" can be carried
> > too far.  I find
> >
> >       if (a == b && c == d)
> >
> > perfectly reasonable, but
> >
> >       if ((a == b) && (c == d))
> >
> > to be just silly.
>
> Color me silly then.  My eyes parse the "silly" form faster.  And I was the
> boss so my eyes won.  Over time, everyone at my shop came to agree with me.
> One mans silly is another mans faster reading.
>
> If you worked for me, you did the silly form.  And everyone came around to
> liking it.  It's just faster to read.

I'm with Arnold on this one in terms of preference, but I think
there's a meta point that's interesting to consider: style
localizations facilitate understanding and knowledge transfer across
large code bases. Google has a codebase measured in the BLOC (B as in
billion), and very strict style guides; they're really more hard and
fast rules as opposed to a soft thing that the term "guide" tends to
imply.

Personally, I hated Google's style formats; but after a month or two
they largely disappeared for me and I stopped thinking about them. I
still thought and continue to think they're ugly, but the network
effects of being able to `cd` anywhere in that massive monorepo and be
able to read a file without the cognitive overhead of internalizing
that this programmer preferred to put the braces somewhere else
relative to the last programmer was a huge win, far outweighing my
aesthetic objections. This directly contributed to allowing the
organization to scale to tens of thousands of programmers working in
the same code base simultaneously. Supported by tools like automatic
formatters, folks concentrated on the problem at hand and not the
minutiae of formatting. Uniform style also facilitated things like
large-scale, automated refactorings; another huge win in evolving code
to newer standards, fixing old problems, and so forth. So even though
I didn't like the specifics of the local standard, I respected what it
did for us.

So I don't think the specifics of whether you put parentheses around
every boolean expression matter as much as whether you aggressively
commit to consistency everywhere and support that with tooling and
automation.

        - Dan C.

[TUHS] Re: What would early alternatives to C have been?

[Larry McVoy]

On Mon, Mar 10, 2025 at 10:52:20AM -0400, Clem Cole wrote:
> On Mon, Mar 10, 2025 at 10:41???AM Larry McVoy <lm@mcvoy.com> wrote:
> 
> > On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote:
> > > I think, as in all things, "always use parentheses" can be carried
> > > too far.  I find
> > >
> > >       if (a == b && c == d)
> > >
> > > perfectly reasonable, but
> > >
> > >       if ((a == b) && (c == d))
> > >
> > > to be just silly.
> >
> > Color me silly then.
> 
> Me too.
> 
> > My eyes parse the "silly" form faster.
> 
> Exactly.
> 
> > And I was the boss so my eyes won.  Over time, everyone at my shop came
> > to agree with me.
> > One mans silly is another mans faster reading.
> >
> The problem is that in the first form, you have to slow down to ensure you
> have the order correctly,  Maybe it's my dyslexia speaking, but the "extra"
> parens make it clear without having to slow down.

Exactly.  It's not that Clem and I are stupid, we aren't.  It's that we
want to use our brains to work on stuff that is actually hard.  Making 
us spend effort on "silly" stuff is just rude, just don't do that.  You
are entitled to your opinion for sure, but you are less entitled when
that opinion creates pointless work for other people.

[TUHS] Re: What would early alternatives to C have been?

[Larry McVoy]

On Mon, Mar 10, 2025 at 10:57:39AM -0400, Dan Cross wrote:
> So I don't think the specifics of whether you put parentheses around
> every boolean expression matter as much as whether you aggressively
> commit to consistency everywhere and support that with tooling and
> automation.

Amen.  I've contributed to GNU C code, and while I _HATE_ their coding
style, my contributions were in that style.  It's their house, their
rules, and Dan is spot on as to why that is important.

[TUHS] Re: What would early alternatives to C have been?

[Dan Cross]

On Mon, Mar 10, 2025 at 11:12 AM Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Mar 10, 2025 at 10:52:20AM -0400, Clem Cole wrote:
> > On Mon, Mar 10, 2025 at 10:41???AM Larry McVoy <lm@mcvoy.com> wrote:
> > > On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote:
> > > > I think, as in all things, "always use parentheses" can be carried
> > > > too far.  I find
> > > >
> > > >       if (a == b && c == d)
> > > >
> > > > perfectly reasonable, but
> > > >
> > > >       if ((a == b) && (c == d))
> > > >
> > > > to be just silly.
> > >
> > > Color me silly then.
> >
> > Me too.
> >
> > > My eyes parse the "silly" form faster.
> >
> > Exactly.
> >
> > > And I was the boss so my eyes won.  Over time, everyone at my shop came
> > > to agree with me.
> > > One mans silly is another mans faster reading.
> > >
> > The problem is that in the first form, you have to slow down to ensure you
> > have the order correctly,  Maybe it's my dyslexia speaking, but the "extra"
> > parens make it clear without having to slow down.
>
> Exactly.  It's not that Clem and I are stupid, we aren't.

Oh goodness; I hope we can all agree that no one was suggesting that!

> [snip] creates pointless work for other people.

Along these lines, I can't stand when people write, `if (!strcmp(a,
b)) { /* strings are equal */ }`

While true, I find the negation particularly annoying in this context,
and prefer either `if (strcmp(a, b) == 0) { ... }` or writing a small
`streq()` function that returns boolean true/false.

        - Dan C.

[TUHS] Re: What would early alternatives to C have been?

[Larry McVoy]

On Mon, Mar 10, 2025 at 11:27:46AM -0400, Dan Cross wrote:
> > [snip] creates pointless work for other people.
> 
> Along these lines, I can't stand when people write, `if (!strcmp(a,
> b)) { /* strings are equal */ }`
> 
> While true, I find the negation particularly annoying in this context,
> and prefer either `if (strcmp(a, b) == 0) { ... }` or writing a small
> `streq()` function that returns boolean true/false.

From bitkeeper's style.h:

#define streq(a,b)      (!strcmp((a),(b)))

and

#define unless(e)       if (!(e))

Maybe I should post the whole file :-)

[TUHS] Re: What would early alternatives to C have been?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]

On Mon, Mar 10, 2025 at 9:28 AM Dan Cross <crossd@gmail.com> wrote:

> On Mon, Mar 10, 2025 at 11:12 AM Larry McVoy <lm@mcvoy.com> wrote:
> > On Mon, Mar 10, 2025 at 10:52:20AM -0400, Clem Cole wrote:
> > > On Mon, Mar 10, 2025 at 10:41???AM Larry McVoy <lm@mcvoy.com> wrote:
> > > > On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote:
> > > > > I think, as in all things, "always use parentheses" can be carried
> > > > > too far.  I find
> > > > >
> > > > >       if (a == b && c == d)
> > > > >
> > > > > perfectly reasonable, but
> > > > >
> > > > >       if ((a == b) && (c == d))
> > > > >
> > > > > to be just silly.
> > > >
> > > > Color me silly then.
> > >
> > > Me too.
> > >
> > > > My eyes parse the "silly" form faster.
> > >
> > > Exactly.
> > >
> > > > And I was the boss so my eyes won.  Over time, everyone at my shop
> came
> > > > to agree with me.
> > > > One mans silly is another mans faster reading.
> > > >
> > > The problem is that in the first form, you have to slow down to ensure
> you
> > > have the order correctly,  Maybe it's my dyslexia speaking, but the
> "extra"
> > > parens make it clear without having to slow down.
> >
> > Exactly.  It's not that Clem and I are stupid, we aren't.
>
> Oh goodness; I hope we can all agree that no one was suggesting that!
>

Yea. That's the problem with style debates: It's all about taste,
preference and workflow. Those items differ wildly, are core to one's
identity (to a degree not usually appreciated) and so it turns personal w/o
people intending it to do so. I saw a presentation years ago that went over
all the human factors and showed that there's too many 80/20 60/40 divides
in how people's brains work to have a universal style that would be
friction free for everybody. I searched for it just now, but couldn't find
it.

I'm team  "If you want that many parens, use LISP" not team "Explicit
parens make it clearer" myself, but as you see, my internal framing isn't
exactly respectul while trying to be funny...  Another hazard of style
debates.


> > [snip] creates pointless work for other people.
>
> Along these lines, I can't stand when people write, `if (!strcmp(a,
> b)) { /* strings are equal */ }`
>
> While true, I find the negation particularly annoying in this context,
> and prefer either `if (strcmp(a, b) == 0) { ... }` or writing a small
> `streq()` function that returns boolean true/false.
>

There's a number of things in C that we'd do differently in other
languages...  FreeBSD encourages the latter style over the former and is an
odd choice of concise and verbose when it comes to notation (sometimes
delete the extra parens, sometimes have extra == 0 or != 0).

Warner

[-- Attachment #2: Type: text/html, Size: 3950 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[arnold]

Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Mar 10, 2025 at 10:57:39AM -0400, Dan Cross wrote:
> > So I don't think the specifics of whether you put parentheses around
> > every boolean expression matter as much as whether you aggressively
> > commit to consistency everywhere and support that with tooling and
> > automation.
>
> Amen.  I've contributed to GNU C code, and while I _HATE_ their coding
> style, my contributions were in that style.  It's their house, their
> rules, and Dan is spot on as to why that is important.

I agree 110% with Dan as well. And with Larry about GNU code.

Long ago I worked in a startup, and early on the developers got
together and wrote up a coding style to use.  A year later a new
guy came on board, who refused to follow it.  It was then
easy to see when what's-his-name had touched a part of the code. (I forgot
what his name was.)  Quite annoying.

Arnold

[TUHS] Re: What would early alternatives to C have been?

[segaloco via TUHS]

Sent with Proton Mail secure email.

On Monday, March 10th, 2025 at 9:30 AM, arnold@skeeve.com <arnold@skeeve.com> wrote:

> Larry McVoy lm@mcvoy.com wrote:
> 
> > On Mon, Mar 10, 2025 at 10:57:39AM -0400, Dan Cross wrote:
> > 
> > > So I don't think the specifics of whether you put parentheses around
> > > every boolean expression matter as much as whether you aggressively
> > > commit to consistency everywhere and support that with tooling and
> > > automation.
> > 
> > Amen. I've contributed to GNU C code, and while I HATE their coding
> > style, my contributions were in that style. It's their house, their
> > rules, and Dan is spot on as to why that is important.
> 
> 
> I agree 110% with Dan as well. And with Larry about GNU code.
> 
> Long ago I worked in a startup, and early on the developers got
> together and wrote up a coding style to use. A year later a new
> guy came on board, who refused to follow it. It was then
> easy to see when what's-his-name had touched a part of the code. (I forgot
> what his name was.) Quite annoying.
> 
> Arnold

I'm quite enjoying following along in this thread as my current work team is in
a growth pattern.  For the first year of the project it was mainly just myself
and my manager slinging code.  We had been bumped over from the same project so
already had a pretty good synergy.  Then we brought in a few new folks and
managed to settle into a good groove, we weren't using automated style
enforcement but didn't tend to step on each others toes.

This year the team has expanded both a few times over in numbers as well as in
geographic footprint and the divergences in approach are finally becoming 
"a thing" that needs to be addressed intentionally rather than organically.
It's proving quite a pain, I used to be a stickler for style and have in the
past several years tried to relax that attitude...which now with the growing
need to pay attention to that again, it's a bit jarring to now see the pendulum
swing in the opposite direction.

I generally like deferring to folks tasked with a problem to come up with all
the minutiae surrounding their solution, but with the size our team is growing
to, I'm coming to recognize where having those structural guardrails saves
everyone headaches in the long run.

Generally I'm a more parens is fine if it makes meaning clear kind of person,
annoyingly though with some assembler projects.  Since parentheses are more
context-sensitive in different assembler languages, I've found plenty of
situations where I use parentheses in a macro or equate definition only to
find later when they're used with some operation, they trigger an addressing
mode that I didn't intend.

- Matt G.

[TUHS] Re: What would early alternatives to C have been?

[Stuff Received]

On 2025-03-10 12:30, arnold@skeeve.com wrote:
> Larry McVoy <lm@mcvoy.com> wrote:
> 
>> On Mon, Mar 10, 2025 at 10:57:39AM -0400, Dan Cross wrote:
>>> So I don't think the specifics of whether you put parentheses around
>>> every boolean expression matter as much as whether you aggressively
>>> commit to consistency everywhere and support that with tooling and
>>> automation.
>>
>> Amen.  I've contributed to GNU C code, and while I _HATE_ their coding
>> style, my contributions were in that style.  It's their house, their
>> rules, and Dan is spot on as to why that is important.
> 
> I agree 110% with Dan as well. And with Larry about GNU code.
> 
> Long ago I worked in a startup, and early on the developers got
> together and wrote up a coding style to use.  A year later a new
> guy came on board, who refused to follow it.  It was then
> easy to see when what's-his-name had touched a part of the code. (I forgot
> what his name was.)  Quite annoying.
> 
> Arnold

We foresaw that and ensured that different code could be reformatted 
with indent.

S.

[TUHS] Re: What would early alternatives to C have been?

[Bakul Shah via TUHS]

On Mar 10, 2025, at 9:30 AM, arnold@skeeve.com wrote:
> 
> Long ago I worked in a startup, and early on the developers got
> together and wrote up a coding style to use.  A year later a new
> guy came on board, who refused to follow it.  It was then
> easy to see when what's-his-name had touched a part of the code. (I forgot
> what his name was.)  Quite annoying.

Most every company where I worked did this (agreed upon a coding style).
One of my best engineers, who usually said very little, preferred a very
different style but he set up scripts so that in the editor he saw *his*
favorite style and before checking in a file he ran indent to conform to
the agreed upon style.

[TUHS] Re: What would early alternatives to C have been?

[Greg A. Woods]

[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]

At Sun, 9 Mar 2025 18:58:14 -0400, Clem Cole <clemc@ccc.com> wrote:
Subject: [TUHS] Re: What would early alternatives to C have been?
>
> I find where the C standard folks falling into the C++ trap and letting
> people pee it. CC++ is a  disaster ― primarily because everyone added their
> favorite feature.   That's while I like Go for applications work, and if I
> were to do OS (near the HW development)  today and not use C, I would have
> to consider Rust.

Perhaps Rust gets/deserves its name from the corrosion caused by
everyone peeing into it too.  For me it's way too much of a kitchen sink
of what seem to me to be half-baked ideas.

W.r.t. Unix history, and any alternatives to C, well I did mention TUNIS
a bit ago, and the fact it was implemented in Concurrent Euclid.  That's
quite a bit later than the first C though.

I would guess though that even its parent, Euclid, which came along a
little earlier, would still have been too late to have been useful for
early Unix.  It's mostly just another Algol derivative anyway.  It did
have some big funding from the military in the early days, but look
where that got it.

I think one of the most loved innovations C (and B just before it)
brought to programming languages was the use of braces instead of
begin/end, along with the elimination of some of the other extra
unnecessary keywords like "then".  These syntactical changes made
programming a lot more fun for many of us.  I for one dreaded having to
use Pascal, or heaven forbid PL/1, after I got used to C just because of
the wordy syntax alone (I was still too inexperienced at the time to
appreciate BWK's criticisms of Pascal).  I had the "fun" experience of
learning BASIC and a bit of Pascal in high school, then being thrown
into Pascal, C, PL/1, and lisp, all as learning languages, in first
year (the first two on Unix, the second two on Multics).

Which reminds me, wasn't there was some mention of difficulties with
Pascal et al w.r.t. separate compilation earlier in this thread....
Wasn't that one of the features of Berkeley Pascal?  I know separate
compilation is a definitely a feature by the time it makes it to
SunOS/Solaris-2.  I remember trying to figure it out once for a class
assignment and the TA scowled at me and asked me why on earth I would
ever want to do that, so I never trusted that TA on programming
languages, or much of anything else, ever again.

Proper and elegant and simple modules for a systems programming language
would seem a pre-requisite these days though.  Preprocessors and headers
be gone!

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[segaloco via TUHS]

On Monday, March 10th, 2025 at 4:25 PM, Greg A. Woods <woods@robohack.ca> wrote:

>
> ...
> 
> Which reminds me, wasn't there was some mention of difficulties with
> Pascal et al w.r.t. separate compilation earlier in this thread....
> Wasn't that one of the features of Berkeley Pascal? I know separate
> compilation is a definitely a feature by the time it makes it to
> SunOS/Solaris-2. I remember trying to figure it out once for a class
> assignment and the TA scowled at me and asked me why on earth I would
> ever want to do that, so I never trusted that TA on programming
> languages, or much of anything else, ever again.
> 
> ...
> 
> --
> Greg A. Woods gwoods@acm.org
> 
> 
> Kelowna, BC +1 250 762-7675 RoboHack woods@robohack.ca
> 
> Planix, Inc. woods@planix.com Avoncote Farms woods@avoncote.ca

If by separate compilation you mean the compiler spits out (possibly optionally)
human-readable assembler, I would assume that is nearly crucial for any systems
language, otherwise you're putting a lot of faith in an ABI when it comes to
linking with your machdep assembly files no?  I'd be nervous to use something
for bare metal programming that I couldn't easily inspect the resulting
assembler code from...

- Matt G.

[TUHS] Re: What would early alternatives to C have been?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Mon, Mar 10, 2025 at 7:25 PM Greg A. Woods <woods@robohack.ca> wrote:

>
>
> Which reminds me, wasn't there was some mention of difficulties with
> Pascal et al w.r.t. separate compilation earlier in this thread....
> Wasn't that one of the features of Berkeley Pascal?

Yes - had extensions for that so: compiling to *.o and using external
libraries was possible.
man pc will describe the -c switch   pc was the hooks into the pcc  system
for the vax, but I'm not sure if it was backported the PDP-11.   It was
moved to the 68k by a couple different teams, including Sun for SunOS.
Maybe Larry or Rob G can answer if they ever moved it to SPARC.   By that
time, they had there own compiler suite and may have started to abandon
anything based on pcc.

ᐧ

[-- Attachment #2: Type: text/html, Size: 1741 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Dan Cross]

On Mon, Mar 10, 2025 at 8:12 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
> On Monday, March 10th, 2025 at 4:25 PM, Greg A. Woods <woods@robohack.ca> wrote:
> > ...
> >
> > Which reminds me, wasn't there was some mention of difficulties with
> > Pascal et al w.r.t. separate compilation earlier in this thread....
> > Wasn't that one of the features of Berkeley Pascal? I know separate
> > compilation is a definitely a feature by the time it makes it to
> > SunOS/Solaris-2. I remember trying to figure it out once for a class
> > assignment and the TA scowled at me and asked me why on earth I would
> > ever want to do that, so I never trusted that TA on programming
> > languages, or much of anything else, ever again.
>
> If by separate compilation you mean the compiler spits out (possibly optionally)
> human-readable assembler, I would assume that is nearly crucial for any systems
> language, otherwise you're putting a lot of faith in an ABI when it comes to
> linking with your machdep assembly files no?  I'd be nervous to use something
> for bare metal programming that I couldn't easily inspect the resulting
> assembler code from...

No, typically that means that you've got two or more source files, say
a.pas and b.pas; you separately compile those into object files, such
as a.o and b.o, and then link them into a file executable binary.
Early Pascal systems were not generally modular in that way, while C
was. Yes, you are putting some faith into the linker and ABI, but on
early Unix, they came from the same folks who wrote the compiler.

Generating assembly listings (or disassembling object files/a,out) is
a separate matter.

        - Dan C.

[TUHS] Re: What would early alternatives to C have been?

[John Levine]

It appears that Greg A. Woods <tuhs@tuhs.org> said:
>I think one of the most loved innovations C (and B just before it)
>brought to programming languages was the use of braces instead of
>begin/end, along with the elimination of some of the other extra
>unnecessary keywords like "then". ...

I suspect that's because they came along just late enough that
everything used ASCII, and they got those cool Model 37 Teletypes, so
they could assume that devices could generate and print punctuation
like { } [ ] | < >

The C standards used to have (still have?) trigraph equivalents for much
of the punctuation for people on systems that don't have the characters.

R's,
John

[TUHS] Re: What would early alternatives to C have been?

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

At 2025-03-10T22:18:43-0400, John Levine wrote:
> I suspect that's because they came along just late enough that
> everything used ASCII, and they got those cool Model 37 Teletypes, so
> they could assume that devices could generate and print punctuation
> like { } [ ] | < >

"begin" and "end" were fine.

I've heard a story that Pascal was unpopular in the Middle East;
every programming student wanted to know why they had to pay homage to
Israeli Prime Minister Menachem Begin in every program, which tells you
how old this story is.

> The C standards used to have (still have?) trigraph equivalents for
> much of the punctuation for people on systems that don't have the
> characters.

My understanding of the feedback procedure for ISO C23 finalization is
that some NBs (national bodies) fought pretty hard to keep trigraphs.

I _think_ they're gone from the final version of the standard, but I
don't have an official version, just a "final" draft, and my impression
of the WG14 meeting minutes from last year was that this particular
issue was fought to the bitter end.

So maybe they snuck back in at the 11th hour.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[George Michaelson]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

Is nobody going to tell stories about the #define of Bourne Shell fame?

-G

On Tue, Mar 11, 2025 at 2:00 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> At 2025-03-10T22:18:43-0400, John Levine wrote:
> > I suspect that's because they came along just late enough that
> > everything used ASCII, and they got those cool Model 37 Teletypes, so
> > they could assume that devices could generate and print punctuation
> > like { } [ ] | < >
>
> "begin" and "end" were fine.
>
> I've heard a story that Pascal was unpopular in the Middle East;
> every programming student wanted to know why they had to pay homage to
> Israeli Prime Minister Menachem Begin in every program, which tells you
> how old this story is.
>
> > The C standards used to have (still have?) trigraph equivalents for
> > much of the punctuation for people on systems that don't have the
> > characters.
>
> My understanding of the feedback procedure for ISO C23 finalization is
> that some NBs (national bodies) fought pretty hard to keep trigraphs.
>
> I _think_ they're gone from the final version of the standard, but I
> don't have an official version, just a "final" draft, and my impression
> of the WG14 meeting minutes from last year was that this particular
> issue was fought to the bitter end.
>
> So maybe they snuck back in at the 11th hour.
>
> Regards,
> Branden
>

[-- Attachment #2: Type: text/html, Size: 1870 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Ron Natalie]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

Gosh, I had the misfortune of working on the shell (and I think ADB) 
when they had those darned marcros.    I was so happy when 5R2 came 
around and I found someone had undone them all and turned it back into 
normal C.



------ Original Message ------
From "George Michaelson" <ggm@algebras.org>
To tuhs@tuhs.org
Date 3/11/2025 12:14:56 AM
Subject [TUHS] Re: What would early alternatives to C have been?

>Is nobody going to tell stories about the #define of Bourne Shell fame?
>
>-G

[-- Attachment #2: Type: text/html, Size: 1976 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Rob Pike]

The rapscallion who removed the macros, at least for the version I
worked on for the v8 shell (sadly missed) was called Steve Bourne.

-rob

On Wed, Mar 12, 2025 at 2:19 AM Ron Natalie <ron@ronnatalie.com> wrote:
>
> Gosh, I had the misfortune of working on the shell (and I think ADB) when they had those darned marcros.    I was so happy when 5R2 came around and I found someone had undone them all and turned it back into normal C.
>
>
>
> ------ Original Message ------
> From "George Michaelson" <ggm@algebras.org>
> To tuhs@tuhs.org
> Date 3/11/2025 12:14:56 AM
> Subject [TUHS] Re: What would early alternatives to C have been?
>
> Is nobody going to tell stories about the #define of Bourne Shell fame?
>
> -G

[TUHS] Re: What would early alternatives to C have been?

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

Very probably. But under pressure I went with what I knew I could get
right.  In hindsight it was like one of those non-quantitative
multiple-choice tests where you have to figure out not the correct answer
but the answer that the test author is most likely to believe to be correct.

On Mon, Mar 10, 2025, 4:49 PM Bakul Shah <bakul@iitbombay.org> wrote:

> Perhaps the interviewer was looking for something dumb like the following
> and not a full RD parser?
>
> int count = 0;
> while (*cp) {
>         char c = *cp++;
>         count += c == '(' ? 1 : c == ')' ? -1 : 0;
>         if (count < 0) return -1; // FAIL: one too many )
> }
> if (count > 0) return -1; // FAIL: too many (
> return 0; // SUCCESS
>
> Though this will fall apart if you also want to also balance braces &/or
> brackets and must catch invalid cases like "(..[..)..]"!
>
> > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote:
> >
> > I was working at the whiteboard during a job interview once. I had been
> asked to write a function to report if its input had balanced parentheses.
> No problem: I wrote an RD parser in Python (which I prefer for
> whiteboarding) to detect balance and return True if the parse was
> successful and False if EOF was reached.
> >
> > I was starting to write some tests when the interviewer interrupted me.
> >
> > "What is that?"
> >
> > "It's a recursive descent parser. It detects if the input is
> well-formed."
> >
> > Blank look.
> >
> > I started to walk him through the code.
> >
> > He interrupted me. "Excuse me, I'll be back in a few minutes."
> >
> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the
> recruiter will get back to you." That's the last I hear from them.
>
>

[-- Attachment #2: Type: text/html, Size: 2339 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Ken Thompson]

[-- Attachment #1: Type: text/plain, Size: 5488 bytes --]

i find that SD and yacc have about the same
time performance. yacc gets a bad rep when
it uses lex as its front-end. then it is pig-slow.


On Mon, Mar 10, 2025 at 6:52 PM Larry McVoy <lm@mcvoy.com> wrote:

> I'm guessing this is because yacc makes it easy to fiddle with the grammar?
> Does performance factor in?
>
> I'm actually curious because BitKeeper has what we call a dspec language
> which lets you wander through the revision history and print it out in
> a sort of awk/printf like language.  If my memory serves me, we had a
> version in yacc (really flex but same thing) and Rob (cc-ed) rewrote
> it in a recursive-descent parser for performance reasons.  If you are
> curious, this is a dspec that spits out history in JSON format that
> I wrote because one of my engineers said it was impossible (it wasn't):
>
> http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt
>
> $0 .. $9 are variables.  We used $if as a way to get an if statement
> rather than just say "if", :whatever: is a way to fish some field out
> of the history, Marc will get it, it's SCCS's :D: that means date, we
> just took it a lot further.
>
> I don't remember how much faster the RD version was but it was a lot,
> for sure more than a factor of 2 and maybe much more than that.  All
> I remember is at some point the dspec parser was a performance issue
> and after Rob rewrote it, it wasn't.
>
> On Mon, Mar 10, 2025 at 05:06:13PM -0700, Ken Thompson wrote:
> > re yacc vs RD
> >
> > i agree that they are about the same,
> > where the edge would tilt based on the parsed language.
> > BUT when the parsed language (like go) is not yet defined,
> > yacc is the only option.
> >
> >
> >
> > On Mon, Mar 10, 2025 at 4:50???PM Clem Cole <clemc@ccc.com> wrote:
> >
> > > Marc - check out OpenSIMH( https://opensimh.org)
> > > Check out over 40 different simulators including the I7000 which
> > > supports IBM 701,7010,7070,7080, 7090 -
> https://opensimh.org/simulators/
> > >
> > >
> > > ???
> > >
> > > On Mon, Mar 10, 2025 at 7:12???PM Marc Rochkind <mrochkind@gmail.com>
> wrote:
> > >
> > >> This thread started to be about what I thought were system programming
> > >> languages (e.g., C, BLISS) and seems to have meandered into a general
> > >> discussion of languages that were around in the 1960s and 1970s, so,
> what
> > >> the heck, I'll add my own story.
> > >>
> > >> PL/0 is an education programming language introduced in the book,
> *Algorithms
> > >> + Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great
> > >> language for teaching compiler writing because it contains interesting
> > >> concepts, such as recursive functions, yet isn't overly complicated. I
> > >> wrote a PL/0 compiler for the IBM 701 (
> > >> https://github.com/MarcRochkind/pl0compiler).
> > >>
> > >> Yeah, that's not a misprint. I wrote perhaps the world's only 701
> > >> emulator (https://www.mrochkind.com/mrochkind/a-701.html), and my
> PL/0
> > >> compiler runs on it. Unfortunately, I can't verify that the compiled
> code
> > >> runs on an actual 701, since I'm sure there haven't been any in
> operation
> > >> for many decades. For those of you who haven't had the pleasure,
> > >> programming the 701 is really hard. It had no index registers, and
> the sign
> > >> bit didn't participate in shifts. Still, my compiler compiles
> full-blown
> > >> PL/0.
> > >>
> > >> So there! ;-)
> > >>
> > >> Marc Rochkind
> > >>
> > >> On Mon, Mar 10, 2025 at 2:49???PM Bakul Shah via TUHS <tuhs@tuhs.org>
> > >> wrote:
> > >>
> > >>> Perhaps the interviewer was looking for something dumb like the
> following
> > >>> and not a full RD parser?
> > >>>
> > >>> int count = 0;
> > >>> while (*cp) {
> > >>>         char c = *cp++;
> > >>>         count += c == '(' ? 1 : c == ')' ? -1 : 0;
> > >>>         if (count < 0) return -1; // FAIL: one too many )
> > >>> }
> > >>> if (count > 0) return -1; // FAIL: too many (
> > >>> return 0; // SUCCESS
> > >>>
> > >>> Though this will fall apart if you also want to also balance braces
> &/or
> > >>> brackets and must catch invalid cases like "(..[..)..]"!
> > >>>
> > >>> > On Mar 10, 2025, at 8:19???AM, John Cowan <cowan@ccil.org> wrote:
> > >>> >
> > >>> > I was working at the whiteboard during a job interview once. I had
> > >>> been asked to write a function to report if its input had balanced
> > >>> parentheses.  No problem: I wrote an RD parser in Python (which I
> prefer
> > >>> for whiteboarding) to detect balance and return True if the parse was
> > >>> successful and False if EOF was reached.
> > >>> >
> > >>> > I was starting to write some tests when the interviewer
> interrupted me.
> > >>> >
> > >>> > "What is that?"
> > >>> >
> > >>> > "It's a recursive descent parser. It detects if the input is
> > >>> well-formed."
> > >>> >
> > >>> > Blank look.
> > >>> >
> > >>> > I started to walk him through the code.
> > >>> >
> > >>> > He interrupted me. "Excuse me, I'll be back in a few minutes."
> > >>> >
> > >>> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you,
> the
> > >>> recruiter will get back to you." That's the last I hear from them.
> > >>>
> > >>>
> > >>
> > >> --
> > >> Subscribe to my Photo-of-the-Week emails at my website mrochkind.com.
> > >>
> > >
>
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

[-- Attachment #2: Type: text/html, Size: 7947 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Larry McVoy]

I'm guessing this is because yacc makes it easy to fiddle with the grammar?
Does performance factor in?

I'm actually curious because BitKeeper has what we call a dspec language
which lets you wander through the revision history and print it out in
a sort of awk/printf like language.  If my memory serves me, we had a 
version in yacc (really flex but same thing) and Rob (cc-ed) rewrote 
it in a recursive-descent parser for performance reasons.  If you are
curious, this is a dspec that spits out history in JSON format that 
I wrote because one of my engineers said it was impossible (it wasn't):

http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt

$0 .. $9 are variables.  We used $if as a way to get an if statement
rather than just say "if", :whatever: is a way to fish some field out
of the history, Marc will get it, it's SCCS's :D: that means date, we
just took it a lot further.

I don't remember how much faster the RD version was but it was a lot,
for sure more than a factor of 2 and maybe much more than that.  All
I remember is at some point the dspec parser was a performance issue
and after Rob rewrote it, it wasn't.

On Mon, Mar 10, 2025 at 05:06:13PM -0700, Ken Thompson wrote:
> re yacc vs RD
> 
> i agree that they are about the same,
> where the edge would tilt based on the parsed language.
> BUT when the parsed language (like go) is not yet defined,
> yacc is the only option.
> 
> 
> 
> On Mon, Mar 10, 2025 at 4:50???PM Clem Cole <clemc@ccc.com> wrote:
> 
> > Marc - check out OpenSIMH( https://opensimh.org)
> > Check out over 40 different simulators including the I7000 which
> > supports IBM 701,7010,7070,7080, 7090 - https://opensimh.org/simulators/
> >
> >
> > ???
> >
> > On Mon, Mar 10, 2025 at 7:12???PM Marc Rochkind <mrochkind@gmail.com> wrote:
> >
> >> This thread started to be about what I thought were system programming
> >> languages (e.g., C, BLISS) and seems to have meandered into a general
> >> discussion of languages that were around in the 1960s and 1970s, so, what
> >> the heck, I'll add my own story.
> >>
> >> PL/0 is an education programming language introduced in the book, *Algorithms
> >> + Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great
> >> language for teaching compiler writing because it contains interesting
> >> concepts, such as recursive functions, yet isn't overly complicated. I
> >> wrote a PL/0 compiler for the IBM 701 (
> >> https://github.com/MarcRochkind/pl0compiler).
> >>
> >> Yeah, that's not a misprint. I wrote perhaps the world's only 701
> >> emulator (https://www.mrochkind.com/mrochkind/a-701.html), and my PL/0
> >> compiler runs on it. Unfortunately, I can't verify that the compiled code
> >> runs on an actual 701, since I'm sure there haven't been any in operation
> >> for many decades. For those of you who haven't had the pleasure,
> >> programming the 701 is really hard. It had no index registers, and the sign
> >> bit didn't participate in shifts. Still, my compiler compiles full-blown
> >> PL/0.
> >>
> >> So there! ;-)
> >>
> >> Marc Rochkind
> >>
> >> On Mon, Mar 10, 2025 at 2:49???PM Bakul Shah via TUHS <tuhs@tuhs.org>
> >> wrote:
> >>
> >>> Perhaps the interviewer was looking for something dumb like the following
> >>> and not a full RD parser?
> >>>
> >>> int count = 0;
> >>> while (*cp) {
> >>>         char c = *cp++;
> >>>         count += c == '(' ? 1 : c == ')' ? -1 : 0;
> >>>         if (count < 0) return -1; // FAIL: one too many )
> >>> }
> >>> if (count > 0) return -1; // FAIL: too many (
> >>> return 0; // SUCCESS
> >>>
> >>> Though this will fall apart if you also want to also balance braces &/or
> >>> brackets and must catch invalid cases like "(..[..)..]"!
> >>>
> >>> > On Mar 10, 2025, at 8:19???AM, John Cowan <cowan@ccil.org> wrote:
> >>> >
> >>> > I was working at the whiteboard during a job interview once. I had
> >>> been asked to write a function to report if its input had balanced
> >>> parentheses.  No problem: I wrote an RD parser in Python (which I prefer
> >>> for whiteboarding) to detect balance and return True if the parse was
> >>> successful and False if EOF was reached.
> >>> >
> >>> > I was starting to write some tests when the interviewer interrupted me.
> >>> >
> >>> > "What is that?"
> >>> >
> >>> > "It's a recursive descent parser. It detects if the input is
> >>> well-formed."
> >>> >
> >>> > Blank look.
> >>> >
> >>> > I started to walk him through the code.
> >>> >
> >>> > He interrupted me. "Excuse me, I'll be back in a few minutes."
> >>> >
> >>> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the
> >>> recruiter will get back to you." That's the last I hear from them.
> >>>
> >>>
> >>
> >> --
> >> Subscribe to my Photo-of-the-Week emails at my website mrochkind.com.
> >>
> >

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: What would early alternatives to C have been?

[Ken Thompson]

[-- Attachment #1: Type: text/plain, Size: 3503 bytes --]

re yacc vs RD

i agree that they are about the same,
where the edge would tilt based on the parsed language.
BUT when the parsed language (like go) is not yet defined,
yacc is the only option.



On Mon, Mar 10, 2025 at 4:50 PM Clem Cole <clemc@ccc.com> wrote:

> Marc - check out OpenSIMH( https://opensimh.org)
> Check out over 40 different simulators including the I7000 which
> supports IBM 701,7010,7070,7080, 7090 - https://opensimh.org/simulators/
>
>
> ᐧ
>
> On Mon, Mar 10, 2025 at 7:12 PM Marc Rochkind <mrochkind@gmail.com> wrote:
>
>> This thread started to be about what I thought were system programming
>> languages (e.g., C, BLISS) and seems to have meandered into a general
>> discussion of languages that were around in the 1960s and 1970s, so, what
>> the heck, I'll add my own story.
>>
>> PL/0 is an education programming language introduced in the book, *Algorithms
>> + Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great
>> language for teaching compiler writing because it contains interesting
>> concepts, such as recursive functions, yet isn't overly complicated. I
>> wrote a PL/0 compiler for the IBM 701 (
>> https://github.com/MarcRochkind/pl0compiler).
>>
>> Yeah, that's not a misprint. I wrote perhaps the world's only 701
>> emulator (https://www.mrochkind.com/mrochkind/a-701.html), and my PL/0
>> compiler runs on it. Unfortunately, I can't verify that the compiled code
>> runs on an actual 701, since I'm sure there haven't been any in operation
>> for many decades. For those of you who haven't had the pleasure,
>> programming the 701 is really hard. It had no index registers, and the sign
>> bit didn't participate in shifts. Still, my compiler compiles full-blown
>> PL/0.
>>
>> So there! ;-)
>>
>> Marc Rochkind
>>
>> On Mon, Mar 10, 2025 at 2:49 PM Bakul Shah via TUHS <tuhs@tuhs.org>
>> wrote:
>>
>>> Perhaps the interviewer was looking for something dumb like the following
>>> and not a full RD parser?
>>>
>>> int count = 0;
>>> while (*cp) {
>>>         char c = *cp++;
>>>         count += c == '(' ? 1 : c == ')' ? -1 : 0;
>>>         if (count < 0) return -1; // FAIL: one too many )
>>> }
>>> if (count > 0) return -1; // FAIL: too many (
>>> return 0; // SUCCESS
>>>
>>> Though this will fall apart if you also want to also balance braces &/or
>>> brackets and must catch invalid cases like "(..[..)..]"!
>>>
>>> > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote:
>>> >
>>> > I was working at the whiteboard during a job interview once. I had
>>> been asked to write a function to report if its input had balanced
>>> parentheses.  No problem: I wrote an RD parser in Python (which I prefer
>>> for whiteboarding) to detect balance and return True if the parse was
>>> successful and False if EOF was reached.
>>> >
>>> > I was starting to write some tests when the interviewer interrupted me.
>>> >
>>> > "What is that?"
>>> >
>>> > "It's a recursive descent parser. It detects if the input is
>>> well-formed."
>>> >
>>> > Blank look.
>>> >
>>> > I started to walk him through the code.
>>> >
>>> > He interrupted me. "Excuse me, I'll be back in a few minutes."
>>> >
>>> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the
>>> recruiter will get back to you." That's the last I hear from them.
>>>
>>>
>>
>> --
>> Subscribe to my Photo-of-the-Week emails at my website mrochkind.com.
>>
>

[-- Attachment #2: Type: text/html, Size: 5731 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Marc Rochkind]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

Clem, thanks... didn't know about those.

MIne has two features that the other one perhaps doesn't: A fully
functional control panel, and it operates at the speed of the 701.

On Mon, Mar 10, 2025 at 5:49 PM Clem Cole <clemc@ccc.com> wrote:

> Marc - check out OpenSIMH( https://opensimh.org)
> Check out over 40 different simulators including the I7000 which
> supports IBM 701,7010,7070,7080, 7090 - https://opensimh.org/simulators/
>
>
>

[-- Attachment #2: Type: text/html, Size: 1164 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]

Marc - check out OpenSIMH( https://opensimh.org)
Check out over 40 different simulators including the I7000 which
supports IBM 701,7010,7070,7080, 7090 - https://opensimh.org/simulators/


ᐧ

On Mon, Mar 10, 2025 at 7:12 PM Marc Rochkind <mrochkind@gmail.com> wrote:

> This thread started to be about what I thought were system programming
> languages (e.g., C, BLISS) and seems to have meandered into a general
> discussion of languages that were around in the 1960s and 1970s, so, what
> the heck, I'll add my own story.
>
> PL/0 is an education programming language introduced in the book, *Algorithms
> + Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great
> language for teaching compiler writing because it contains interesting
> concepts, such as recursive functions, yet isn't overly complicated. I
> wrote a PL/0 compiler for the IBM 701 (
> https://github.com/MarcRochkind/pl0compiler).
>
> Yeah, that's not a misprint. I wrote perhaps the world's only 701 emulator
> (https://www.mrochkind.com/mrochkind/a-701.html), and my PL/0 compiler
> runs on it. Unfortunately, I can't verify that the compiled code runs on an
> actual 701, since I'm sure there haven't been any in operation for many
> decades. For those of you who haven't had the pleasure, programming the 701
> is really hard. It had no index registers, and the sign bit didn't
> participate in shifts. Still, my compiler compiles full-blown PL/0.
>
> So there! ;-)
>
> Marc Rochkind
>
> On Mon, Mar 10, 2025 at 2:49 PM Bakul Shah via TUHS <tuhs@tuhs.org> wrote:
>
>> Perhaps the interviewer was looking for something dumb like the following
>> and not a full RD parser?
>>
>> int count = 0;
>> while (*cp) {
>>         char c = *cp++;
>>         count += c == '(' ? 1 : c == ')' ? -1 : 0;
>>         if (count < 0) return -1; // FAIL: one too many )
>> }
>> if (count > 0) return -1; // FAIL: too many (
>> return 0; // SUCCESS
>>
>> Though this will fall apart if you also want to also balance braces &/or
>> brackets and must catch invalid cases like "(..[..)..]"!
>>
>> > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote:
>> >
>> > I was working at the whiteboard during a job interview once. I had been
>> asked to write a function to report if its input had balanced parentheses.
>> No problem: I wrote an RD parser in Python (which I prefer for
>> whiteboarding) to detect balance and return True if the parse was
>> successful and False if EOF was reached.
>> >
>> > I was starting to write some tests when the interviewer interrupted me.
>> >
>> > "What is that?"
>> >
>> > "It's a recursive descent parser. It detects if the input is
>> well-formed."
>> >
>> > Blank look.
>> >
>> > I started to walk him through the code.
>> >
>> > He interrupted me. "Excuse me, I'll be back in a few minutes."
>> >
>> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the
>> recruiter will get back to you." That's the last I hear from them.
>>
>>
>
> --
> Subscribe to my Photo-of-the-Week emails at my website mrochkind.com.
>

[-- Attachment #2: Type: text/html, Size: 5058 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Marc Rochkind]

[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]

This thread started to be about what I thought were system programming
languages (e.g., C, BLISS) and seems to have meandered into a general
discussion of languages that were around in the 1960s and 1970s, so, what
the heck, I'll add my own story.

PL/0 is an education programming language introduced in the book, *Algorithms
+ Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great
language for teaching compiler writing because it contains interesting
concepts, such as recursive functions, yet isn't overly complicated. I
wrote a PL/0 compiler for the IBM 701 (
https://github.com/MarcRochkind/pl0compiler).

Yeah, that's not a misprint. I wrote perhaps the world's only 701 emulator (
https://www.mrochkind.com/mrochkind/a-701.html), and my PL/0 compiler runs
on it. Unfortunately, I can't verify that the compiled code runs on an
actual 701, since I'm sure there haven't been any in operation for many
decades. For those of you who haven't had the pleasure, programming the 701
is really hard. It had no index registers, and the sign bit didn't
participate in shifts. Still, my compiler compiles full-blown PL/0.

So there! ;-)

Marc Rochkind

On Mon, Mar 10, 2025 at 2:49 PM Bakul Shah via TUHS <tuhs@tuhs.org> wrote:

> Perhaps the interviewer was looking for something dumb like the following
> and not a full RD parser?
>
> int count = 0;
> while (*cp) {
>         char c = *cp++;
>         count += c == '(' ? 1 : c == ')' ? -1 : 0;
>         if (count < 0) return -1; // FAIL: one too many )
> }
> if (count > 0) return -1; // FAIL: too many (
> return 0; // SUCCESS
>
> Though this will fall apart if you also want to also balance braces &/or
> brackets and must catch invalid cases like "(..[..)..]"!
>
> > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote:
> >
> > I was working at the whiteboard during a job interview once. I had been
> asked to write a function to report if its input had balanced parentheses.
> No problem: I wrote an RD parser in Python (which I prefer for
> whiteboarding) to detect balance and return True if the parse was
> successful and False if EOF was reached.
> >
> > I was starting to write some tests when the interviewer interrupted me.
> >
> > "What is that?"
> >
> > "It's a recursive descent parser. It detects if the input is
> well-formed."
> >
> > Blank look.
> >
> > I started to walk him through the code.
> >
> > He interrupted me. "Excuse me, I'll be back in a few minutes."
> >
> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the
> recruiter will get back to you." That's the last I hear from them.
>
>

-- 
Subscribe to my Photo-of-the-Week emails at my website mrochkind.com.

[-- Attachment #2: Type: text/html, Size: 3755 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Bakul Shah via TUHS]

Perhaps the interviewer was looking for something dumb like the following
and not a full RD parser?

int count = 0;
while (*cp) {
	char c = *cp++;
	count += c == '(' ? 1 : c == ')' ? -1 : 0;
	if (count < 0) return -1; // FAIL: one too many )
}
if (count > 0) return -1; // FAIL: too many (
return 0; // SUCCESS

Though this will fall apart if you also want to also balance braces &/or
brackets and must catch invalid cases like "(..[..)..]"!

> On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote:
> 
> I was working at the whiteboard during a job interview once. I had been asked to write a function to report if its input had balanced parentheses.  No problem: I wrote an RD parser in Python (which I prefer for whiteboarding) to detect balance and return True if the parse was successful and False if EOF was reached.
> 
> I was starting to write some tests when the interviewer interrupted me.
> 
> "What is that?"
> 
> "It's a recursive descent parser. It detects if the input is well-formed."
> 
> Blank look.
> 
> I started to walk him through the code.
> 
> He interrupted me. "Excuse me, I'll be back in a few minutes."
> 
> Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the recruiter will get back to you." That's the last I hear from them.

[TUHS] Re: What would early alternatives to C have been?

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Mon, 10 Mar 2025, John Cowan wrote:

> I was working at the whiteboard during a job interview once. I had been
> asked to write a function to report if its input had balanced parentheses. 
> No problem: I wrote an RD parser in Python (which I prefer for
> whiteboarding) to detect balance and return True if the parse was successful
> and False if EOF was reached.

RD is a bit over the top, isn't it?

Pseudocode:

    set counter to 0

    while !EOF
    do
	read char
	char == "(" -> counter++
	char == ")" -> counter--
	abort "Unbalanced: )" if counter < 0
    done

    abort "Unbalanced: (" if counter > 0

Untested, of course :-)

-- Dave

[TUHS] Re: What would early alternatives to C have been?

[Dan Cross]

On Mon, Mar 10, 2025 at 11:13 AM Clem Cole <clemc@ccc.com> wrote:
> On Sun, Mar 9, 2025 at 10:03 PM Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>> Yacc certainly makes it easier to write parsers for big grammars, but it's far from cheating. You need to know a lot more about parsing to use Yacc than you need to roll your own.
>
> I disagree here.  I have wtchged too many young programmers that I realized did not understand what yacc  was doing and came to understanding that never built a simple parse before.

Funny, I agree with both of you, and with Rob. :-)

If I'm not mistaken, I think what Doug was suggesting was that, to
really understand what YACC is _doing_ requires understanding a lot
more about the theory of parsing, grammars, and so on, than one needs
to understand to write a fairly simple RD parser.  RD makes a lot of
sense intuitively, but once you introduce table-driven parsing,
LALR(1), etc, you get into a whole different level of theory and
rigor. Of course, by design the tool abstracts that away from you, so
to just _use_ it you don't necessarily need to understand as much.

>[...]
> The interesting thing is while I tend to use yacc for most parsers, I've found myself building recursive descent parsers in a couple of cases where it seems to make better sense.

Funny, I'm the opposite: I've used YACC for a few parsers, but prefer
to roll my own. I find that I'm either parsing something very simple,
in which case reaching for YACC feels like cutting butter with a
chainsaw, or I need to do something that YACC isn't super great at
(like run in a multithreaded environment). YACC is superb at what it
does, but not something I feel like I need that often.

        - Dan C.

[TUHS] Re: What would early alternatives to C have been?

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

I was working at the whiteboard during a job interview once. I had been
asked to write a function to report if its input had balanced parentheses.
No problem: I wrote an RD parser in Python (which I prefer for
whiteboarding) to detect balance and return True if the parse was
successful and False if EOF was reached.

I was starting to write some tests when the interviewer interrupted me.

"What is that?"

"It's a recursive descent parser. It detects if the input is well-formed."

Blank look.

I started to walk him through the code.

He interrupted me. "Excuse me, I'll be back in a few minutes."

Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the
recruiter will get back to you." That's the last I hear from them.

On Mon, Mar 10, 2025, 12:10 AM Rob Pike <robpike@gmail.com> wrote:

> A rare case where I disagree with you, Doug. If the language is reasonably
> regular (I do not mean in the strict Kleene sense), a recursive descent
> parser is not much harder to write than a yacc grammar, and much smoother
> at providing good error messages. Having done many yaccs and many RD
> parsers, I no longer go to yacc.
>
> To put it another way, there are few programming tasks I enjoy more than
> writing a recursive descent parser for a sane language.
>
> Now if the language is not so regular, my position might shift. I do
> recall Bjarne dynamically editing the generated tables mid-parse to get
> yacc to handle at least one stage of C++'s development.
>
> Another way to think of it is that if you are designing the language and
> it is undergoing frequent changes in grammar, yacc could certainly be move
> you along faster. But even then once things had settled I'd still redo it
> as RD, for the quality of the result.
>
> You can credit Stephen R. "Software" Steve for this change in my thinking.
>
> -rob
>
>
> On Mon, Mar 10, 2025 at 1:12 PM Douglas McIlroy <
> douglas.mcilroy@dartmouth.edu> wrote:
>
>> > everyone should write for their first compiler in Pascal for a
>> > simple language and no cheating using YACC.  You need to write the whole
>> > thing if you want to understand how parsing really works.
>>
>> Yacc certainly makes it easier to write parsers for big grammars, but
>> it's far from cheating. You need to know a lot more about parsing to use
>> Yacc than you need to roll your own.
>>
>> Hand parsing of a tiny grammar is almost a  necessary step on the way to
>> understanding Yacc. But I think hand-building the whole parser for a
>> compiler is unnecessary torture--like doing trigonometry with log tables.
>>
>> Doug
>>
>

[-- Attachment #2: Type: text/html, Size: 4605 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

below...  (At the risk of a case of being in disagreement with someone I
rarely am).

On Sun, Mar 9, 2025 at 10:03 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

>
> Yacc certainly makes it easier to write parsers for big grammars, but
> it's far from cheating. You need to know a lot more about parsing to use
> Yacc than you need to roll your own.
>
I disagree here.  I have wtchged too many young programmers that I realized
did not understand what yacc  was doing and came to understanding that
never built a simple parse before.
I'm not asking them to rebuild a parser for Algol68 or  C++ in a one
semester course.  I asking that to you take something like Dennis Allisons
"tiny basic" assignment for his Stanfrodf students in the lat 1970s and ask
them to build that.

Peter Hibbard gave us a super small Algol-ish language, and we generated
code for the "CMU Mini" (which was basically Gordon Bell's the precursor to
the PDP-8 (see ISP below) - in my time the "Dragon Book was not yet written
BTW.  I really understood what Stev had accomplished.

The interesting thing is while I tend to use yacc for most parsers, I've
found myself building recursive descent parsers in a couple of cases where
it seems to make better sense.


>
> Hand parsing of a tiny grammar is almost a  necessary step on the way to
> understanding Yacc. But I think hand-building the whole parser for a
> compiler is unnecessary torture--like doing trigonometry with log tables.
>
Point table ... however a funny thing to consider. My father was a high
school math teacher for 40 years. He noted that the loss of slide rules and
trig tables made his "modern" (post-calculator) students not understand
interpolation.To me, learning to use mathematical tables is a skill that
never hurts.  I don't even think of asking people "to walk uphill both ways
to school in the snow and rain instead of riding a heated, dry yellow
school bus." I am asking the student to learn foundational ideas and build
skills up top of core understanding.
ᐧ

[-- Attachment #2: Type: text/html, Size: 4867 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

A rare case where I disagree with you, Doug. If the language is reasonably
regular (I do not mean in the strict Kleene sense), a recursive descent
parser is not much harder to write than a yacc grammar, and much smoother
at providing good error messages. Having done many yaccs and many RD
parsers, I no longer go to yacc.

To put it another way, there are few programming tasks I enjoy more than
writing a recursive descent parser for a sane language.

Now if the language is not so regular, my position might shift. I do recall
Bjarne dynamically editing the generated tables mid-parse to get yacc to
handle at least one stage of C++'s development.

Another way to think of it is that if you are designing the language and it
is undergoing frequent changes in grammar, yacc could certainly be move you
along faster. But even then once things had settled I'd still redo it as
RD, for the quality of the result.

You can credit Stephen R. "Software" Steve for this change in my thinking.

-rob


On Mon, Mar 10, 2025 at 1:12 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> > everyone should write for their first compiler in Pascal for a
> > simple language and no cheating using YACC.  You need to write the whole
> > thing if you want to understand how parsing really works.
>
> Yacc certainly makes it easier to write parsers for big grammars, but
> it's far from cheating. You need to know a lot more about parsing to use
> Yacc than you need to roll your own.
>
> Hand parsing of a tiny grammar is almost a  necessary step on the way to
> understanding Yacc. But I think hand-building the whole parser for a
> compiler is unnecessary torture--like doing trigonometry with log tables.
>
> Doug
>

[-- Attachment #2: Type: text/html, Size: 3105 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Charles H. Sauer]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

[While walking 5 miles through the snow …]

> On Mar 9, 2025, at 9:03 PM, Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
> 
> > everyone should write for their first compiler in Pascal for a
> > simple language and no cheating using YACC.  You need to write the whole
> > thing if you want to understand how parsing really works.
> 
> Yacc certainly makes it easier to write parsers for big grammars, but it's far from cheating. You need to know a lot more about parsing to use Yacc than you need to roll your own. 
> 
> Hand parsing of a tiny grammar is almost a  necessary step on the way to understanding Yacc. But I think hand-building the whole parser for a compiler is unnecessary torture--like doing trigonometry with log tables.
> 
> Doug

In 1971 compiler construction course at UT-Austin, we had to use CDC Fortran to build a compiler for a subset of Algol 60. Undergraduates used punch cards and RJE to the 6600/6400 shared by all but the privleged few.

Charlie

--
voice: +1.512.784.7526       e-mail: sauer@technologists.com <mailto:sauer@technologists.com>           
fax: +1.512.346.5240         web: https://technologists.com/sauer/ <http://technologists.com/sauer/>
Facebook/Google/LinkedIn/mas.to: CharlesHSauer


[-- Attachment #2: Type: text/html, Size: 3550 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Douglas McIlroy]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

> everyone should write for their first compiler in Pascal for a
> simple language and no cheating using YACC.  You need to write the whole
> thing if you want to understand how parsing really works.

Yacc certainly makes it easier to write parsers for big grammars, but
it's far from cheating. You need to know a lot more about parsing to use
Yacc than you need to roll your own.

Hand parsing of a tiny grammar is almost a  necessary step on the way to
understanding Yacc. But I think hand-building the whole parser for a
compiler is unnecessary torture--like doing trigonometry with log tables.

Doug

[-- Attachment #2: Type: text/html, Size: 837 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Ken Thompson]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

> Was smalgol also known as BC Algol, as described here:

no, bc algol was a phd thesis of ralph love. i was an RA for ralph.
he was a phd student for wirth.

it was supposed to be the first (only?) complete implementation
of algol 60. (thats an interesting statement: think of integer labels,
and recursive call by name.)  i coded most of the compile-to-byte-code
pass of the compiler. ralph designed it. later i wrote a byte-code
interpreter on a pdp-8s, which showed the memory state graphically.



On Sun, Mar 9, 2025 at 2:01 PM Paul McJones <paul@mcjones.org> wrote:

> Ken,
>
> Was smalgol also known as BC Algol, as described here:
>
> https://www.softwarepreservation.org/projects/ALGOL/algol60impl/#BC_ALGOL
>
> On Mar 9, 2025, at 12:06 PM, Ken Thompson <kenbob@gmail.com>
>
>  wrote:
>
> how about smalgol?
>
> it was an algol-like language with just int and float types.
> i dont know its history, but it came out of berkeley near
> when Niklaus Wirth was there. it compiled for the ibm 7094
> in normal batch processing fashion. i converted it to a jit
> into memory in order to skip the loading phase. i used
> it for a lot of my fun-work. (1965-66)
>
> mainframe time, then, was a big factor in the computing process.
> smalgol could compile, load, and run in about 1 cpu-second.
>
> smalgol was all ibm-cards, but it was on my mind through
> the bcpl to b to nb phases. i would use the modern word
> "influencer.”
>
>
>
> Paul McJones
>
>
>

[-- Attachment #2: Type: text/html, Size: 9190 bytes --]

[TUHS] Re: What would early alternatives to C have been?

[Paul McJones]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

Ken,

Was smalgol also known as BC Algol, as described here:

https://www.softwarepreservation.org/projects/ALGOL/algol60impl/#BC_ALGOL

> On Mar 9, 2025, at 12:06 PM, Ken Thompson <kenbob@gmail.com <mailto:kenbob@gmail.com>>
>  wrote:
> 
> how about smalgol?
> 
> it was an algol-like language with just int and float types.
> i dont know its history, but it came out of berkeley near
> when Niklaus Wirth was there. it compiled for the ibm 7094
> in normal batch processing fashion. i converted it to a jit
> into memory in order to skip the loading phase. i used
> it for a lot of my fun-work. (1965-66)
> 
> mainframe time, then, was a big factor in the computing process.
> smalgol could compile, load, and run in about 1 cpu-second.
> 
> smalgol was all ibm-cards, but it was on my mind through
> the bcpl to b to nb phases. i would use the modern word
> "influencer.”


Paul McJones



[-- Attachment #2: Type: text/html, Size: 10734 bytes --]