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: Frank Heckenbach
Subject: Re: Non-greedy wildcard possible? (Long)
Date: Tue, 18 May 2004 23:57:02 +0200
User-agent: semail 20040101

Laurence Finston 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.

That's a special case of lexer/parser interaction, where the usual
caveats WRT look-ahead (and GLR) apply.

It's not really like a `goto' between rules, since you only insert
tokens, so you cannot do arbitrary rule changes (which is a good
thing, BTW).

> > 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.

OK, so you don't change the parsing, just the action. Well, in such
cases I'd rather move the duplicate parts into a function, so I
don't need to worrry about using `$n' in dangerous ways. (And
besides, I generally prefer to do most larger stuff in functions, to
keep the grammar part small.)

> 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.

BTW, which inconvenience? I've never found any. Of course, I have to
pass `$n' as arguments as required and usually assign the result to
`$$', but that's quite simple and "looks nice"
(foo: bar baz { $$ = foo ($1, $2); };).

Frank

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




reply via email to

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