This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ lexer (GCC 3.1.1) requires knowledge of other C dialects
- From: Per Bothner <per at bothner dot com>
- To: Gary Funck <gary at Intrepid dot Com>
- Cc: Gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Wed, 31 Jul 2002 23:09:51 -0700
- Subject: Re: C++ lexer (GCC 3.1.1) requires knowledge of other C dialects
- References: <KNEFLOIOCHLFEGCDNFPHMENICEAA.gary@intrepid.com>
Gary Funck wrote:
More importantly, [hard-written] parsers can be difficult to extend
> reliably. Therefore, using either parsing approach, I'd suggest that
> the resulting parser will be easier to maintain and extend if it is
> built using a parser-generator or related support/analysis tools.
Perhaps, but generated parsers may be even worse to extend. How do you
handle having a command-line flag control which parts of the grammar
to enable? Or a flag that controls how ambiguities are resolved?
Or sharing sub-grammars (like expression parsing) across different
languages?
There are tricks to solve most of these problems, but a
recursive-descent parser is just so much easier to understand, to debug,
and to handle special quirks that I much prefer it. Yes, the actual
grammar isn't as cleanly separated, and the source is slightly more
verbose, but I much prefer it.
Although C seems like a stable language, so far we've seen K&R C, ANSI C,
C++, Objective-C, C99, and perhaps soon C# (perish the thought)? It seems to
me that planning for new dialects should be an important design goal.
Yep - that's one reason recursive-descent is better.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/