Bug in your integer expression parsing

[remy]

For context, I've written the same thing as you in JavaScript, and I was looking at your code (which seems much cleaner 😄 ) for to test my own results against.

Any, I've found there's a parsing bug in your integer expression logic (I'm not sure where the bug is, but it's definitely there).

Given the following code:

10 LET %x=% RND 4*48+48
20 PRINT %x

Converting to .bas file will print 1440, rather than 48 (or a random number than increments by 48).

From the hexdump, I can see that you're treating the numerics in the right hand of the expression as 5 byte numbers when they shouldn't be. Below is a screenshot with the output from the python script highlighted, next is my JavaScript version and below that (og) is the result from .txt2bas run on the Spectrum:

You're welcome to see how my js is doing it but it's not the cleanest of code (and possibly a bit confusing…!).

[kounch]

I tried to understand your code, but i got lost :-(

The current logic in my script to treat an integer expression literally (not converting to 5-bit number) is as follows:

1. After a % or MOD are found, treat everything literally
2. Until ,. = or a classic BASIC token (char code > 164) is found, then process numbers as 5-bit

In this case, RND is found, so the numbers in the last part are processed as 5-bit.

I have reading in ZX Next manual, but i cannot clearly see what the logic should be.

Perhaps adding a list, and excluding in 2. every token that is valid in an integer expression, like RND?

[remy]

Yeah - sorry about my code 😊

My own parser wasn't driven by the manual but running code comparisons with the .txt2bas (and sometimes writing the code directly into the NextBASIC editor and checking memory directly which was way trickier!).

I didn't know mod switches into int mode (I'll need to adjust my own code for that).

Actually, check page 76, I think that RND and a handful of other keywords are allowed in integer expressions.

[kounch]

Actually, check page 76, I think that RND and a handful of other keywords are allowed in integer expressions.

That's very useful! I overlooked it

This commit fixes this issue and some similar ones (when using RND, PEEK, IN, USR and BIN).