The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
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 --]

  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).