Re: [Opencxx-users] parse error on valid code

[Shigeru C. <ch...@is...>]

From: Stefan Seefeld <se...@sy...>
Subject: Re: [Opencxx-users] parse error on valid code
Date: Mon, 26 Jul 2004 19:00:12 -0400

> > Since the parser of OpenC++ is LL(k) --- a backtracking parser ---,
> > the token analyzer allows the parser to look up several tokens in
> > advance.  The parser can read several tokens and rewind back to
> > several tokens before.  If the rewinding happens, maybe TypeResolver
> > must also discard some recorded type names to distinguish duplicated
> > type declarations from revisited type declarations.  Therefore,
> > TypeResolver must work with not only Parser but also TokenAnalyzer.
> 
> I thought that new types would only be registered to the TypeResolver
> when the parser can confirm that what it is looking at is indeed a type,
> and not an expression. That would mean that while arbitrary 'look ahead' is
> required, tokens wouldn't be consumed until all ambiguities are resolved
> for the current token sequence, and thus, all type instantiations are
> final.

Yes, in theory!  But due to the complexity of the C++ grammar, the
OpenC++ parser sometime backtracks in a complex way.  So please be
careful although I don't think it's difficult.

> By the way: what is a TokenAnalyzer ? How is it related to Lexer and Parser ?

Ah, I mean Lexer.

> > I'm now remembering my desing decision.  GCC used a LR(1) parser,
> > i.e. bison parser (I don't know whether or not gcc3 still uses bison).
> 
> no, gcc 3.4 has a completely (manually) rewritten parser for C++.

I see.  I don't know today's fashion but using a bison/yacc for
writing a compiler such as gcc 2 (not 3!) was a right decison untill
mid 1990s, in which the C++ grammar had been extended beyond LR(1).

Chiba