|Grammar ambiguity email@example.com (Joachim Durchholz) (2000-02-05)|
|Re: Grammar ambiguity firstname.lastname@example.org (Ira D. Baxter) (2000-02-10)|
|Re: Grammar ambiguity email@example.com (Robert Sherry) (2000-02-10)|
|Re: Grammar ambiguity firstname.lastname@example.org (Jocelyn Coulmance) (2000-02-12)|
|Re: grammar ambiguity email@example.com (Chris F Clark) (2000-02-12)|
|Re: Grammar ambiguity firstname.lastname@example.org (Joachim Durchholz) (2000-02-12)|
|Re: grammar ambiguity email@example.com (Chris F Clark) (2000-02-12)|
|Re: Grammar ambiguity firstname.lastname@example.org (Charles E. Bortle, Jr.) (2000-02-13)|
|[9 later articles]|
|From:||"Ira D. Baxter" <email@example.com>|
|Date:||10 Feb 2000 01:10:27 -0500|
|Organization:||Posted via Supernews, http://www.supernews.com|
The DMS Reengineering Toolkit may offer what you need.
http://www.semdesigns.com/Products/DMS/DMSToolkit.html. It come
equipped with a GLR parser generator, so it can parse languages with
local ambiguities (even unbounded lookahead). A nice property of GLR
grammars is that it takes very little effort to get a "reference"
grammar to act as a useful parser. As an example, we put the
Fortran90 grammar almost directly into DMS, in spite of considerably
ambiguities present in expressions with respect to element accesses.
The parser generator tool itself has a built-in heuristic ambiguity
checker; it attempts to find terminal strings leading to ambiguous
>In summary: Are there parser generators available that cover more than
>just LALR, and where the effort to tweak language syntax to a form
>that the generator will accept is so straightforward that I can easily
>infer whether the rewritten and the original syntax are still the same
>I don't have my hopes too far up, but I wanted to ask before giving
Return to the
Search the comp.compilers archives again.