A quick overview of currently known issues:
1. Yes, more than 1 extra blank line at the end of the file make the LISP parser choke in QB45, FBSL and SB alike. This signifies an initial design fault, supposedly, the inability to correctly intercept an EOF event. The lookahead depth in the parsing loop is 1 char only. There's no looping in an empty line; no looping -> no lookahead -> no EOF interception.
2. (/ A B C) and (- A B C) yield trash in QB45, FBSL and SB alike. (+ A B C) and (* A B C) are correct. Another initial design bug.
3. BASIC LISP's T stands for TRUE, () stands for FALSE. Every math or logical evaluation sends its result to the console transparently without an explicit (print something). The explicit print can additionally enforce LISP to output data which isn't part of the evaluation process.
LISP's "evaluation" is what we usually call "execution" in normal human speech. Implicit evaluation is applied to everything that is enclosed in a pair of matching parentheses. Apart from implicit evaluation, LISP also has an explicit (eval [']something) command that additionally returns whatever an executable something has already returned, or turns 'something into an executable and returns only its own evaluation of this otherwise non-executable literal.
From the LISP perspective, execution of a program file as a whole is a command to (eval 'string_literal_with_entire_file_contents). It adds a trailing T (TRUE) to the console output to denote successful completion of the eval command. Failure to evaluate 'something would result in () (FALSE) if only the evaluation process didn't trigger some other error that LISP is responsive to.
In other words, T and () serve as program success/failure return codes in LISP file evaluation.
I find this behavior logically reasonable and I wouldn't fight to suppress it.
