Re: variables in yyparse

[Akim Demaille]

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