The Sinclair QL Forum

stevepoole wrote:Hi,
If I remember correctly, the QDOS 'expression evaluator' evaluates a statement from left to right, (except where parentheseses override priority).
So the QDOS evaluation is correct ?
As for SMSQ/E, I cannot remember reading about expression evaluation priorities at all... or any changes to them.
So it looks like SMSQ/E got it wrong...

I'm not saying that. The statement in question is an assignment, in the form [LET] variable = expression, so the only expression here is the call to the function 'two' which returns 200 but also increments array index x as a side effect. Then, the array element a(x) gets assigned but QDOS takes the value of x as array index before it evaluates the expression, and SMSQ/E does this afterwards. I've taken a look at Jan Jones's 'SuperBASIC Definitive Handbook' but coudn't find anything that defines the order of evaluation when the variable to be assigned to is dependent on the result of the expression...
That said, I believe it would be a good idea if SMSQ/E would change this behaviour to match that of QDOS, just for compatibility reasons...

To make matters more compatible, x as a parameter to 'two' would be automatically local, and help get rid of the bug !

That would also make it impossible for a function to assign a value to a global variable... If your intention is to use a variable only locally, you should declare it in a LOCal statement. I must admit I have sinned here too in the past, as pre-Minerva versions of S*BASIC couldn't handle more than 10 LOCals or else would crash...

regards, Jan.

janbredenbeek wrote:That said, I believe it would be a good idea if SMSQ/E would change this behaviour to match that of QDOS, just for compatibility reasons..

No, please dont do that! Then the bug will be in my brain!

Hi Jan,
At present I do not have acesss to my QDOS system, being over the pond.

Can you please try the following code under QDOS and SMSQ/E :
100 dim a(5) : x=2 : a(x+1)= two(x) : print x!!a(x)
110 DEFine FuNction two(x)
120 x=x+1 : RETurn 200
END DEFine

If I correctly read the QL User Guide, a(x+1) should evaluate before two(x) on line 100.
This is not the case under SMSQ/E. The two systems should indeed normally behave the same !
Regards,
Steve.

stevepoole wrote:Hi Jan,
At present I do not have acesss to my QDOS system, being over the pond.

Can you please try the following code under QDOS and SMSQ/E :
100 dim a(5) : x=2 : a(x+1)= two(x) : print x!!a(x)
110 DEFine FuNction two(x)
120 x=x+1 : RETurn 200
END DEFine

QDOS (Minerva): 3 200
SMSQ/E (QPC2): 3 0
(which is as expected, since in S*BASIC parameters are called by reference so any change in formal parameter x in a function is reflected in the actual parameter used when calling the function).

regards, Jan.

Hi Jan,
The compatibility fix could be to modify the code to read :
a(x+1)=two( (x) )
Does this now work correctly on both systems ?
It is a pity if code tweaks are necessary, but they are better than nothing...
Regards,
Steve.

stevepoole wrote:Hi Jan,
The compatibility fix could be to modify the code to read :
a(x+1)=two( (x) )
Does this now work correctly on both systems ?
It is a pity if code tweaks are necessary, but they are better than nothing...
Regards,
Steve.

On SMSQmulator I get '2 0' and a(3) equals 200. Haven't been able yet to test it on QDOS/Minerva. But putting extra brackets around x on the function call stops it from being modified - it is now treated as a local variable within the function.

Jan.

Hi everyone

janbredenbeek wrote:But putting extra brackets around x on the function call stops it from being modified - it is now treated as a local variable within the function.

Whilst just semantics, it would be more accurate to say "... it is now treated as an expression and thus passed by value rather than by reference within the function. As such, changes made to (x) will not persist upon return."

I don't think I've ever read anything for either platform (QDOS/SMSQ) to define whether the left-hand-side of an assignment is evaluated before or after the right-hand-side - only the precedence _within_ an expression (of which we have two - one either-side of the assignment operator.)

In (at least my) software industry, if it aint documented, it aint a bug, but undocumented behaviour. Drives our customers crazy!

My take on the original use-case is that when we rely on undocumented behaviour we must take what we get, until such time as the behaviour is defined/documented.

It seems to me perfectly reasonable to expect the developer to actively code-round undefined system behaviour, such as this interesting example, in order to produce predictable behaviour across platforms.

would It not come under the wider scope of the BASIC language ? which is usually a left to right evaluation?

Pr0f wrote:would It not come under the wider scope of the BASIC language ? which is usually a left to right evaluation?

I doubt if this was ever standardised in BASIC. AFAIK there is no such thing as 'standard BASIC'. It might as well be that SuperBASIC was the first BASIC that would let you use a function call in an expression which could modify a variable! Yes we had DEFFN before, but this could only return an expression and did not have a 'body' of statements like DEFPROC.
(I wonder how Pascal and C have resolved this)...

Jan.

it does look messy - being able to amend a variable that's been declared as local, and being allowed to do so because you are being called by the procedure that declared it local. It's more regional then