[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: variables in yyparse
From: |
Akim Demaille |
Subject: |
Re: variables in yyparse |
Date: |
Thu, 16 Dec 2004 18:30:07 +0100 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) |
>>> "Laurence" == Laurence Finston <address@hidden> writes:
>> Wow! This file is just incredible! I guess the C++ compiler _dies_
>> trying to compile it.
> Mine doesn't die.
I mean it must take ages to compile. A single function is tens of
thousands lines long.
>> Basically, it seems to me that all the nodes are basically the
>> same.
> I don't know what you mean.
Most actions are very similar and duplicate a lot of code.
> If `%parse-param' allows me to specify the type, then I might as well.
It does. Have a look at calc.c in the test suite, or at the
documentation of the current tarballs.
> However, I must check whether this feature is supported on the versions of
> Bison that are included in standard Linux distributions.
Why is that? Don't you ship the generated file? If not, you might
want to ship your own bison.
> I'm not that concerned about the cost of a declaration and a static
> cast, at least not if I only have to do it once instead of 914
> times.
But you pay this: twice during development, and then during execution
you lose space.
>> | ostream *out_stream_metapost
>> | = scanner_node->out[Run_State::METAPOST]->stream_ptr;
>>
>> Defined 914 times, but never used.
> I define it 914 times because it's in
> address@hidden declarations for rules@>'. It's there in case I want it.
> I may or may not remove things that I don't use in the course of
> developing my software.
OK, sorry. I was just trying to see the actual need, and pointing out
that some were artificial. But sure, you're the boss on your code.
>> Why no passing the scanner_node to cerr_message ? Overloading, or
>> another routine, but that would certainly simplify the code, and help
>> the C++ compiler.
> Because warning messages use `warning_stop_value' and passing
> `scanner_node' would give no indication of whether the user should be
> prompted to type return or not. This is known in the rule, not implicit
> in the values of the data members of `scanner_node'.
I was suggesting factoring some code via new interfaces, but ymmv and
the suggestion I made probably needs being extended.
>> Same thing with entry.
> `entry' is set in the parser rules.
I meant that entry and status are defined, but could easily be
removed.
>> - need to exchange information with the caller, and you'd better use
>> %parse-param than YYPARSE_PARAM: (i) choose the type, (ii) use it
>> several times!
> I don't yet see the advantage of using `%parse-param' over
> `YYPARSE_PARAM', except for possibly being able to remove the declaration
> of `scanner_node'. This wouldn't solve the problem of having to set
> the other variables.
I agree. This is why my bullet lists had several items, not just the
first.
> Some are just for convenience, but others, such as
> `error_stop_value' are not. I don't understand the other points.
> The type is `Scanner_Node' and I pass a different one to each
> instance of `yyparse()'.
I mean you can pass several arguments to yyparse.
>> but there is no clear need (yet!) for local variables (?)
> It's your decision.
That was my observation, but I'm discussing.
>> Maybe you'd also need a means to specify an action executed each
>> time a rule is reduced.
> Sounds good.
Back in my mind I also think about push parsers, where yyparse is
passed the token (instead of having it called yylex repeatedly). In
such a context, yyparse automatic variables don't have the same
semantics. If there is state to preserve, that should be outside.
If it's stateless, it's probably to leave in the rules themselves.
- Re: Bison version 1.875e available for testing, (continued)
- 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, 2004/12/15
- 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, Hans Aberg, 2004/12/15