Re: Bison and LR(1) Parsers

[Tim_Josling]

Thanks Hans,

By the way - there is a bug on the bison web page - the person listed as
maintainer denies being the maintainer any more.

Who is the official maintainer?

All your comments make sense. I am just about to go off and get a copy fo the
Fortes paper. I did a search and he doesn't seem to have patented it though
there are patents in the LR parser space, notably from IBM.

I will await an official verdict before writing anything.

The bison.simple also puts out some warnings when run with gcc in pedantic mode
- comparison of "signed and unsigned". Would someone like a patch for this? I
have already patched the version on my system as I build gcc all the time and
the messages annoyed me.

I also have another question - is there anywhere I can download the latest cvs
version or whatever? I don't want to make a lot of patches to an obsolete
version.

Tim Josling


"Not a GNU official myself, I can nevertheless report on some discussions on
a similar topic that I happened to take part of:

Carlos Borges already asked to implement an option for the DR
("discriminating reverse") LR(1) developed by Jose Fortes, and it was
preliminary agreed to make a %... option put in the .y file by which this
algorithm can be selected, but otherwise keep it as similar as possible to
the old Bison parser with respect to other features. Richard Stallman
<address@hidden> also said that "it ought to be possible to use the same input
format for a whole range of different kinds of grammar algorithms", so it
should be a go ahaead for implementing such algorithms.

So if you already have a LR(1) grammar implementation, I suggest you to
make a Bison % ... option for selecting that, and then one can see how well
that experimental version is. Then it might be possible to decide for
future support.

  Hans "


10:32 +1000 2001/07/02, address@hidden wrote:
>I am having troubles with the limitations of LALR(1) which bison implements.
...
>Having an LR(1) parser would solve this problem for me. The state table is
>a >lot larger but with modern CPUs this need not be a show stopper -
>provided it >is an option not mandatory.
...
>My question to you as the maintainer of bison is would you in principle accept
>patches that would
>
>- not change default behaviour
>- add an option to produce an LR(1) parser
>- provide all needed documentation updates to reflefct the code changes
>- conform to the FSF coding standards and not mess up the code
>
>I have an FSF copyright assignment in place already.