[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

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

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

reply via email to

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