Is this a bug?

[TerryRitchie]

I just spent an hour tearing my hair out trying to track down a syntax error that the IDE failed to report. My need to comment everything bit me in the butt this time.

I accidentally placed a comment after a DATA statement. The line of code containing the READ statement kept failing with a syntax error after executing the code. The code worked fine, I made a few comments, ate supper, came back, and the code didn't work.

At first I thought my cat was playing a prank on me ... typing something in while I'm not looking! Hey, it's happened before! They love to walk on keyboards.

But I FINALLY figured out what was going on.

Is it a bug that the IDE does not catch a comment being placed after a DATA statement?

[SMcNeill]

DATA I eat cheese.
DATA I don't eat cheese.

Two perfectly valid DATA statements, each being a sentence.  If the remark signified a comment, the 2nd statement would end at I don

Do this:

DATA I don't eat cheese.: 'Now I can leave a comment after the colon.

---

See example 1: https://qb64phoenix.com/qb64wiki/index.php/DATA

[TerryRitchie]

DATA I eat cheese.
DATA I don't eat cheese.

Two perfectly valid DATA statements, each being a sentence.  If the remark signified a comment, the 2nd statement would end at I don

Do this:

DATA I don't eat cheese.: 'Now I can leave a comment after the colon.

---

See example 1: https://qb64phoenix.com/qb64wiki/index.php/DATA

Ok, the syntax error only happens with data lines that contain numeric values

READ a$
PRINT a$
READ n
PRINT n

DATA I don't each cheese
DATA 9 '  (nope)
DATA 9: ' (yep)

Thanks for the : tip though, that works with numeric values too. I missed that in the Wiki.

[SMcNeill]

Your syntax error is trying to read a string as a number.  

DATA 1's, 2's, 3's

READ x    <-- ERROR!


READ x$
PRINT x$

(Prints "1's")

Data can hold both numbers and strings in one statement.  Read can only read the type you specify back though.  

[PhilOfPerth]

Great work!. I have had this problem too, but always fiddled until it worked. Now hopefully, I can steer through it.

[grymmjack]

I ran into this too.

Code: (Select All)

DATA 9: ' (yep)

Exactly

The IDE didn't catch it then either.

[SMcNeill]

I ran into this too.

Code: (Select All)

DATA 9: ' (yep)

Exactly

The IDE didn't catch it then either.

The IDE can't catch it, as it's not a glitch.

For example, let's take a look at this person in my address book:

Code: (Select All)

DATA John, Doe, 123, 49er's Street, New York, New York, 12345

Now, that data represents:
First name -- string
Last name -- string
House/Apt number -- number
Street name -- string
City name -- string
State name -- string
Zip code -- number

Now, which of the next two statements do you support as being true:

1) That's correct DATA as written and will process in the proper fields with zero issues.

or

2) That's only half the data, as that ' is a remark and everything after it doesn't count as data, therefore it's going to error out when being read.

---

Note that BASIC wouldn't have this issue, if DATA strings had the same rules as everything else in the language -- they had to be INSIDE QUOTES!!   Unfortunately, in an attempt to save as much byte size, disk space, and memory, as possible back in the day, DATA doesn't require strings to be in quotes.

And that's where this "glitch" tends to pop up and catch folks unaware who aren't thinking about it.  

But, as we tend to try and be QB45-compatible as much as possible, we can't really call this a bug.  It's just the way BASIC tends to do DATA -- even if that does get rather messy from time to time.