Re: initial-action question

[lfinsto1]

Aaron Jackson wrote:

> Thanks for the response.

You're welcome.

> On Feb 11, 2008, at 5:03 AM, address@hidden wrote:
>
>> To the best of my knowledge, you would need to modify the skeleton
file. [...]

> I wanted to avoid this since I want my .y code to be portable.

It would be.  You'd just have to include it in your distribution and
account for this in your `make' rules and/or explain to users anything
special they'd need to do.  To the best of my knowledge, Bison uses to m4
to copy the skeleton file and inserts the parser rules and the
corresponding actions in the appropriate places.  However, I don't think
it's necessary or desirable in this case.  (I've never modified the
skeleton file myself.)

> I ended up using a structure with all the variables I needed, but it
just > doesn't seem personally satisfying to me.
> It just seems cleaner
> if I could declare variables that are local to yyparse, that way, the 
function calling yyparse doesn't have to know what's going on in the 
background.

I didn't know about Bison's internal functions, which Joel Denny explained
in his message, making it impossible, or at least impracticable, for users
to declare local variables in `yyparse'.

>From the point of view of programming philosophy, I don't see anything not
clean about using the parameter.  The place where you store your values is
just a region of memory.  I don't see any significant difference between
letting it be popped from the stack when `yyparse' returns to its caller
or freeing it after it returns.  It will probably be cheaper to let it be
popped from the stack, but not so much that I would choose to program in a
way that would be less clear and understandable.

If you're really worried about the caller of `yyparse' having access to
the contents of the object passed as a parameter, you could use C++ and
make them private data members.  You wouldn't necessarily have to generate
a C++ parser.  I generate a C parser and compile with g++.  On the other
hand, if you're using C, you're already using a language that doesn't
support data hiding that much anyway, so I wouldn't worry too much about
it.  After all, the caller of `yyparse' isn't going to access this data by
itself --- it's under your control.  (I'm not very "object-oriented".)

It can also be very useful to have a structure that represents the state
of a parse and which continues to exist after `yyparse' has returned.

Laurence