I never liked statement names like -MOVE in TurboBASIC XL because it is not natural and probably makes the parser a little bit more complex. I think in this case it would better to be named as RMOVE (reverse move) or something like that. Of course it could be lost an abbreviation...
Well, in my parser both are equally easy to parse and would result in the same binary size, just change "-move" with "Rmove" in the file src/basic.syn. Lower case letters are optional, so the statement would be abbreviated to "R.".
I haven't test this yet, but what is the result of PRINT 8/3 in the integer version? (truncated, rounded or error?)
I guess that the FP version handles both type of variables, but can them be combined in a single expression? If the expression is assigned to an integer variable, which rule applies?
I tried explaining all of this in the manual, see at https://github.com/d...ic-fp/manual.md
Basically, most operations expect an integer expression, so for example "PLOT 1.3, 5" or "X=3.5" gives a parsing error, you must use "PLOT INT(1.3), 5" or "X%=3.5". The only statement that expects both FP or INT operations is PRINT, in this case the syntax says:
EXPR emit TOK_PRINT_NUM PRINT_NEXT
FP_EXPR emit TOK_PRINT_FP PRINT_NEXT
STR_EXPR emit TOK_PRINT_STR PRINT_NEXT
This means, to parse PRINT_ONE (one print expression), try tree posibilities:
- first to parse one EXPR (an integer or boolean expression), if success emit a token TOK_PRINT_NUM, then go to parsing PRINT_NEXT (this expects a comma, semicolon or end of statement).
- if not posible, parse one FP_EXPR (a floating point expression), if success emit a token TOK_PRINT_FP and go to parse PRINT_NEXT (same as above)
- at last, parse one STR_EXPR (a string expression), if success emit a token TOK_PRINT_STR and go to parse PRINT_NEXT.
If all the above fail, the entire rule (PRINT_ONE) fails, so the parser backtracks to the rule that called that, etc.
So, the result is that, if it is possible to parse the expression as integer, it will be parsed as such, only if not possible it is parsed as floating point.
The unexpected result of this is that "PRINT 1+8/3" prints 3, but "PRINT 1.+8/3" prints 3.66666666. And, the most confusing of all, "PRINT 8/3*3" prints 6 (the expression is parsed as INT), but "PRINT INT(8/3*3)" prints 8 (the argument to INT() is parsed as floating point).
Note that division gives truncated results (rounded towards 0), and it's warranted that "(A / B) * B + (A MOD B) = A".