help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging "$4"


From: Chris verBurg
Subject: Re: Debugging "$4"
Date: Wed, 7 Oct 2020 14:52:56 -0700

I don’t know if this is helpful, but is there a problem with ambiguity between 
these parses:

(IF 1=1 THEN PRINT “3” ) : PRINT “4”

and

IF 1=1 THEN (PRINT “3” : PRINT “4”)

?  Because if the shift/reduce conflict resolved toward the first one, then $4 
really only has one statement anyway.

-Chris

> On Oct 7, 2020, at 1:52 PM, Maury Markowitz <maury.markowitz@gmail.com> wrote:
> 
> Noob Q here. I have these rules in my BASIC.y:
> 
> statements:
>    statement
>    {
>      $$ = g_list_prepend(NULL, $1);
>    }
>    |
>        statement ':' statements
>        {
>      $$ = g_list_prepend($3, $1);
>        }
>    ;
> 
> statement:
> (among others...)
>    IF expression THEN statements
>    {
>      statement_t *new = make_statement(IF);
>      new->parms._if.condition = $2;
>      new->parms._if.then_expression = $4;
>      new->parms._if.then_linenumber = 0;
>      $$ = new;
>    }
> 
> There is a single routine that runs the statements. When I feed it this:
> 
> 100 PRINT "1":PRINT"2"
> 
> I get 1\n2 as expected. However, when I tell it to run then_expression with 
> statements
> 
> 200 IF 1=1 THEN PRINT"3":PRINT"4"
> 
> I get only 3. I *believe* that $4 is a correctly formatted g_list of 
> statements, but how do I test that assumption? How does one print out the 
> value of $4 in the debugger? 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]