Re: for loops in C style

[lfinsto1]

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