Re: parsing ISO C++(1998/2003)

"Ira Baxter" <idbaxter@semdesigns.com>
28 Apr 2007 23:29:03 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: parsing ISO C++(1998/2003) ang.usenet@gmail.com (Aaron Gray) (2007-04-23)
Re: parsing ISO C++(1998/2003) haberg@math.su.se (2007-04-23)
Re: parsing ISO C++(1998/2003) idbaxter@semdesigns.com (Ira Baxter) (2007-04-26)
Re: parsing ISO C++(1998/2003) torbenm@app-7.diku.dk (2007-04-26)
Re: parsing ISO C++(1998/2003) ang.usenet@gmail.com (Aaron Gray) (2007-04-27)
Re: parsing ISO C++(1998/2003) ang.usenet@gmail.com (Aaron Gray) (2007-04-27)
Re: parsing ISO C++(1998/2003) idbaxter@semdesigns.com (Ira Baxter) (2007-04-28)
Re: parsing ISO C++(1998/2003) idbaxter@semdesigns.com (Ira Baxter) (2007-04-28)
Re: parsing ISO C++(1998/2003) idbaxter@semdesigns.com (Ira Baxter) (2007-04-28)
| List of all articles for this month |
From: "Ira Baxter" <idbaxter@semdesigns.com>
Newsgroups: comp.compilers
Date: 28 Apr 2007 23:29:03 -0400
Organization: NewsGuy - Unlimited Usenet $19.95
References: 07-04-052 07-04-059 07-04-069 07-04-085 07-04-110
Keywords: C++, parse
Posted-Date: 28 Apr 2007 23:29:03 EDT

"Torben Ęgidius Mogensen" <torbenm@app-7.diku.dk> wrote in message
> "Aaron Gray" <ang.usenet@gmail.com> writes:
>
> GLR parsers are able to parse ambiguous grammars, so this is trivially
> true. What you need, however, is a way to choose which one of the
> many parse trees that the GLR parser gives you that you want, and I
> can see no way of getting this automatically -- unless you can
> formally specify disambiguation rules (such as operator precedence
> rules). Operator precendence rules are insufficient to make the C++
> grammar unambiguous, though.


In DMS, we solve this problem by building attribute grammars that
evaluate the (ambiguous) parse tree to do name and type resolution,
including operator precedence evaluation; this builds a scoped symbol
table as a side effect. A special operator in our attribute grammar
declares the "current" computation to be in error; this is invoked
when there is some inconsistency in type declarations and actual
usage. Our attribute grammar evaluator engine deletes any subtree in
which such an error occurs. The remaining trees are not inconsistent,
and in fact if you encode all the C++ type resolution rules, the
resulting tree doesn't have any ambiguities.


So the extraction of the "right" parse trees occurs automatically in
one sense. Somebody still has to encode the C++ rules to detect the
wrong cases. That's quite a lot of effort, that we've already done.


--
Ira Baxter, CTO
www.semanticdesigns.com


Post a followup to this message

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