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

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

No, my point is not an issue of OO design.  It is of parsing algorithm.

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'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).
However, I didn't think that LR(1) is appropriate for C++ or that C++
grammar can be parsed by a pure LR(1) parser.  As we are talking now,
a C++ parser based on LR(1) needs a table of type names.  However,
writing a LR(1) grammar that can maintain such a type-name table is a
really messy job.  So, as far as I remember, the parser of GCC does
not do this job but the token analyzer of GCC does although the code
of the token analyzer of GCC is still complicated.

So my solution when I wrote OpenC++ was to write a LL(k) parser, which
is a LL parser that may perform backtracking.  Then, since LL(k)
parser is really powerful, a LL(k) parser does not need to maintain a
type-name table for parsing the C++ grammar at that time.  That's why
the OpenC++ parser does not maintain a type-name table.

Now, almost 10 years have been passed.  Sure, a LL(k) parser needs a
type-name table for parsing the current grammar of C++.  So I agree to
implement a type-name table but please note that the OpenC++ parser
may backtrack.  So the type-name table must be aware of that
backtracking.

Chiba

From: Grzegorz Jakacki <ja...@ac...>
Subject: Re: [Opencxx-users] parse error on valid code
Date: Thu, 22 Jul 2004 07:41:13 +0800

> > So now I must say that I cannot remember why I chose the approach
> > currently used in OpenC++.  However, there should be some examples in
> > which the lexical analyzer must help the parser to record all the
> > declared type names etc.  Thus, as far as I remember, the code of the
> > lexical analyzer of gcc 2.x(?) was quite tangled with the code of the
> > parser.  I didn't like to make the OpenC++ code tangled.  Hope this info
> > helps you guys.  I think the parser needs to maintain the type name
> > table for completely supporting templates.
> 
> I think we can keep the OpenC++ parser clean with this design:
> 
>                  <<iface>>
> +--------+     +--------------+
> | Parser |---->| TypeResolver |
> +--------+     +--------------+
> 
> Where TypeResolver instance provides all the functionality requiring
> maintaining the type name table. Perhaps ClassWalker or Environment can
> be made an implementation of TypeResolver. That way code would stay not
> tangled (i.e. Parser still does not implement type name table, nor does
> it depend on concrete classes from the next layers, like Environment or
> ClassWalker).