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) |
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
Return to the
comp.compilers page.
Search the
comp.compilers archives again.