From: "John Levine" <johnl@taugh.com>
To: tuhs@tuhs.org
Subject: [TUHS] Re: parsing tools, was What would early alternatives
Date: 12 Mar 2025 01:36:09 -0000 [thread overview]
Message-ID: <vqqoe9$2vd1$1@gal.iecc.com> (raw)
In-Reply-To: <CAKzdPgyJ4yoSjJG5XsrUEMexqd2-hSvmU9=5p88DSsQpEVW7TA@mail.gmail.com> <CAOkr1zWofLGga8v-m6V4=c+U-sYHHp-3=3OVrzyg47mk8caoRA@mail.gmail.com> <CAKH6PiW8J8=uFbadUTSaC9VcLGUJMFZaSFWOFDyCM3MpMTSayw@mail.gmail.com <CAMP=X_mchJuVgdpc4-AYHASwEVzUcJXMmqSDv_UvX6y0o0+LBQ@mail.gmail.com>
According to Ken Thompson <kenbob@gmail.com>:
>-=-=-=-=-=-
>
>i find that SD and yacc have about the same
>time performance. yacc gets a bad rep when
>it uses lex as its front-end. then it is pig-slow.
Parsing is never a performance issue since its time is generally O(n)
where n is the number of tokens emitted by the lexer and the constant
is not large. The lexer always is because it's the only part of the
compiler that has to look at every input character separately. If a
compiler does a lot of optimization, the analysis for that can be
slow, too.
Lex was a dog. Flex, which as far as I know was a complete rewrite
that shared no code with lex, are not bad.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
next prev parent reply other threads:[~2025-03-12 1:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-10 2:03 [TUHS] Re: What would early alternatives to C have been? 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
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 ` John Levine [this message]
2025-03-12 2:22 ` [TUHS] Re: parsing tools, was What would early alternatives 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
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='vqqoe9$2vd1$1@gal.iecc.com' \
--to=johnl@taugh.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).