Groups | Search | Server Info | Login | Register
Groups > comp.compilers > #116
| From | Robert A Duff <bobduff@shell01.TheWorld.com> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Maintaining scope while parsing C with a YACC grammar |
| Date | 2011-05-02 20:19 -0400 |
| Organization | The World Public Access UNIX, Brookline, MA |
| Message-ID | <11-05-007@comp.compilers> (permalink) |
| References | <11-04-036@comp.compilers> <11-04-038@comp.compilers> <11-05-003@comp.compilers> |
eliben <eliben@gmail.com> writes:
> On Apr 26, 7:22 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> I strongly recommend the "build a tree" solution. It might seem like
>> a lot of trouble at first, but it will simplify things in the long
>> run.
>>
>> Do all the interesting work during a subsequent walk of the tree. Or
>> multiple walks.
>
> Since it's parsing of C I'm talking about, this approach will have to
> somehow handle ambiguity of this kind:
>
> T * x;
Right, that's what I meant by:
...except that C requires some sort of kludgery to
deal with typedefs.
in my earlier post.
> This can be either a declaration or a multiplication, depending on
> earlier symbol table information (whether T is a type or not).
>
> So are you proposing to build an ambiguous AST that contains *both*
> parses and resolve between them in later passes?
I have never seen a C parser that does that. I've seen Ada parsers
that do that (Ada has an ambiguous grammar, too). The idea is that
you create a single tree node that represents "this or that", and
during semantic analysis, you transform it into a "this" or a "that"
tree. It works well for Ada. I don't know how well it would work for
C.
The typical approach for C is to do as you say -- put typedefs in the
symbol table, and have them affect the parse (or really, the lexer).
In any case, I stand by my statement, 'I strongly recommend the "build a
tree" solution.' even for C. Defer as much as possible of semantic
analysis until after parsing, where "as much as possible" is not
necessarily "all of it".
>... Or just pick one and maybe modify it later?
That's possible, but kind of kludgy.
>...Do you have references (papers, books, etc.)
> explaining this technique?
No, sorry. I'd be interested to hear if anybody built a C parser that
didn't use any feedback into the parser from a symbol table to deal
with the typedef issue.
- Bob
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Maintaining scope while parsing C with a YACC grammar eliben <eliben@gmail.com> - 2011-04-25 05:14 -0700
Re: Maintaining scope while parsing C with a YACC grammar Robert A Duff <bobduff@shell01.TheWorld.com> - 2011-04-26 12:22 -0400
Re: Maintaining scope while parsing C with a YACC grammar Robert A Duff <bobduff@shell01.TheWorld.com> - 2011-04-26 14:08 -0400
Re: Maintaining scope while parsing C with a YACC grammar eliben <eliben@gmail.com> - 2011-04-28 23:20 -0700
Re: Maintaining scope while parsing C with a YACC grammar Robert A Duff <bobduff@shell01.TheWorld.com> - 2011-05-02 20:19 -0400
Re: Maintaining scope while parsing C with a YACC grammar "Ira Baxter" <idbaxter@semdesigns.com> - 2011-05-13 17:46 -0500
Maintaining scope while parsing C with a Yacc grammar Chris F Clark <cfc@shell01.TheWorld.com> - 2011-06-12 20:43 -0400
Re: Maintaining scope while parsing C with a YACC grammar torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-05-03 09:51 +0200
Re: Maintaining scope while parsing C with a YACC grammar Paul B Mann <paul@paulbmann.com> - 2011-05-06 10:43 -0700
csiph-web