Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Kaz Kylheku <480-992-1380@kylheku.com> Newsgroups: comp.compilers Subject: Re: Are compiler developers light-years ahead of other software development? Date: Sat, 22 Jan 2022 21:22:31 -0000 (UTC) Organization: A noiseless patient Spider Lines: 49 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-01-094@comp.compilers> References: <22-01-059@comp.compilers> <22-01-083@comp.compilers> <22-01-090@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="73060"; mail-complaints-to="abuse@iecc.com" Keywords: parse, practice Posted-Date: 22 Jan 2022 18:50:34 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2859 On 2022-01-22, Roger L Costello wrote: > Kaz Kylheku wrote this about the C++ compiler: > >> In other words, a major compiler for probably >> the programming language with the most >> complicated syntax ever, eschews pretty much >> all that we have learned and accumulated about >> parsing between around 1968 and now. > > Yikes! > > They ignored the rich theory and vast set of algorithms, in favor of > their own proprietary code? Why would the C++ compiler developers do > such a thing? Wild guess: Suppose that there is a foo_statement which contains a bar_designator, and something is wrong in there. They can fire up gdb, and put a simple breakpoint on bar_designator, feed in the test case and get a call stack in which parse_bar_designator is called by parse_foo_statement. They can examine all the locals, and arguments up the stack. Typically, nothing like this is easily possible with the theoretically-based parser generation tools. And in C++, you're likely going to be debugging parsing quite a bit. The main parser generation tools used by GNU projects are Flex and Bison. These tools are moving targets; especially Bison. The common practice is to ship the generated parser. (In a fundamental compiler project, you have to for other reasons, like the users not having thta tool installed, because maybe they need your compiler to build it: you want as few dependencies as possible.) Now GCC is hacked on quite a bit and has lots of contributors. It would be annoying to tell people "Oh, just use the generated, shipped parsers if you're not touching the grammar; if you need to regenerate, please use the exact version Bison X.Y.Z.". If a parser is hand-written, that whole sort of problem goes away. > /Roger > [My guess is that they were too busy chopping down trees to sharpen their axes. -John] -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal