[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison version 1.875e available for testing
From: |
Laurence Finston |
Subject: |
Re: Bison version 1.875e available for testing |
Date: |
Wed, 15 Dec 2004 17:41:47 +0100 (MET) |
On Wed, 15 Dec 2004, Akim Demaille wrote:
> >>> "Laurence" == Laurence Finston <address@hidden> writes:
>
> > On Wed, 15 Dec 2004, Akim Demaille wrote:
> >> >>> "Laurence" == Laurence Finston <address@hidden> writes:
> >>
> >> > Does this make it possible to declare local automatic
> >> > variables in `yyparse()'?
> >>
> >> Nope. To a similar end you are expected to use %parse-param.
> >>
>
> > That's what I do. The CWEB section
> > address@hidden declarations for rules@>' contains code that extracts the
> > values from the parameter. It just seems a bit wasteful to do this in
> > every rule, as well as cluttering up my code.
>
> I don't understand what you mean with "every rule". Automatic
> variables in yyparse are for a whole parse, just as arguments given to
> %parse-param.
>
Perhaps I've misunderstood what you mean by `%parse-param', and I haven't
looked it up. I generate a reentrant parser and make use of the ability
to pass an object by means of a `void*' to `yyparse()'. I use a unique
object for each call to `yyparse()' so I can use the data members of that
object in lieu of local automatic variables in `yyparse()'.
> > For non-threaded applications it would suffice to use static
> > variables local to the compilation unit for `yyparse()', but this
> > won't work with threads.
>
> Why is that? It is up to you to pass to yyparse references to
> automatic variables from its caller. So I fail to see what actual
> difference it would make.
>
Because if they're static, there will only be one for all instances of
`yyparse()' instead of a separate one for each instance. I don't
understand what you mean by passing references to automatic variables to
`yyparse()' from its caller. What I'd like are automatic variables local
to `yyparse()', which cannot be referenced from outside `yyparse()'.
Laurence
- Re: undefining YYRHSLOC in the GLR parser, (continued)
- Re: undefining YYRHSLOC in the GLR parser, Paul Eggert, 2004/12/12
- Re: undefining YYRHSLOC in the GLR parser, Frank Heckenbach, 2004/12/12
- Re: undefining YYRHSLOC in the GLR parser, Paul Eggert, 2004/12/13
- Re: undefining YYRHSLOC in the GLR parser, Frank Heckenbach, 2004/12/14
- Re: undefining YYRHSLOC in the GLR parser, Paul Eggert, 2004/12/14
- Re: undefining YYRHSLOC in the GLR parser, Frank Heckenbach, 2004/12/15
Re: Bison version 1.875e available for testing, Laurence Finston, 2004/12/11
- Re: Bison version 1.875e available for testing, Akim Demaille, 2004/12/15
- Re: Bison version 1.875e available for testing, Laurence Finston, 2004/12/15
- Re: Bison version 1.875e available for testing, Akim Demaille, 2004/12/15
- Re: Bison version 1.875e available for testing,
Laurence Finston <=
- Re: Bison version 1.875e available for testing, Akim Demaille, 2004/12/15
- Re: Bison version 1.875e available for testing, Kelly Leahy, 2004/12/15
- Re: Bison version 1.875e available for testing, Laurence Finston, 2004/12/15
Re: Bison version 1.875e available for testing, Hans Aberg, 2004/12/15
- Re: Bison version 1.875e available for testing, Akim Demaille, 2004/12/15
- Re: Bison version 1.875e available for testing, Laurence Finston, 2004/12/15
- Message not available
- Message not available
- Message not available
- Re: variables in yyparse (Was: Bison version 1.875e available for testing), Laurence Finston, 2004/12/16
- Re: variables in yyparse, Akim Demaille, 2004/12/16
- Re: variables in yyparse, Laurence Finston, 2004/12/16
- Re: variables in yyparse, Hans Aberg, 2004/12/18