Re: Non-greedy wildcard possible? (Long)

[Laurence Finston]

On Tue, 18 May 2004, Frank Heckenbach wrote:

> Laurence Finston wrote:
>
> > > 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).
>

I didn't mean to imply that it was, it's a separate issue.  When I
first started using Bison, I sometimes _wanted_ to jump from one rule
to another, but with time I've developed a better feel for working
with it.

> > 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); };).
>

Passing the strings for debugging and/or error output
can be a bit inconvenient.  I also have the cost of a function call,
which seems to me to be too expensive, if the function doesn't contain
much code.
If I want to return more than one value to the rule, then I either
have to define a `class' to contain the values, if I haven't already
defined an appropriate one, or pass pointers (or references) as
additional arguments for storing the values.  (I can't use global
variables because of race conditions).

On the other hand, I think I'm only about half-way through coding my
parser and it's already quite long, and compilation takes long enough
so that I get bored waiting for it to finish.  Inlining the
functions or using CWEB sections can cause a significant increase in the
size of the code compared with using (non-inlined) functions.

Since 3DLDF is a 3D-graphics application, and I'd like it to be
a real-time application someday, the choice between these alternatives
is significant, and not just an academic exercise.

Laurence