Re: Maintaining scope while parsing C with a YACC grammar

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

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