Re: Faster token table lookups

[Hans Aberg]

At 11:42 +0100 0-12-22, Akim Demaille wrote:
>I won't look at it before January.

I though I should give you something to do during the Christmas
holidays.... :-)

>  Are you sure it is worth the
>trouble?

You should have told me before writing the patch...

> My opinion is that 1. nobody uses those tables to parse, and
>2. those who do certainly process these tables before using them.

Isn't there a contradiction here? :-) (Those that do not use the tables
processes them before using them.)

>  Let
>it be for bsearch or some other method they might want to use.

Well, if one should somehow use it, I think I implemented the fastest one,
so there would be no point for any other to implement something else.

Otherwise, for the usability, I have no idea. :-)

One use is to diminish the cluttering of the namespaces. I use three Bison
invokations, and I worry a little with name conflicts with Flex which
defines start-condition macros).

Also, I use Flex reading Bison's header, which means that the Flex file
must be recompiled every time the Bison file is used, which could be
avoided using those functions.

And if one somehow wants to have a lexer that produces type-codes
dynamically, one could use these functions.

Otherwise, I have no idea; it is a feature mentioned in the manual, sec.
4.2.1, and I got curios about it. The reason for using macros alone is
speed, but the question is how much this dynamical variation slows down it:
If it is not too much, one could just as well use that version. (Computers
have improved a lot since the original code was written, so more dynamic
stuff is permissible nowadays.)

So if somebody is interested in experimenting with the approach, you got
the code.

>I think it is not
>relative to the current state of CVS Bison since I think I saw fguard
>which no longer exists.

Right. I have been busy using Bison, so have not had time using the latest
version (as I would have to patch it up for the MacOS CW IDE plugin that I
use). -- Just replace "fguard" with whatever you put the output.

  Hans Aberg