Re: Please assist: if/else condition problem with lex/yacc

Kevin Lynx <kevinlynx@gmail.com> writes:


> paktsardines@gmail.com (Pakt) wrote:
> "
> if_else_block:
> TOK_IF expression LBRACE commands RBRACE TOK_ELSE LBRACE commands
> RBRACE {
> if ($2 == true) {
> $$=$4;
> }
> else {
> $$=$8;
> }
> }
> ;
> "
> I suppose this will not work as you wish. Actually, yacc will parse
> the two "commands" above, but not parse one of them by the
> "expression". The simple solution is to set a global flag to indicate
> the "expression" result, and when you interpret "command", you can
> check the flag to do your special things.
>
> Kevin Lynx
> [A flag will work for if/then/else, but I still encourage people to turn
> anything they plan to interpret into an AST first. Flags won't help
> when you want to add loops. -John]


Why do people have such objections to doing the simple correct thing
and keep trying to hack something that just gets them deeper into a
quagmire? (No need to answer, that question is rhetorical.)


John, our moderator is absolutely correct. Building an AST is the
simplest most straight-forward solution to this problem. It will let
you do what you want and you won't try layering hack-upon-hack trying
to kludge toegther something that is a house-of-cards.


You can have some luck getting if-then-elses working with an execute
as you parse strategy. Others, have done it. You can also get it to
work with simple non-recursive subroutines. However, when it comes to
executing loops or subroutines with recursion, you will find the
problem nearly intractable. In those, cases that only simple solution
is to have a saved representation you can execute. An AST qualifies
for that.


Equally important is that for any complete modern parser generator
(i.e. written since about 1990), you will find ways of generating an
AST directly from your parser grammar with some simple annotations.
If you stay with yacc, you can find add-on tools that do the same
thing.


Even if you don't want to use a tool, it is fairly simple to build an
AST by hand. You simply make one class (data structure) for each
non-terminal or token in your grammar, where the members (fields) in
the class correspond to the (interesting) items in the right-hand-
side(s) of the rules that define the non-terminal. In the grammar,
you construct (allocated and fill in) one instance of the class at the
end of each rule (i.e. when the rule reduces) filling in the members
from the items in the rules right-hand-side, and make that newly
created instance your parser result. Something like this:


        if_stmt: if LP expr RP then block else block semi;
                      { class if_stmt *result = new if_stmt(
                                        $3, // expr
                                        $6, // then block
                                        $8); // else block
                          $$ = result;
                      }


Hope this helps,
-Chris


******************************************************************************
Chris Clark email: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
------------------------------------------------------------------------------

Return to the comp.compilers page.
Search the comp.compilers archives again.