Re: several messages

[Joel E. Denny]

Hi Akim.

On Wed, 2 Sep 2009, Akim Demaille wrote:

> I played with canonical-lr, but it is way too expensive for me, both in terms
> of size, and duration of compilation (maybe in a release mode, but...).

By compilation, you mean gcc?  Or is bison slow?

> But
> toying with lr.default-reductions (still in lalr) gives very good results.
> 
> I have 382 LR(0) states, and 12941 is canonical LR(1).

That's quite a jump.  I usually see only one more digit.  There must be 
many similar contexts within your grammar.  What does IELR(1) give you?  
How long does bison take to run for IELR(1) versus LALR(1)?

> Here are the size of the parser files.
> 
> address@hidden ~/src/gnet/kernel $ ls -l _build/*/ugrammar.cc
> 12:40:05
> -rw-r--r--  1 akim  akim   321287 Sep  2 12:10 _build/accepting/ugrammar.cc
> -rw-r--r--  1 akim  akim   170357 Sep  2 12:13 _build/all/ugrammar.cc
> -rw-r--r--  1 akim  akim  8913314 Sep  2 11:52 _build/canonical-lr/ugrammar.cc
> -rw-r--r--  1 akim  akim   263165 Sep  2 12:06 _build/consistent/ugrammar.cc

It's interesting that each value for lr.default-reductions has a 
significant impact on size, but at least it's not orders of magnitude as 
for canonical LR.

> The syntax error on "1 1" behaves as expected with both accepting and
> consistent (i.e., mute since there are too many possibilities ;).

If you could unmute it (by adding a few more possibilities in the 
skeleton), it would be interesting to see if canonical LR gives the same 
expected tokens list.

> So I will proceed with default-reductions=all on space-starving targets (on
> which anyway I use simple error messages to get rid of the tables), and
> "accepting" otherwise.

Why not "consistent"?  For error messages, I don't know of any reason to 
expect either to typically be better than the other.  But "consistent" 
produces the traditional Yacc behavior (actually defined in POSIX) of not 
requesting a token from yylex until necessary.  This can affect semantic 
actions.

The only reason I made canonical LR choose "accepting" by default is 
because I think of that as being the canonical form.

> The documentation for error-verbose should probably
> promote the use of accepting/consistent.

They can sometimes worsen the error messages.  That is, in some cases, 
lookahead merging might produce worse effects on the expected list in the 
state containing the default reduction than is produced by performing the 
default reduction.  For example, consider the input "aaz" for this 
grammar:

  %token 'z';
  S: 'a' A 'a'
   | 'b' A B
   ;
  A: 'a' ;
  B: 'a' | 'b' | 'c' | 'd' ;

With lr.type=canonical-lr or lr.type=lalr:

  syntax error, unexpected 'z', expecting 'a'

But with lr.type=lalr and lr.default-reductions=accepting:

  syntax error, unexpected 'z', expecting 'a' or 'b' or 'c' or 'd'

If we add:

  %left 'a';
  A: 'a' 'a';

Then lr.default-reductions=consistent has the same problem.

My suspicion would have been that disabling default reductions almost 
always does more good than harm, but I think we need more exploration.

On Wed, 2 Sep 2009, Akim Demaille wrote:

> Le 27 août 09 à 00:21, Joel E. Denny a écrit :
> 
> > Thanks for mentioning that.  I meant to address it, but I fell down a
> > different rabbit hole and forgot.
> > [...]
> 
> Your explanations are crystal clear.  It's a very nice basis to address the
> following points:
> 
> > I really need to rewrite the lr.default-reductions and lr.type
> > documentation.  A cross-reference from %error-verbose would be nice.
> > I'll try to get to that before the 2.5 release.
> 
> Thanks for taking the time to analyse this!

Thanks for sharing your results!

> > > Maybe that would also explain my incorrect
> > > messages in the nearby thread about semantic error messages.
> > 
> > I skimmed that, and I would guess that you need canonical LR.  I haven't
> > explored your grammar yet though.
> 
> I don't think you have the grammar I was referring too, or maybe an old
> version of it.

For some reason, I thought you meant the calc++ example grammar, so that's 
what I looked at.