10 Mar
2025
10 Mar
'25
3:24 p.m.
On Mon, Mar 10, 2025 at 11:13 AM Clem Cole <clemc(a)ccc.com> wrote:
On Sun, Mar 9, 2025 at 10:03 PM Douglas McIlroy
<douglas.mcilroy(a)dartmouth.edu> wrote:
Funny, I agree with both of you, and with Rob. :-)
If I'm not mistaken, I think what Doug was suggesting was that, to
really understand what YACC is _doing_ requires understanding a lot
more about the theory of parsing, grammars, and so on, than one needs
to understand to write a fairly simple RD parser. RD makes a lot of
sense intuitively, but once you introduce table-driven parsing,
LALR(1), etc, you get into a whole different level of theory and
rigor. Of course, by design the tool abstracts that away from you, so
to just _use_ it you don't necessarily need to understand as much.
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.
I disagree here. I have wtchged too many young programmers that I realized did not
understand what yacc was doing and came to understanding that never built a simple parse
before. [...]
The interesting thing is while I tend to use yacc for most parsers, I've found
myself building recursive descent parsers in a couple of cases where it seems to make
better sense.
Funny, I'm the opposite: I've used YACC for a few parsers, but prefer
to roll my own. I find that I'm either parsing something very simple,
in which case reaching for YACC feels like cutting butter with a
chainsaw, or I need to do something that YACC isn't super great at
(like run in a multithreaded environment). YACC is superb at what it
does, but not something I feel like I need that often.
- Dan C.