Re: grammar ambiguity

wclodius@aol.com (Wclodius)
21 Feb 2000 23:54:42 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: Grammar ambiguity j.coulmance@itecor.com (Jocelyn Coulmance) (2000-02-12)
Re: grammar ambiguity world!cfc@uunet.uu.net (Chris F Clark) (2000-02-12)
Re: Grammar ambiguity joachim.durchholz@halstenbach.com.or.de (Joachim Durchholz) (2000-02-12)
Re: grammar ambiguity compres@world.std.com (Chris F Clark) (2000-02-12)
Re: Grammar ambiguity cbrtjr@ix.netcom.com (Charles E. Bortle, Jr.) (2000-02-13)
Re: Grammar ambiguity j.coulmance@itecor.com (Jocelyn Coulmance) (2000-02-19)
Re: grammar ambiguity wclodius@aol.com (2000-02-21)
Re: grammar ambiguity world!cfc@uunet.uu.net (Chris F Clark) (2000-02-27)
Re: Grammar ambiguity joachim.durchholz@halstenbach.com.or.de (Joachim Durchholz) (2000-02-27)
Re: grammar ambiguity joachim.durchholz@halstenbach.com.or.de (Joachim Durchholz) (2000-02-27)
Re: Grammar ambiguity j.coulmance@itecor.com (Jocelyn Coulmance) (2000-03-03)
Grammar ambiguity ma9vk@bath.ac.uk (Vassilis Kostakos) (2000-03-06)
Re: Grammar ambiguity torbenm@diku.dk (2000-03-11)
[1 later articles]
| List of all articles for this month |

From: wclodius@aol.com (Wclodius)
Newsgroups: comp.compilers
Date: 21 Feb 2000 23:54:42 -0500
Organization: AOL http://www.aol.com
References: 00-02-051
Keywords: parse

>A different approach to extending the reach of parsers is the use of
>non-terminal lookahead. I have 3 papers by someone who researched
>that, and called the technique non-canonical LR if I recall correctly.
>The k in this technique is k non-terminals and not just k tokens.
>This technique can guarantee that the grammar is unambiguous and can
>parse grammars that are not LR(k) for any k. However, I'm not aware
>of the author ever releasing his software. We also used that
>technique in the first version of Yacc++, which we never released.
>Foolishly, we replaced the technique with the minimal state LR
>algorithm in the versions that saw the light of day.


It appears that you preferred this implementation. What were the
tradeoffs involved that led you to drop this implementation, and what
has prevented you from reimplementing it in subsequent versions of
YACC++?


William B. Clodius


Post a followup to this message

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