bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bison version 1.875e available for testing


From: Hans Aberg
Subject: Re: Bison version 1.875e available for testing
Date: Wed, 15 Dec 2004 19:28:54 +0100
User-agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.6

At 18:48 +0100 2004/12/15, Akim Demaille wrote:
> > Akim Demaille argues that, as there are clearly such workarounds,
> > no augmenting of Bison is needed: It will just add another feature
> > to maintain.
>
>Well, there are many others to finish first.  And I would like to have
>a look at the actual code needing this feature.
>
>in this specific case, I'm not very fond of opening the guts of
>yyparse, there are many risks in there.

I am myself not thinking of it as an immediate issue. But there have here
been a couple of requests that each lead to the need of more specific code
placements.

As for the feature at hand, I think of it as writing code that is properly
localized, also in the case where there might not be an immediate need for
thread safeness. Paul Eggert evidently has rewritten the C parser so that it
is thread safe. The C++ parser is not thread safe, and should be changed.
When this localization moves ahead, I think that there will come in a
natural the need for being able to place data in the parser function.

It is probably a good idea to ask for examples before moving ahead with such
a feature, because I can think of different ways of implementing it: One
might put the action "switch" statement in an environment {...} and admit
code there, or one might admit initializers in the beginning of the yyparse
function. Each code placement probably need to have specified what data the
user can reach, like the rule actions are specified to give access to $k,
etc.

  Hans Aberg






reply via email to

[Prev in Thread] Current Thread [Next in Thread]