Bison runtime library (was: bison and i18n)

[Frank Heckenbach]

Stepan Kasal wrote:

> On Tue, May 31, 2005 at 10:07:24PM +0200, Bruno Haible wrote:
> > The drawback regarding the bison-runtime dependency would be void
> > if there is agreement to introduce a bison-runtime package _anyway_.
>
> I think this is an important point.
>
> If the bison-runtime contains only the .mo file, then many distributors
> will forget to set the dependency.
> But if we change bison so that it installs a shared library which will
> eventually be used bu the applications, then the dependency will be
> discovered automatically.
>
> Then each package using bison would use libison, if it is installed.
> If not, it would fall back to an old copy of *.c code, which wouldn't
> support localization.
>
> So it is a good idea to introduce libison and a central *.mo file
> together.  I discussed the idea in the other mail, and I think this
> is a good thing to implement in the longer run.
> But there are several questions:
> -- does the bison maintainer like my idea?
> -- if yes, who and when will find capacities to implement it.
>
> So I think 1)+libison is a good solution.
> The question is, whether 3) should be accepted as a temporary solution.
> Pro: it's ready.
> Contra: one more concept introduced; it'll confuse bison users.
>
> Bruno, you are men of action!  Perhaps you could implement libison? [1]
>       ;-)
> I don't want to annoy you, of course.  Not only the patch but also
> your analysis of the situation and its explanation is very good work.
> Thank you very much for it.

I could see another advantage of a Bison runtime library:
programming language independence.

Currently, porting Bison to support a new langauge means, among
other things, rewriting the parsing algorithm, AFAIUI. With such a
library, one would only have to interface to the library functions
which is at least one order of magnitude less work.

Of course, the parser functions must be self-contained then, not use
global variables, etc., so multiple instances will work (as the
library doesn't know whether or not it will be used in a pure
parser). But I suppose necessary global data (possibly pointers) and
perhaps callbacks could be packed into a structure which is
initialized from the language-dependent code, or something like
that.

This way, the actual parsing algorithms, wether LALR, GLR or
something new, will have to be written and maintained just once, and
will be available to all languages. (Whereas currently, e.g., in
C++, there is only a separate LALR parser and no GLR parser
available, AFAIUI.)

Unfortunately I can't volunteer to help in this area, though I'd
like to, but I currently don't have the time.

Frank

-- 
Frank Heckenbach, address@hidden
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)