>> Oh, I see. I thought you were writing a C-like interpreter that >> would actually execute the loop. In that case, you're right, and my >> point is irrelevant. I suppose what ultimately gets output is >> machine-code or assembler with a branch and a goto for the loop? > > Yes! you're right.
Well, that is the way it's done, so it wasn't that clever of me. > For the stack overflow, it's true that it's a kind of issue. It's a > bit complicated for my case, since I'm not using bison's semantic > stack to push and pop the terminals and to link them together in a > tree form. I'm using one of my own right now and I'm really feeling > like I'm duplicating that functionality so may be I'm going to rewrite > the actions to use bison in the standard way (i.e, actions use $$, $1, > $2, etc.). What might work is to scan to the end of the loop and just store the tokens or perhaps the non-tokenized input somewhere. When you traverse your syntax tree (I suppose the idea is to traverse it in order to produce the machine code), you could parse the statements, etc., within the loop, building that branch (or whatever) of your syntax tree. For inner loops, you would just do the same thing. Of course, the trade-off would be that any errors would be caught at this time and not when the "outer" tree is built. Just an idea. > But I also believe that it's also a limitation in bison too > (its stack size is fixed). I think it is, but haven't checked. Assuming it is, I don't know why it was done this way, but the fixed stack size is adequate for most purposes. I don't think it would be difficult to duplicate the stack if you really need one that can grow dynamically. I don't see any particular disadvantage to doing this, on the face of it. Laurence _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison