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.markow...@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?