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 _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison