Re: for loops in C style

[Laurence Finston]

On Fri, 29 Feb 2008, Ilyes Gouta wrote:

> 
> >  fexpr: /* Empty  */
> >  {
> >   /* Action for empty case  */
> >  };
> >
> >  fexpr: expr
> >  {
> >   /* Action for `expr' case  */
> > };
> 
> I wasn't aware the one could duplicate a rule so that it has two
> possible bodies. But it's alright, there is a second, much prettier
> approach.

Duplicating the left-hand side of a rule and using `|' are completely 
equivalent.  I use the CWEB package for my Bison input files 
and have a lot of log entries and TeX code for the documentation, so
the different alternatives can be widely separated in my source
files.  I therefore prefer to duplicate the left-hand side.  In
addition, there's no rule that says all of the rules with the same
left-hand side need to be consecutive in your input file or files.

> 
> >  I'm not sure about your `block'.  It may make sense from the point of
> >  view of a formal grammar, but in practice, it means parsing the same
> >  input multiple times.  Have you got a solution for this yet?
> 
> Well, my purpose is to construct an abstract syntax tree given a
> script. The block rule in may grammar is defined as following:
> 
> block: '{' {ctx->scope++;} declarations statements '}' {ctx->scope--;
> fancy_stuff();} ;

Yes, I figured it would be something along these lines.  The
consequence is that all your `declarations' and `statements', which
might contain nested loops, have to be processed before the `block'
rule can be reduced.  This may not be a problem, but it might cause
stack overflow.  I think my way of doing it is simpler.  However, it's
not that simple to explain and it's not C-like, so I will just refer
you to previous postings where I have explained it, if you want to
know the details.  If you search for "loops" in the archive, you
should find the previous discussions.

> Basically, parsing the input multiple time isn't really an issue for
> my case (actually I don't understand your point here), since what I'm
> doing is just recognizing/reducing the different script components,
> building the ast nodes (filling the right information) and linking
> these nodes properly to form the final tree once everything is reduced
> to the primary block. I've got pretty much everything working (this
> includes nodes for identifiers, unary and binary operations, array
> fetches and stores (indexed accesses), jumps and conditional jumps).
> Once the ast is constructed, I switch off flex/bison and all the
> remaining work is done using that tree, this includes types
> propagation (for the float and int conversions), registers allocations
> and then native opcode emitters.

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?

Laurence