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

[Ken Thompson <kenbob@gmail.com>]

[-- 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 --]