That looks pretty normal. It displays the values of $x and $y, right? No. It displays the value of $y
only. Your $x value never appears. The reason is that SHOW uses spaces as delimiters, not commas. Therefore
SQR assumes that $x, (including the comma) is a variable. You certainly didn't intend that. So SQR just displays the value
of $x, and that is empty. There is no error message, since this is perfectly valid syntax.
This is even worse:
That is one variable named $x,$y and it's probably empty.
This situation will now be flagged by SP Debugger for SQR when you click the Code Alerts button (the "bug" button on the toolbar).
Version 2.0.6 is now available for download. Customers can and should upgrade, free of charge. This version also includes various other
fixes. Get the new version at the downloads page.
How about this?
move 'no' to $is`THIS`a`good`"variable"`(name)?!!
This is valid syntax too. Unfortunately, SQR accepts almost anything as a variable name, and this leads to
a number of different problems. First is the difficulty in reading code such as this. You normally do a little parse on the code as you
read it, and you probably aren't expecting that mess to be one token (a variable) in the program. Second is the fact that a variable that
would be accepted in certain statements (such as MOVE) might not be accepted in others (such as LET), since they follow different rules!
Third, SQR does not require us to declare our variables, so we can accidentally create one we weren't expecting (as shown in the
earlier examples). And finally, this extreme "flexibility" can lead to ambiguities, like this:
let #x = #y-1
Is that a variable named #y-1 or are we subtracting 1 from a variable named #y? In most languages it would be
clear because they wouldn't allow a variable named like that. SQR does allow it and recognizes the ambiguity. It issues this warning:
"#y-1 assumed to be a variable name, not an expression". That warning pops up every time you run the program. So it's best to avoid names