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

[Akim Demaille]

Le 24 avr. 09 à 08:37, Joel E. Denny a écrit :

> Hi Akim,
>
> On Tue, 21 Apr 2009, Akim Demaille wrote:
>
> > Le 21 avr. 09 à 12:32, Joel E. Denny a écrit :
> >
> > > +Generate a deterministic or GLR parser employing LALR(1),  
> > > IELR(1), or\n\
> > > +canonical LR(1) parser tables.\n\
> >
> > Why not ascending order?
>
> I'm not sure what you mean.

Actually, I'm not sure either.  Forget it :)  This order is from  
coarser and smaller to finer and bigger, it's fine.

> > And shouldn't we s/GLR/generalized/ here?
>
> I see your point.  However, this blurb is sort of like a short ad for
> Bison.  If we write the following, I'm afraid people won't recognize  
> that
> Bison can generate GLR parsers:
>
> Generate a deterministic or generalized parser employing LALR(1),
> IELR(1), or canonical LR(1) parser tables.
>
> This might be better:
>
> Generate a deterministic or generalized LR parser employing LALR(1),
> IELR(1), or canonical LR(1) parser tables.
>
> And this seems clearest though most repetitive:
>
> Generate a deterministic LR or GLR parser employing LALR(1),
> IELR(1), or canonical LR(1) parser tables.
>
> Also, it occurs to me that most people have no idea what IELR is, so  
> maybe
> we should say "minimal LR" in parentheses or instead.  I don't know.
>
> 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.

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".