Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end From: AD Newsgroups: comp.compilers Subject: type or identifier fundamental parsing issue - Need help from parsing experts Date: Tue, 3 Jul 2012 11:30:48 -0700 (PDT) Organization: Compilers Central Lines: 33 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-07-004@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1341369148 99699 64.57.183.58 (4 Jul 2012 02:32:28 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 4 Jul 2012 02:32:28 +0000 (UTC) Keywords: parse, types, design, question Posted-Date: 03 Jul 2012 22:32:28 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:704 Greetings All, I am dealing with a programming langauge that supports something like sizeof() as well as sizeof() expression. For parsing such a construct, one would need a parser/yacc rule somewhat like the following: SIZEOF_KEYWORD '(' IDENTIFIER ')' The fundamemtal problem in the rules of the language (that I am dealing with) is that its lookup/resolution rule *doesn't* allow me to check in symbol table if that 'IDENTIFIER' is a type or non-type variable. Problem is, this language supports certain constructs which can potentially/later make such early lookup/resolution decisions wrong. In short, name resolutions in this langauge (as per the langauge definition) can only be initiated after the entire source code has been completely parsed/seen. Given this restriction, I will probably have to delay/defer the decision of, whether we saw a 'type' or a non-type variable (with the 'sizeof' operator) to "semantic check phase". On the other hand, some people/experts believe that such decisions of whether something is a type or non-type idernfier has to be frozen/finished during parsing and *SHOULD NOT* be deferred/delayed to 'semantic check phase'. I am not an expert compiler researcher/scientist, so am seeking some opinion here, if you happen to have a sound knowledge on this issue. Many thanks. Regards, AD