From: eliben Newsgroups: comp.compilers Subject: Re: Maintaining scope while parsing C with a YACC grammar Date: Thu, 28 Apr 2011 23:20:09 -0700 (PDT) Organization: Compilers Central Lines: 34 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-05-003@comp.compilers> References: <11-04-036@comp.compilers> <11-04-038@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: gal.iecc.com 1304311773 43457 64.57.183.58 (2 May 2011 04:49:33 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Mon, 2 May 2011 04:49:33 +0000 (UTC) Keywords: C, parse Posted-Date: 02 May 2011 00:49:33 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.dougwise.org!feed.ac-versailles.fr!usenet-fr.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!news.glorb.com!usenet.stanford.edu!news.iecc.com!nerds-end Xref: x330-a1.tempe.blueboxinc.net comp.compilers:112 On Apr 26, 7:22 pm, Robert A Duff wrote: > eliben writes: > > [There's a couple of possibilities. One is to add separate rules for > > the open and close braces with action code that increments and > > decrements the nesting level, so you know when you reduce the > > declaration what scope it is in. Another is to parse the whole thing > > into an AST without trying to interpret the symbols other than making > > pointers to a generic symbol table entry per name, then walk the AST > > and add the scope and type info. Perhaps people will have other > > suggestions. -John] > > 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; 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? Or just pick one and maybe modify it later? Do you have references (papers, books, etc.) explaining this technique? Thanks in advance