In general, the more 'contrived' the Liberty BASIC code the greater the likelihood of encountering an incompatibility with LBB. I recently came across some code which boiled down to this:
Code: array(newdim(100)) = 123
end
function newdim(n)
redim array(n)
newdim = n
end function
The essence of this code is that the array is dimensioned in a function called during the evaluation of the array's subscript! Whether or not this code will run successfully depends on the precise sequence of events inside the BASIC interpreter.
If the array's dimensions are determined before the subscript is evaluated the code will fail, because an attempt is being made to access an element of an array that doesn't yet exist. If, on the other hand, the array's dimensions are determined after the subscript is evaluated, the code will succeed.
It so happens that the former is true in LBB, so the code fails, whereas the latter is true in LB 4, so the code runs successfully. Quite why anybody would deliberately write code like that is a mystery; it would be much easier to understand and much easier to debug if split into two statements like this:
Code: subscript = newdim(100)
array(subscript) = 123
This code will of course run successfully in both LB 4 and LBB.
So the moral is: contrived code which relies on undocumented internal behavior of the interpreter is inevitably less likely to run successfully in LBB.
Richard.
Logged
