Re: too many gotos

[Hans Aberg]

on 2004/10/25 18:26, Paul Eggert at address@hidden wrote:

> Akim Demaille <address@hidden> writes:
> 
>> Well, are you serious?  Can you possibly imagine a (real life) grammar
>> exceeding our new boundary?
> 
> Not one generated by hand, no.  But an automatically-generated grammar could.

If one assumes that Bison will support an LR(1) option in the future, one
will need to knock a factor of a few thousand more states in order to break
the 32-bit limit relative the grammars that now is breaking the 16-bit
limit. It will probably be best to use 64-bits on 64-bit machines, for the
sake of speed.

>> I'm not sure there remain many arbitrary limits.
> 
> It depends on what you mean by "arbitrary limits", but if we're
> talking about arbitrarily limiting ourselves to 32-bit sizes even on
> 64-bit hosts, then there are many instances of this in Bison.
> 
> Spurred by your patch, I started on a patch to fix just the problems
> related to goto numbers but haven't had the time to finish it yet.
> Perhaps later this week.  Here's the first one in the partial patch
> I've written, to give you a feeling for what's involved.
> 
> --- src/lalr.c  22 Oct 2004 23:08:33 -0000      1.99
> +++ src/lalr.c  25 Oct 2004 16:19:00 -0000
> @@ -98,7 +98,7 @@ set_goto_map (void)
> }
> 
> {
> -    int k = 0;
> +    goto_number k = 0;
> int i;
> for (i = ntokens; i < nsyms; i++)
> {
> 
> There are lots more fixes like this: token numbers, symbol numbers,
> etc., etc.

And the number "i" above. :-)

>  To some extent this is just busy work as the limits will
> never be reached in ordinary handwritten grammars; but to some extent
> identifying which integers mean what will be a useful improvement to
> Bison, for maintenance purposes.

Just so. I do such changes in my own parser (a theorem prover), when I have
the effort. It really helps up the redability of the code (as the program is
very complex).