[FIXED] QB64 Precompiler Bug ($LET)

[SMcNeill]

Code: QB64: [Select]

1. $IF X = 2 THEN
2.     $LET X = 1
3.     PRINT "We're inside this block like an idiot!"
4. $END IF
5.  
6. $IF X = 1 THEN
7.     PRINT "It's 1"
8. $ELSE
9.     PRINT "We skipped the definition as we should have."
10. $END IF

As we can see from above, $LET is assigning values, even if it's in a block which should be unavailable for us.  Since we don't have a precompiler variable X to start with, there's no way we should actually do the stuff inside that first $IF block (and we don't, except for that $LET)...

This needs a little tweaking.  To be honest, I'm suprised nobody ever mentioned this before.  Maybe I'm the only person who ever uses $IF and $LET??  :P

[FellippeHeitor]

I often use $IF for OS-specific code blocks, so no $LET required. Good catch.

[SMcNeill]

The issue is a case of last assignment vs top-down assignment.

QB64 runs things in 2 passes for us -- the precompiler pass and then the translation pass.

$LET X = 1
$IF X = 1 THEN
    PRINT "Hello World"
    $LET X = 2
$END IF

The above colors itself as if it's going to work for us, but it doesn't.  It simply runs and we have a blank screen.

"HOW??", you ask?

Because in the prepass we set X to 1.
That then lets us into the $IF block, which then makes X a value of 2.

In the second pass, when we execute our code, X is 2, therefore we don't go back into the very block that we successfully passed into in the prepass.

For now, the rule should be: 

**DON'T USE $LET MORE THAN  ONCE TO DEFINE A PRECOMPILER VARIABLE, UNTIL I CAN SORT THIS MESS OUT.**

[SMcNeill]

The fix is below, with one cavet:  It ruins the auto-indenting for the $IF blocks.

No longer do we see:
$IF WIN THEN
     PRINT "Hello World"
$END IF

Now, it all sticks to the left side of the screen and gives us:

$IF WIN THEN
PRINT "Hello World"
$END IF

**********************
**********************

IMHO, it's better to have it work RIGHT, rather than have it work PRETTY.

I'll dig into the indenting and spacing issues later this afternoon or tomorrow, but for now, this seems to correct the flow/assignment issues which we were seeing with the report above.

[FellippeHeitor]

Did you push it yet or are you pushing with the indenting?

[SMcNeill]

I'll push it once I get the indenting corrected as well.

[SMcNeill]

Fixed, with indenting... I think.  :P

Also expanded the precompiler so that it now knows how to check to see if a PC-variable has been defined or not, which allows for the such as:

Code: QB64: [Select]

1. $IF X = UNDEFINED THEN
2.     PRINT "Hello"
3.     $LET X = 1
4. $END IF
5.  
6. $IF X = UNDEFINED THEN
7.     PRINT "World"
8.     $LET X = 1
9. $END IF
10.  
11. $IF X = DEFINED THEN
12.     PRINT "Steve"
13.     $LET X = 2
14. $END IF
15.  
16. $IF X = 1 THEN
17.     PRINT "I love pizza"
18.     $LET X = 1
19. $END IF
20.  
21. $IF X = 2 THEN
22.     PRINT "I love cheese"
23.     $LET X = 1
24. $END IF

I think the above illustrates our fixes fairly well.

When undefined at start, we go inside the first block and print "Hello", then we define X = 1.

Since it's defined, we skip the second block.

And, since it's defined, we execute the third block of code, printing "Steve" and reassigning X = 2.

Since X is 2, we skip the next block completely.  That $LET there does nothing now.

Which means the next block is valid, but -- as you can see -- we no longer bleed over that $LET X = 1 back to the translation stage and ruin the print statements and such above us.

It's prettified.  It seems to fix all the issues without making new ones.  I adds new capabilities for us...

I don't know what more a person could want.  :P

*************************
*************************

Grab it.  Try it.  Test it.

Unless somebody finds a glitch with the process somewhere that I'm currently overlooking, I'll push the changes into the repo in the next couple of days, after some testing has been done.

[SMcNeill]

Went ahead and pushed fix/enhancements into the development build.