Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Ed Davis on December 10, 2020, 01:27:01 pm

Title: Small bug in QB64 expression parser
Post by: Ed Davis on December 10, 2020, 01:27:01 pm
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.
Title: Re: Small bug in QB64 expression parser
Post by: SpriggsySpriggs on December 10, 2020, 01:28:47 pm
@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.
Title: Re: Small bug in QB64 expression parser
Post by: Ed Davis on December 10, 2020, 02:05:52 pm
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.
Title: Re: Small bug in QB64 expression parser
Post by: SpriggsySpriggs on December 10, 2020, 02:06:57 pm
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.
Title: Re: Small bug in QB64 expression parser
Post by: SMcNeill on December 10, 2020, 02:28:32 pm
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.  ;)
Title: Re: Small bug in QB64 expression parser
Post by: Ed Davis on December 10, 2020, 02:37:29 pm
Quote from: SMcNeill on December 10, 2020, 02:28:32 pm
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. :)
Title: Re: Small bug in QB64 expression parser
Post by: doppler on December 11, 2020, 08:33:57 am
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.

Title: Re: Small bug in QB64 expression parser
Post by: Kernelpanic on December 11, 2020, 11:13:36 am
 
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

  [ This attachment cannot be displayed inline in 'Print Page' view ]  
 
Compiler and output 1, 2, + 3

  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: Small bug in QB64 expression parser
Post by: SpriggsySpriggs on December 11, 2020, 11:22:19 am
Why aren't you doing string comparisons for the other two tests, @Kernelpanic ?
Title: Re: Small bug in QB64 expression parser
Post by: Kernelpanic on December 11, 2020, 11:26:16 am
Which tests?
Title: Re: Small bug in QB64 expression parser
Post by: SpriggsySpriggs on December 11, 2020, 11:28:24 am
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.
Title: Re: Small bug in QB64 expression parser
Post by: Kernelpanic on December 11, 2020, 11:36:54 am
Sorry, I don't know what you just mean.

Ok, now I see your example. I have to look again.
Title: Re: Small bug in QB64 expression parser
Post by: Kernelpanic on December 11, 2020, 11:53:24 am
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.  
  17.  

Title: Re: Small bug in QB64 expression parser
Post by: SpriggsySpriggs on December 11, 2020, 11:59:10 am
@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
Title: Re: Small bug in QB64 expression parser
Post by: Kernelpanic on December 11, 2020, 05:15:49 pm
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?
Title: Re: Small bug in QB64 expression parser
Post by: SpriggsySpriggs on December 11, 2020, 06:07:53 pm
@Kernelpanic

He was comparing strings, not variables.
Title: Re: Small bug in QB64 expression parser
Post by: Kernelpanic on December 12, 2020, 02:19:41 pm
Ok, so it is understandable.
Text Only | Text with Attachments