help-bison
[Top][All Lists]
Advanced

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

Re: Non-greedy wildcard possible? (Long)


From: Laurence Finston
Subject: Re: Non-greedy wildcard possible? (Long)
Date: Tue, 18 May 2004 13:37:05 +0200 (MEST)

On Tue, 18 May 2004, Frank Heckenbach wrote:

> Laurence Finston wrote:
>
> > I had a problem that reminds me of this.  Sometimes, one would like to
> > "get out of" a rule in `yyparse()' and "get into" another rule.  I
> > believe this to be impossible, except with `gotos', which is risky.
> > If one does it, then one must be very careful about using the semantic
> > values of the tokens of all the rules involved.  I _don't_ recommend
> > it.
>
> If you mean a `goto' from one action into another, this will
> certainly not work.


> The actions in `{ ... }' are just for the
> semantic values and irrelevant for the actual parsing.

In general, this is true.  However, in my grammar it's occasionally
necessary to "fake" tokens by causing `yylex()' to return a
particular token the next time it's called.  I suppose this is a
standard technique, but it's not described in the Bison manual.  In
these cases, the actions do influence the course of parsing.

>
> What you achieve is at best to execute a part of another semantic
> action, and at worst to mess up completely, especially if the code
> after the `goto' accesses any `$n' values. But the parsing will
> continue with the original state (it will not even notice the
> `goto'). (You could try modifying the parser's internal structures,
> but before you start this, you should really try to restructure your
> grammar or use a more powerful parsing algorithm, i.e. GLR.)
>

Yes, I meant using a `goto' to jump into the action of another
rule.  It did work.  As I said, I don't recommend it and I no longer
use it.  However, it might still be useful in some special cases.
The whole point of it was to execute a part of another
semantic action.  In the cases where I used it, the symbols on the
right-hand side of the rule were identical, so the `$n' values were
correct.  However, I don't think it would be smart to depend on this
and would use the object pointed to by the `void*' parameter to
`yyparse()' to store any values I needed in the action that I jump
into.  Since the next reduction was identical for both rules, it
didn't matter that parsing continued with the original state.  I can
see that problems would almost certainly arise if this were not the
case.

It was simply a way to avoid duplicating a fairly large amount of
code and keeping the two identical sections synchronized.  This is a
problem that has been brought up on this list before.  Bison itself
doesn't provide a way of coping with it.  It's not always convenient
to put the code into a function. In most places, I've used CWEB
sections for this purpose, however I've started to use functions
instead, where possible, despite the inconvenience.

Laurence




reply via email to

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