Small bug in QB64 expression parser

[Ed Davis]

This works in QBASIC:

Code: QB64: [Select]

1. print "abc" = "a" + "bc"
2. -1
3.  

But in QB64, I get:

Code: QB64: [Select]

1. QB64 Compiler V1.4
2.  
3. Beginning C++ output from QB64 code... first pass finished.
4. Translating code...
5. [.........................                         ] 50%
6. Expected variable/value before '='
7. Caused by (or after):PRINT "abc",3 = "a",1 + "bc",2
8. LINE 1:print "abc" = "a" + "bc"
9.  

Not a big deal for me - I happened on this by chance.  But, I thought I would report it just in case.

[SpriggsySpriggs]

@Ed Davis
I don't think is a bug so much as it is just not allowed in QB64. I recommend coding in the IDE so you can see syntax errors immediately. It would stink to have to wait until compile to find out if what you are writing is "syntax friendly" or not. If you are trying to compare two strings like that then do this and I believe you will get your desired results:

Code: QB64: [Select]

1. PRINT ("abc") = ("a" + "bc")

I get -1 just like your QBASIC code.

[Ed Davis]

As I noted in my post, not a big deal for me.  This is not code that I would ever write.

A user of a product that I created a long time ago (and still support), reported this bug in the products macro language.  I started testing it on various other compiler/interpreters, to see if it was handled.

Again, no big deal for me.  It is a difference from QBASIC, so I reported it.  And if the expression parser is anything like the one in my product, it might be a chore to fix it, and maybe not worth the time.

[SpriggsySpriggs]

Well again it isn't really a bug. Some syntax from QBASIC just isn't allowed in QB64 but that (the code I showed) would get you the same results, at least.

[SMcNeill]

PRINT is its own beast — basically a sublanguage inside the language.  I doubt any glitch in PRINT will ever be fixed, just from the complexity of the statement itself and how it translates to c. 

I’m not at the PC right now, but does the error appear elsewhere, like in an IF statement?

IF “abc” = “a” + “bc” THEN PRINT “TRUE” ELSE PRINT “FALSE”

If it works in IF, you’ve narrowed the glitch down to PRINT itself, and not the expression parser, and as I said above, I wouldn’t hold my breath expecting to see PRINT overhauled anytime soon.

If it glitches in IF as well, then I’ll dig into it later and see what I can come up with, once I get some free time again after the holidays.  ;)

[Ed Davis]

I’m not at the PC right now, but does the error appear elsewhere, like in an IF statement?

IF “abc” = “a” + “bc” THEN PRINT “TRUE” ELSE PRINT “FALSE”

If it works in IF, you’ve narrowed the glitch down to PRINT itself, and not the expression parser, and as I said above, I wouldn’t hold my breath expecting to see PRINT overhauled anytime soon.

Yep, your if example works fine.  So the problem is relegated to print.  Again, not an issue for me, and not something anyone would ever hit.  I'm even sorry I brought it up. :)

[doppler]

Print is the bread & butter of basic.  Unless you just want to manage a bit of code, data or records.  Visual output "Print" is used.  No wonder it's a beast under the hood.  It has to take all kinds of data and make it presentable.  I have seen other languages (specialized use, military etc)  break output in categories to speed up code.  A print like command for numeric, alphabetical, string and memory, all separate codes.  What fun to find out you used the wrong print variant in relation to the data.  ie: Numeric print used on string data.  I have not used that convoluted code myself, but my friends have.  This was back in the day of "Assembly needed" and very little expensive memory available.  Everything was in code modules, pull the modules needed and use the I/O interfaces.  Made for interesting programs.  You would be amazed what could happen in less than 32K total memory.  Even more amazed when you realize it started with only 4K before expanding to 32k.

[Kernelpanic]

 

Code: QB64: [Select]

1. 'Example 10. Dez. 2020
2.  
3. '1. OK
4. PRINT abc = a + bc
5.  
6. '2. OK
7. IF "abc" = "a" + "bc" THEN PRINT "TRUE" ELSE PRINT "FALSE"
8.  
9. '3. Ergibt: Falsch -> 0
10. IF abc = a + bc THEN PRINT TRUE ELSE PRINT FALSE
11.  

Compiler and output 1 + 2

  [ You are not allowed to view this attachment ]  
 
Compiler and output 1, 2, + 3

  [ You are not allowed to view this attachment ]  

[SpriggsySpriggs]

Why aren't you doing string comparisons for the other two tests, @Kernelpanic ?

[Kernelpanic]

Which tests?

[SpriggsySpriggs]

The ones you just posted, @Kernelpanic

Shouldn't they be:

Code: QB64: [Select]

1. PRINT "abc" = "a" + "bc"
2.  
3. IF "abc" = "a" + "bc" THEN PRINT "TRUE" ELSE PRINT "FALSE"
4.  
5. TRUE = 1
6. FALSE = 0
7. IF "abc" = "a" + "bc" THEN PRINT TRUE ELSE PRINT FALSE

If you don't define TRUE and FALSE then it will be a result of 0 no matter what.

[Kernelpanic]

Sorry, I don't know what you just mean.

Ok, now I see your example. I have to look again.

[Kernelpanic]

So without "" the result is always 0.

Code: QB64: [Select]

1. 'Forumsbeispiel 10. Dez. 2020
2.  
3. 'OK
4. PRINT abc = a + bc
5.  
6. 'OK
7. IF "abc" = "a" + "bc" THEN PRINT "TRUE" ELSE PRINT "FALSE"
8.  
9. 'Ergibt: Falsch -> 0
10. IF abc = a + bc THEN PRINT TRUE ELSE PRINT FALSE
11.  
12. TRUE = -1
13. FALSE = 0
14. IF abc = a + bc THEN PRINT TRUE ELSE PRINT FALSE
15.  
16. END
17.  

[SpriggsySpriggs]

@Kernelpanic

You are comparing 0 to 0 on line 10

Code: QB64: [Select]

1. IF abc = a + bc THEN PRINT TRUE ELSE PRINT FALSE

abc is undefined so it is equal to zero
a is undefined so it is equal to zero
bc is undefined so it is equal to zero
TRUE is undefined so it is equal to zero
FALSE is undefined so it is equal to zero

The code is literally:

Code: QB64: [Select]

1. IF 0 = 0 + 0 THEN PRINT 0 ELSE PRINT 0

[Kernelpanic]

I think you mean this:
"IF abc = a + bc THEN PRINT TRUE ELSE PRINT FALSE"

Yes, but I don't understand what the meaning of the "" is here. Why this effect?
With " " it is correct, without no. Why?