From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1990 invoked from network); 26 May 2021 06:53:26 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 26 May 2021 06:53:26 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id F3EA19B9B7; Wed, 26 May 2021 16:53:24 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 885D29B6B4; Wed, 26 May 2021 16:53:01 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="HbNabv8u"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B07909B6B4; Wed, 26 May 2021 16:52:58 +1000 (AEST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by minnie.tuhs.org (Postfix) with ESMTPS id 671B29B654 for ; Wed, 26 May 2021 16:52:56 +1000 (AEST) Received: by mail-lj1-f175.google.com with SMTP id c15so231318ljr.7 for ; Tue, 25 May 2021 23:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YQYKBc+VrJUGZaf2gBG+dCtKfwswjAQKc8qtY81sMwM=; b=HbNabv8ux/8W3dU/gHmYcjTvIq2FHc70+hUzjzhTRHAPb0tV2mbxUMGaZNQRLlVZAh RBctx6kAXfPKYY0qylXGZ/EhMwiffxpQSuggd2fW92qdF6Di6rjH7807PcCvbnAHS3NU 0kNXP5aWhqKUBftgYDU4ewAALmmW9AZeUxD/hW28IIhgzOZp8xeWM+1V8bA3i6JW6nOI +5WSWpJ3hzZKpyk2DpWxCSjj8TBFxykHHI+OKtMlRmWH8EAG8AJ+Ha6jRdxnIgFrKFQ6 beVXEyQI5+240LLtVPCAyQjkxZp3oo1kLVqZQtT7s4bTahGlFGa3xg1L11sUXs1IoAom LjlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YQYKBc+VrJUGZaf2gBG+dCtKfwswjAQKc8qtY81sMwM=; b=fc0Yk8af55O1H98jFep3ACZsQcAa4LrwBNBT6cb67tEqbC6L+o0wnPWl2E1ExjL4DA cclI/LrTZk8xh8lqoAubpqwjcKXNQ/VigYSyhWphCT94SLWrcYhphBIQl+feOnACX+ac YM0RR9vesh/TCmHvLpNNQOI5n9QbMAOC5NEwJrbOiBIyKhKkHvHnySnOy2r+oknb0YM3 ZskvWObcctpCCeYZnFJu4cp5Q918uS4jjGlmZlAiS7wNXZBdhG5A68eeUuOGOvGjThr7 9m7cAHEHKwP1q6ih6CDAvAqGS6Z0oSxyGMTu4uG2dHc5wCRsPvX5F8yfRkd6++hrRUWv Zzjw== X-Gm-Message-State: AOAM531UgW3Q1zIf2J6YC8A33HPsEI/r5EsfsvR/QK5bRXYAyKfW7use 5Ow0v69EfrGLqYjzfXlzhea6jqfyTD/WpdIwRXCWDEpVx2Q= X-Google-Smtp-Source: ABdhPJyR9bN3LI4TktO32+U70BKENsYP70hji8B0pU9HC35mfM584OFrYld4r1Z7mxtPPNVYUfVkubmPyAYn1+o21Ns= X-Received: by 2002:a05:651c:1ad:: with SMTP id c13mr1104517ljn.38.1622011974646; Tue, 25 May 2021 23:52:54 -0700 (PDT) MIME-Version: 1.0 References: <20210526030341.GD27558@mcvoy.com> <2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org> In-Reply-To: <2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org> From: Rob Pike Date: Wed, 26 May 2021 16:52:43 +1000 Message-ID: To: Bakul Shah Content-Type: multipart/alternative; boundary="00000000000091fe6605c336175b" Subject: Re: [TUHS] [tuhs] Dennis Ritchie's couch X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000091fe6605c336175b Content-Type: text/plain; charset="UTF-8" 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 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 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 > > --00000000000091fe6605c336175b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 la= nguages 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=C2=A0 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 fixin= g
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.=C2=A0 I'm not alone in my lack of understandi= ng.
>
> 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><= br> >> wrote:
>>
>>> The last article of the latest issue of the Communications of = the ACM
>>> that appeared electronically earlier today is a brief intervie= w with
>>> this year's ACM Turing Award winners, Al Aho and Jeff Ullm= an.
>>>
>>> The article is
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Last byte: Shaping the foundations = of programming languages
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://doi.org/10.1145/34604= 42
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Comm. ACM 64(6), 120, 119, June 202= 1.
>>>
>>> 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 me= mber
>>> Steve Johnson's landmark program, yacc:
>>>
>>>>> ...
>>>>> At the time of the first Fortran compiler, it took sev= eral
>>>>> person-years to write a parser.=C2=A0 By the time yacc= came around,
>>>>> you could do it in an afternoon.
>>>>> ...
>>>
>>>
>>> --------------------------------------------------------------= -----------------
>>> - Nelson H. F. Beebe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tel: +1 801 581 5254
>>>=C2=A0 =C2=A0 -
>>> - University of Utah=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 FAX: +1 801 581 4148
>>>=C2=A0 =C2=A0 -
>>> - Department of Mathematics, 110 LCB=C2=A0 =C2=A0 Internet e-m= ail:
>>> beebe= @math.utah.edu=C2=A0 -
>>> - 155 S 1400 E RM 233=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0beebe@acm.org
>>> beebe@= computer.org -
>>> - Salt Lake City, UT 84112-0090, USA=C2=A0 =C2=A0 URL:
>>> http://www.math.utah.edu/~beebe/ -
>>>
>>> --------------------------------------------------------------= -----------------
>>>
>
> --
> ---
> Larry McVoy=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 lm at mcvoy.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0http://www.mcvoy.com/lm

--00000000000091fe6605c336175b--