[Top][All Lists]
[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."