Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin3!goblin.stu.neva.ru!rahul.net!wasp.rahul.net!rahul.net!news.misty.com!news.iecc.com!nerds-end From: Robert A Duff Newsgroups: comp.compilers Subject: Re: Maintaining scope while parsing C with a YACC grammar Date: Mon, 02 May 2011 20:19:58 -0400 Organization: The World Public Access UNIX, Brookline, MA Lines: 57 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-05-007@comp.compilers> References: <11-04-036@comp.compilers> <11-04-038@comp.compilers> <11-05-003@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: gal.iecc.com 1304531548 3139 64.57.183.58 (4 May 2011 17:52:28 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 4 May 2011 17:52:28 +0000 (UTC) Keywords: C, parse Posted-Date: 04 May 2011 13:52:27 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:116 eliben writes: > On Apr 26, 7:22 pm, Robert A Duff > 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