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

[Ken Thompson <kenbob@gmail.com>]

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