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

[Larry McVoy <lm@mcvoy.com>]

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