From: John Cowan <cowan@ccil.org>
To: Rob Pike <robpike@gmail.com>
Cc: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>,
TUHS main list <tuhs@tuhs.org>
Subject: [TUHS] Re: What would early alternatives to C have been?
Date: Mon, 10 Mar 2025 11:19:19 -0400 [thread overview]
Message-ID: <CAD2gp_RgWta3n4ugyCHTrb0hxQUQgjGaemEp+kQiKPFuqDDGUg@mail.gmail.com> (raw)
In-Reply-To: <CAKzdPgyJ4yoSjJG5XsrUEMexqd2-hSvmU9=5p88DSsQpEVW7TA@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2025-03-10 15:19 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-10 2:03 Douglas McIlroy
2025-03-10 2:28 ` Charles H. Sauer
2025-03-11 2:26 ` [TUHS] Re: uphill both ways, was " John Levine
2025-03-10 4:10 ` [TUHS] " Rob Pike
2025-03-10 15:19 ` John Cowan [this message]
2025-03-10 19:56 ` Dave Horsfall
2025-03-10 20:49 ` Bakul Shah via TUHS
2025-03-10 23:12 ` Marc Rochkind
2025-03-10 23:49 ` Clem Cole
2025-03-10 23:58 ` Marc Rochkind
2025-03-11 0:06 ` Ken Thompson
2025-03-11 1:35 ` Larry McVoy
2025-03-11 5:07 ` Ken Thompson
[not found] ` <CAKH6PiW8J8=uFbadUTSaC9VcLGUJMFZaSFWOFDyCM3MpMTSayw@mail.gmail.com <CAMP=X_mchJuVgdpc4-AYHASwEVzUcJXMmqSDv_UvX6y0o0+LBQ@mail.gmail.com>
2025-03-12 1:36 ` [TUHS] Re: parsing tools, was What would early alternatives John Levine
2025-03-12 2:22 ` Rich Salz
2025-03-12 3:35 ` Larry McVoy
2025-03-12 16:35 ` John R Levine
2025-03-12 5:11 ` Greg A. Woods
2025-03-11 5:15 ` [TUHS] Re: What would early alternatives to C have been? John Cowan
2025-03-10 15:12 ` Clem Cole
2025-03-10 15:24 ` Dan Cross
[not found] <174154718981.615624.15831772136951719489@minnie.tuhs.org>
2025-03-09 21:01 ` Paul McJones
2025-03-10 0:38 ` Ken Thompson
-- strict thread matches above, loose matches on Subject: below --
2025-03-09 3:46 [TUHS] " Dan Cross
2025-03-09 6:14 ` [TUHS] " George Michaelson
2025-03-09 12:29 ` Clem Cole
2025-03-09 13:18 ` G. Branden Robinson
2025-03-09 17:29 ` Clem Cole
2025-03-09 19:06 ` Ken Thompson
2025-03-09 19:41 ` G. Branden Robinson
2025-03-09 19:57 ` Bakul Shah via TUHS
2025-03-09 22:47 ` Dave Horsfall
2025-03-09 22:58 ` Clem Cole
2025-03-09 23:12 ` Larry McVoy
2025-03-09 23:18 ` Steve Nickolas
2025-03-09 23:39 ` Lawrence Stewart
2025-03-10 0:55 ` Stuff Received
2025-03-10 1:19 ` Rob Pike
2025-03-10 3:06 ` Larry McVoy
2025-03-10 9:12 ` arnold
2025-03-10 14:41 ` Larry McVoy
2025-03-10 14:52 ` Clem Cole
2025-03-10 15:06 ` Larry McVoy
2025-03-10 15:27 ` Dan Cross
2025-03-10 15:46 ` Larry McVoy
2025-03-10 15:47 ` Warner Losh
2025-03-10 14:57 ` Dan Cross
2025-03-10 15:09 ` Larry McVoy
2025-03-10 16:30 ` arnold
2025-03-10 18:18 ` segaloco via TUHS
2025-03-10 18:39 ` Stuff Received
2025-03-10 18:56 ` Bakul Shah via TUHS
2025-03-10 23:25 ` Greg A. Woods
2025-03-10 23:35 ` segaloco via TUHS
2025-03-11 1:14 ` Dan Cross
2025-03-11 0:01 ` Clem Cole
2025-03-11 2:18 ` John Levine
2025-03-11 4:00 ` G. Branden Robinson
2025-03-11 4:14 ` George Michaelson
2025-03-11 15:18 ` Ron Natalie
2025-03-11 21:52 ` Rob Pike
2025-03-09 20:13 ` John Levine
2025-03-09 20:35 ` Luther Johnson
2025-03-09 20:58 ` Clem Cole
2025-03-09 21:12 ` Luther Johnson
2025-03-09 22:57 ` Warner Losh
2025-03-10 1:51 ` John Levine
2025-03-10 2:54 ` Luther Johnson
2025-03-10 1:31 ` Bakul Shah via TUHS
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD2gp_RgWta3n4ugyCHTrb0hxQUQgjGaemEp+kQiKPFuqDDGUg@mail.gmail.com \
--to=cowan@ccil.org \
--cc=douglas.mcilroy@dartmouth.edu \
--cc=robpike@gmail.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).