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

[Gabriel D. R. <gd...@in...>]

Shigeru Chiba <ch...@is...> writes:

| 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).

All GCC-3.x.y, x < 4, do.  GCC-3.4.x use a handwirtten recursive
descent parser.

| 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,

Agreed.  That is extensively discussed in "Design and Evolution of C++".

| a C++ parser based on LR(1) needs a table of type names.  However,

I think even a LL(k) parser needs such thing.

| 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.

Pardon my ignorance, but:  Did you really handle full C++ (at the
time), or a specific subset.  The reason I'm asking is that if you do
not know which names are type-names, e.g.

    f(a);

?

| 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.

-- Gaby