[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: variables in yyparse (Was: Bison version 1.875e available for testin

From: Laurence Finston
Subject: Re: variables in yyparse (Was: Bison version 1.875e available for testing)
Date: Thu, 16 Dec 2004 16:43:18 +0100 (MET)

On Thu, 16 Dec 2004, Akim Demaille wrote:

> >>> "Laurence" == Laurence Finston <address@hidden> writes:
> Thanks.
> I have passed this file in indent (hence it might no longer be
> correct), and zipped it again.  Attached for archiving purpose.
> Wow!  This file is just incredible!  I guess the C++ compiler _dies_
> trying to compile it.

Mine doesn't die.

> Basically, it seems to me that all the nodes
> are basically the same.

I don't know what you mean.

> | statement:SEMI_COLON
> | {
> |
> |   Scanner_Node scanner_node = static_cast < Scanner_Node > (parameter);
> So why don't you pass this scanner_node as paramater (using
> %parse-param) ?  That's one line less.

If `%parse-param' allows me to specify the type, then I might as well.
However, I must check whether this feature is supported on the versions of
Bison that are included in standard Linux distributions.  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.

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

> |   bool error_stop_value = (scanner_node->run_state.error_stop_mode
> |                        == Run_State::STOPPING
> |                        && scanner_node->in->type != Io_Struct::STDIN_TYPE)
> |     ? true : false;
> Defined as many times, but used several times like this :
> 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'.

> Same thing with entry.

`entry' is set in the parser rules.

> It seems to me that all this can be addressed using %printer.  You
> wouldn't even have to write anything in the action themselves.

If I get a chance, I'll look up `printer'.  I suspect it might not help me
with `log_message()', though, because there are potentially multiple log
files, depending on whether I'm calling `yyparse()' in threads or not.

> To summarize, I think that you
> - 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.  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()'.

> - need to report debugging information, and %printer can help you.

I have a lot of debugging code and a command line option for setting
`yydebug' to 1.

> but there is no clear need (yet!) for local variables (?)

It's your decision.

> Maybe you'd
> also need a means to specify an action executed each time a rule is
> reduced.

Sounds good.


reply via email to

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