"You can still put it into the parser function, so that it is global
to the parser, but not the parser function. But try putting in the
first rule."
I'm sorry, but I don't understand your last comment very well. did
you really mean this:
"...so that it is global to the parser function, but not the
[whole] parser."
Does that mean I'll edit the yacc.m4 file (which I'm doing already)?
What do you mean by "try putting in the first rule"
On 11/22/06, Hans Aberg <address@hidden> wrote: You can still
put it into the parser function, so that it is global
to the parser, but not the parser function. But try putting in the
first rule.
Hans Aberg
On 22 Nov 2006, at 20:23, vlad florentino wrote:
> I guess the global variable is the best choice, then. I was trying
> to avoid global variables because I was hoping the make the parser
> reentrant. I guess that's out the window.
>
> Thanks for the help.
>
>
> On 11/22/06, Hans Aberg <address@hidden> wrote: On 22 Nov 2006,
> at 19:41, vlad florentino wrote:
>
> > In gnu bison:
> >
> > I have a couple of productions of this type:
> > ID '.' complex
> > : {...}
> > ;
> >
> > complex
> > : FOOBAR {...}
> > ;
> >
> > How can I pass the value of ID, a terminal, down to the production
> > 'complex', a non terminal. I would like to determine what's the
> > value of ID
> > and take actions based on that, i.e.:
> > complex
> > : FOOBAR
> > {
> > if( strcmp(ID.value,"this") == 0)
> > doThis();
> > else
> > doThat();
> > }
>
> You can't within the parser itself, as it is a bottom-up parser; so
> some trick is needed. So either use variable global to the
parser, or
> write it in the action of the first rule you have above (using $1).
> You might also attempt using negative $k numbers (perhaps $-1 in
your
> case), but that is tricky: for one, thing, it will break if you
> variable "complex" is used in some other context.
>
> Hans Aberg
>
>
>