From: Rob Pike <robpike@gmail.com>
To: Bakul Shah <bakul@iitbombay.org>
Cc: The Unix Heritage Society mailing list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] [tuhs] Dennis Ritchie's couch
Date: Wed, 26 May 2021 16:52:43 +1000 [thread overview]
Message-ID: <CAKzdPgy6DnFuRwxT4_ZE3qoS5HP2Ze0=G_SXm1i7XQtNbeg_Dw@mail.gmail.com> (raw)
In-Reply-To: <2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org>
[-- Attachment #1: Type: text/plain, Size: 3673 bytes --]
I enjoy writing recursive descent parsers, and I enjoy the grammars that
result from such parsers when cleanly done.
I do agree though that if you grammar is being invented as you go, yacc can
be a boon. But in a sense, that's also it's biggest failing: it makes it
too easy to write bad grammars.
-rob
On Wed, May 26, 2021 at 4:22 PM Bakul Shah <bakul@iitbombay.org> wrote:
> Many existing programming languages do have a simple enough
> syntax to make it easy to write a recursive descent parser for them
> but not alll.
>
> Handwritten recursive descent parsers are often LL(1) with may be
> a separate operator-precedence parsing for expressions.
>
> If you are defining a new language syntax you can make sure parsing
> is easy but not all languages are LL(1) (which is a subset of LALR(1),
> which is a subset of LR(1), which is a subset of GLR). Handwritten
> parsers for these more general grammars are bound to get more
> complicated.
>
> Even *we* understand parsing, writing a parser for some existing
> languages which grew "organically" can become tedious, or
> complicated or adhoc. Often such languages have no well specified
> grammar (the code is the specification!). A yacc grammar would help.
>
> Often one writes a yacc grammar while a new language & its syntax
> is evolving. Changing a yacc file is more localized & easier than fixing
> up a handwritten parser. Even Go has such a grammar initially.
>
> -- Bakul
>
> > On May 25, 2021, at 8:03 PM, Larry McVoy <lm@mcvoy.com> wrote:
> >
> > You do, I don't. I'm not alone in my lack of understanding.
> >
> > I think that all the things that yacc solved, Steve gets some kudos.
> > I've used it a bunch and I did not need to be as smart as you or
> > Steve to get the job done.
> >
> > You getting past that is cool but it doesn't make his work less.
> >
> > On Wed, May 26, 2021 at 10:37:45AM +1000, Rob Pike wrote:
> >> And today, we understand parsing so well we don't need yacc.
> >>
> >> -rob
> >>
> >>
> >> On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe <
> beebe@math.utah.edu>
> >> wrote:
> >>
> >>> The last article of the latest issue of the Communications of the ACM
> >>> that appeared electronically earlier today is a brief interview with
> >>> this year's ACM Turing Award winners, Al Aho and Jeff Ullman.
> >>>
> >>> The article is
> >>>
> >>> Last byte: Shaping the foundations of programming languages
> >>> https://doi.org/10.1145/3460442
> >>> Comm. ACM 64(6), 120, 119, June 2021.
> >>>
> >>> and it includes a picture of the two winners sitting on Dennis
> >>> Ritchie's couch.
> >>>
> >>> I liked this snippet from Jeff Ullman, praising fellow list member
> >>> Steve Johnson's landmark program, yacc:
> >>>
> >>>>> ...
> >>>>> At the time of the first Fortran compiler, it took several
> >>>>> person-years to write a parser. By the time yacc came around,
> >>>>> you could do it in an afternoon.
> >>>>> ...
> >>>
> >>>
> >>>
> -------------------------------------------------------------------------------
> >>> - Nelson H. F. Beebe Tel: +1 801 581 5254
> >>> -
> >>> - University of Utah FAX: +1 801 581 4148
> >>> -
> >>> - Department of Mathematics, 110 LCB Internet e-mail:
> >>> beebe@math.utah.edu -
> >>> - 155 S 1400 E RM 233 beebe@acm.org
> >>> beebe@computer.org -
> >>> - Salt Lake City, UT 84112-0090, USA URL:
> >>> http://www.math.utah.edu/~beebe/ -
> >>>
> >>>
> -------------------------------------------------------------------------------
> >>>
> >
> > --
> > ---
> > Larry McVoy lm at mcvoy.com
> http://www.mcvoy.com/lm
>
>
[-- Attachment #2: Type: text/html, Size: 5464 bytes --]
next prev parent reply other threads:[~2021-05-26 6:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-26 0:12 Nelson H. F. Beebe
2021-05-26 0:37 ` Rob Pike
2021-05-26 3:03 ` Larry McVoy
2021-05-26 4:02 ` Rob Pike
2021-05-26 6:20 ` Bakul Shah
2021-05-26 6:52 ` Rob Pike [this message]
2021-07-02 2:13 ` scj
2021-07-02 3:30 ` Rob Pike
2021-07-02 3:34 ` Rob Pike
2021-07-02 4:40 ` Rob Pike
2021-07-02 6:29 ` George Michaelson
2021-07-02 7:00 ` Bakul Shah
2021-07-02 17:17 ` [TUHS] " Tony Finch
2021-07-04 23:40 ` George Michaelson
2021-07-05 3:41 ` Bakul Shah
2021-05-26 5:13 ` [TUHS] [tuhs] " arnold
2021-05-26 4:10 ` Avindra G
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='CAKzdPgy6DnFuRwxT4_ZE3qoS5HP2Ze0=G_SXm1i7XQtNbeg_Dw@mail.gmail.com' \
--to=robpike@gmail.com \
--cc=bakul@iitbombay.org \
--cc=tuhs@minnie.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).