Re: Maintaining scope while parsing C with a YACC grammar

Robert A Duff <bobduff@shell01.TheWorld.com>
Mon, 02 May 2011 20:19:58 -0400

          From comp.compilers

Related articles
Maintaining scope while parsing C with a YACC grammar eliben@gmail.com (eliben) (2011-04-25)
Re: Maintaining scope while parsing C with a YACC grammar bobduff@shell01.TheWorld.com (Robert A Duff) (2011-04-26)
Re: Maintaining scope while parsing C with a YACC grammar bobduff@shell01.TheWorld.com (Robert A Duff) (2011-04-26)
Re: Maintaining scope while parsing C with a YACC grammar eliben@gmail.com (eliben) (2011-04-28)
Re: Maintaining scope while parsing C with a YACC grammar bobduff@shell01.TheWorld.com (Robert A Duff) (2011-05-02)
Re: Maintaining scope while parsing C with a YACC grammar torbenm@diku.dk (2011-05-03)
Re: Maintaining scope while parsing C with a YACC grammar paul@paulbmann.com (Paul B Mann) (2011-05-06)
Re: Maintaining scope while parsing C with a YACC grammar idbaxter@semdesigns.com (Ira Baxter) (2011-05-13)
Maintaining scope while parsing C with a Yacc grammar cfc@shell01.TheWorld.com (Chris F Clark) (2011-06-12)
| List of all articles for this month |
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: Mon, 02 May 2011 20:19:58 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 11-04-036 11-04-038 11-05-003
Keywords: C, parse
Posted-Date: 04 May 2011 13:52:27 EDT

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



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.