Odd behavour

Anything QL Software or Programming Related.
User avatar
janbredenbeek
Trump Card
Posts: 249
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Odd behavour

Postby janbredenbeek » Sun Feb 04, 2018 2:52 pm

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.


User avatar
pjw
Gold Card
Posts: 375
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: Odd behavour

Postby pjw » Sun Feb 04, 2018 4:13 pm

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!


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
stevepoole
Trump Card
Posts: 161
Joined: Mon Nov 24, 2014 2:03 pm

Re: Odd behavour

Postby stevepoole » Sun Feb 04, 2018 7:18 pm

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.


User avatar
janbredenbeek
Trump Card
Posts: 249
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Odd behavour

Postby janbredenbeek » Sun Feb 04, 2018 10:44 pm

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.


stevepoole
Trump Card
Posts: 161
Joined: Mon Nov 24, 2014 2:03 pm

Re: Odd behavour

Postby stevepoole » Mon Feb 05, 2018 8:46 am

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.


User avatar
janbredenbeek
Trump Card
Posts: 249
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Odd behavour

Postby janbredenbeek » Tue Feb 06, 2018 4:49 pm

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.


martyn_hill
Gold Card
Posts: 381
Joined: Sat Oct 25, 2014 9:53 am

Re: Odd behavour

Postby martyn_hill » Tue Feb 06, 2018 5:39 pm

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.


User avatar
Pr0f
Gold Card
Posts: 267
Joined: Thu Oct 12, 2017 9:54 am

Re: Odd behavour

Postby Pr0f » Tue Feb 06, 2018 10:05 pm

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


User avatar
janbredenbeek
Trump Card
Posts: 249
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Odd behavour

Postby janbredenbeek » Wed Feb 07, 2018 12:44 pm

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.


User avatar
Pr0f
Gold Card
Posts: 267
Joined: Thu Oct 12, 2017 9:54 am

Re: Odd behavour

Postby Pr0f » Wed Feb 07, 2018 1:10 pm

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 ;-)



Return to “Software & Programming”

Who is online

Users browsing this forum: No registered users and 1 guest