Logical operators || and && are short-circuiting

[Rangi42]

true || X short-circuits to 1 without evaluating X
false && X short-circuits to 0 without evaluating X

Fixes #619

[Rangi42]

Note: This comment is obviated by #685, which makes println "{X}" and mymacro "{X}" both expand {X} as within a string literal.

The new test case does not use a print macro to combine the printv and printt "\n" because that affects how interpolation interacts with short-circuiting.

In printv 1 == 2 && 0 < STRLEN("{undef_s}"), the printv 1 == 2 && is lexed, the parser enters the relocexpr T_OP_LOGICOR mid-action rule and starts short-circuiting, and the subsequent 0 < STRLEN("{undef_s}") is lazily evaluated.

In print 1 == 2 && 0 < STRLEN("{undef_s}"), the print is lexed, the parser enters the T_ID mid-action rule for macro and does lexer_SetMode(LEXER_RAW), and then the lexer in raw mode reads the rest of the line and since it's doing both interpolation and macro arg expansion without actually tokenizing anything, it interpolates {undef_s} and complains about the undefined value.

This is arguably how it should work, or at least, changing the behavior would affect this case:

print2: MACRO
n = 20
	printv \1
	printt "\n"
ENDM

n = 10
	print {n}

This currently prints 10, not 20. Edit: which is definitely a good thing, since that's how you can pass {_NARG} to another macro.

[Rangi42]

Another subtlety of short-circuiting: both macro arguments and interpolation outside strings can expand to just about anything, so I don't think those should necessarily get short-circuited in the first place.

For example, db 2+2==4 || \1. Here the \1 looks like it ought to be a self-contained valid operand for the ||, and in real use cases it probably is. But it could also have been false \n printt "Hi!" in which case the user might expect "Hi!" to be printed regardless of the db above it. Or the line could have been db (1==1 || \3 without a closing parenthesis, where the user is for some reason expected to provide that as part of the macro argument; if short-circuiting did not expand the \3 (on the grounds that there might be a third macro arg) then it would just cause a syntax error.

[Rangi42]

This might be worth adding to 0.4.3 even if a later release will add lazily-evaluated expressions and revamp how short-circuiting works, because as-is this can already improve performance by not evaluating right-hand sides.

[Rangi42]

The short-circuiting semantics would be most useful for user-defined functions, which don't exist yet. User-defined functions would depend on true RPN lazy evaluation anyway, and @ISSOtm discussed why that's a better long-term solution in #663.