bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Document %define lr.type and lr.default_rules.


From: Joel E. Denny
Subject: Re: [PATCH] Document %define lr.type and lr.default_rules.
Date: Wed, 6 May 2009 16:05:36 -0400 (EDT)

Hi Akim,

On Wed, 6 May 2009, Akim Demaille wrote:

> > Generate a deterministic LR or GLR parser employing LALR(1),
> > IELR(1), or canonical LR(1) parser tables.

> > What do you think?
> 
> I regret that we don't explicit the "generalized" word, but I see your point
> too. Yet I would say that if the reader is not expected to understand
> "generalized", he will probably not understand "canonical" either.

I'm not sure about that.  It is not clear to me that a "generalized 
parser" or even a "generalized shift/reduce parser" necessarily employs 
the GLR algorithm.  For example, backtracking is another way to generalize 
LR.  However, the meaning of "canonical" from English (the sense of 
"classic" or "standard") alone seems sufficient to convey the meaning of 
"canonical" in "canonical LR".

> We may also escape the LR repetition with "generate a deterministic or
> generalized shift/reduce parser employing LALR(1), IELR(1) or LR(1) parser
> tables".

Googling/grepping for "GLR" or "canonical LR" would not return a hit for 
this sentence.  That loss bothers me more than repetition of "LR".  What 
about the following?

"Generate a GLR (generalized LR) or deterministic shift/reduce parser 
employing LALR(1), IELR(1) or canonical LR(1) parser tables."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]