Re: variables in yyparse

[Laurence Finston]

On Thu, 16 Dec 2004, Akim Demaille wrote:

>
> I mean it must take ages to compile.  A single function is tens of
> thousands lines long.
>

Not ages.  I've put a lot of code for rules into functions.
When I get a chance I'll do it for more, but at the moment
it's not a big problem.  The code for handling error exits
from the functions and thrown exceptions has to be in the
rules, though, so there's a limit to how much putting code
into functions helps.  This is why I'd like to be able to
divide the parser code into multiple compilation units.
I brought this up a while ago in another thread.

If the function you mean is `initialize_name_map()', I need
it because I want to be able to access the names of terminal
symbols in the files that I process after `parser.w'.  I
don't remember the details, but when I generated a table
using Bison's facility for this, the data structure for the
table wasn't declared in the header file generated by Bison.
Therefore I also use CWEB to generate a second header file.
I would be happy to get rid of `initialize_name_map()' and
`parser.h', if you want to implement features that perform
their functions.

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

That's the point of using CWEB sections.  If you look at the
CWEB sources, you'll see that I include these declarations
by including the `@<Common declarations for rules@>'
section.  This is also the whole point of my request:  If I
could declare local automatic variables in `yyparse()', it
wouldn't be necessary.

>
> It does.  Have a look at calc.c in the test suite, or at the
> documentation of the current tarballs.
>

Thanks, I will when I get a chance.

>  > 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 currently working on the next release of GNU 3DLDF.
This will be the first release to include the parser.
Currently, I include neither `parser.y++' nor `parser.c++'
in the snapshots I upload to Savannah, nor do I put them in
the CVS repository.  I may include either or both in the
distribution, I haven't decided yet.  Much as I like Bison,
I definitely do not want to take responsibility for
distributing an up-to-date release with GNU 3DLDF.

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

I don't understand what you mean by "twice during development".
What I'd like is to declare `scanner_node' once when `yyparse()' is
invoked.  If I can pass it as a `Scanner_Node' instead of a `void*', so
much the better.

>
> I was suggesting factoring some code via new interfaces, but ymmv and
> the suggestion I made probably needs being extended.
>

What does "ymmv" mean?  Sorry, I'm not good at acronyms.

I'm quite prepared to discuss improvements to the 3DLDF
code.  However, if you want to make suggestions,
please read and understand my code first.  In particular,
please look at the actual code I write in the CWEB input
files for the parser rather than the code generated from
them by `ctangle'.

>
>  >> Same thing with entry.
>
>  > `entry' is set in the parser rules.
>
> I meant that entry and status are defined, but could easily be
> removed.

I use `entry' and `status' in so many rules that it's most
convenient for me to put them in the "Common declarations"
section.

>
> I mean you can pass several arguments to yyparse.
>

I put the information in a `Scanner_Node' in the first place so it's all
in one place.  I don't think it would make sense to have to
extract it before calling `yyparse()'.
Nor do want to change the calling convention for `yyparse()'
each time I make a change affecting these variables.  In
fact, I definitely will not do this.

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

Executing an action each time a rule is reduced is essentially what I
accomplish with the "Common declarations" section.  As you've noticed,
it's inefficient, which is why I'd like to get rid of it and
use local automatic variables instead.

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

I know virtually nothing about Bison's internals, so I don't
have an opinion about this.

Laurence