[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?
- Debugging "$4", Maury Markowitz, 2020/10/07
- Re: Debugging "$4",
Chris verBurg <=
Re: Debugging "$4", Hans Åberg, 2020/10/08