Odd behavour

Anything QL Software or Programming Related.
Martin_Head
Gold Card
Posts: 291
Joined: Tue Dec 17, 2013 1:17 pm

Odd behavour

Postby Martin_Head » Sat Feb 03, 2018 4:10 pm

I have been trying to get an old Basic program to run in QPC2. And I came across a problem.

This is a simplified version of the the piece of code I was debugging, to show the effect.

Code: Select all

100 DIM a(5)
110 one
1000 DEFine PROCedure one
1010 LOCal x
1020 x=2
1030 a(x)=100
1040 PRINT a
1045 PRINT
1050 a(x)=two
1060 PRINT a
1070 END DEFine one
1080 DEFine FuNction two
1090 x=x+1
1100 RETurn 200
1110 END DEFine two


The desired result, is array element 2 ends up as 200

In QDOS this happens, but in SMSQ/E, element 3 gets set to 200

I can program around the problem. But is this a bug in QDOS that got fixed in SMSQ/E, or is it a bug in SMSQ/E?


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

Re: Odd behavour

Postby Pr0f » Sat Feb 03, 2018 5:31 pm

x is not defined as local in function two


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

Re: Odd behavour

Postby pjw » Sat Feb 03, 2018 8:10 pm

Martin_Head wrote:<> in SMSQ/E, element 3 gets set to 200

This is the correct result. QDOS is simply mistaken ;)


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
User avatar
pjw
Gold Card
Posts: 375
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: Odd behavour

Postby pjw » Sat Feb 03, 2018 8:40 pm

Pr0f wrote:x is not defined as local in function two

x here is one's local x. If two were called from another procedure that defined x as local,
it would act on that procedure's version of x, as in:

Code: Select all

dim a(3)
one: x=x+1: print a, x\
another:    print a, x\
:
def proc one
rem GLOBal x
  x=1: a(x)=1
  two: a(x)=2
three: a(x)=3
enddef one
:
def proc another
loc x
  x=1: a(x)=1
  two: a(x)=2
three: a(x)=3
enddef another
:
def proc   two: x = x + 1
def proc three: x = x + 1


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
User avatar
Pr0f
Gold Card
Posts: 269
Joined: Thu Oct 12, 2017 9:54 am

Re: Odd behavour

Postby Pr0f » Sat Feb 03, 2018 9:23 pm

According to Qdos keywords manual:

LOCal allows identifiers to be defined to be LOCal to a function or procedure. Local identifiers only exist
within the function or procedure in which they are defined, or in procedures and functions called from the
function or procedure in which they are defined. They are lost when the function or procedure
terminates. Local identifiers are independent of similarly named identifiers outside the defining function
or procedure. Arrays can be defined to be local by dimensioning them within the LOCal statement.

so then x would be local in scope for both procedure one in which it is defined local, and also procedure two

Hence x=x+1 in procedure two would operate on the local x in procedure one


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

Re: Odd behavour

Postby Pr0f » Sat Feb 03, 2018 9:24 pm

which ROM is that you are using for QDOS?


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

Re: Odd behavour

Postby pjw » Sat Feb 03, 2018 11:23 pm

Pr0f wrote:which ROM is that you are using for QDOS?

The behaviour of Martin's sample is distinctly odd! Behaves the same in JS and Minerva 1.98
Try:

Code: Select all

1047 b = two
1050 a(x)=b

then you get the 'correct' result.
The example I gave works identically in SMSQ/E, JS and Minerva (provided you add enddef to
procs one and two). Ie it conforms to the statement Pr0f gave of the scope of locals, which
Martin's sample appears not to do.


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
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 1:04 am

What happens here is that calling function 'two' has a side effect of incrementing x by one.
In QDOS, a(x) is evaluated first as the variable to be set (when x = 2), and then 'two' is called which returns 200 and increments x to 3, but the result is stored in a(2) because x was 2 at the start of the assignment.
In SMSQ/E however, a(x) appears to be evaluated after calling 'two' so this evaluates to a(3), which is then assigned the result of the function.
I'm not sure which one is 'correct' according to the definition of S*BASIC. It might as well be that this behaviour was never anticipated so both could be right (or wrong)!

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 9:23 am

janbredenbeek wrote:What happens here is that calling function 'two' has a side effect of incrementing x by one.
In QDOS, a(x) is evaluated first as the variable to be set (when x = 2), and then 'two' is called which returns 200 and increments x to 3, but the result is stored in a(2) because x was 2 at the start of the assignment.
In SMSQ/E however, a(x) appears to be evaluated after calling 'two' so this evaluates to a(3), which is then assigned the result of the function.

Yes, that seems to explain the logic.
I'm not sure which one is 'correct' according to the definition of S*BASIC. It might as well be that this behaviour was never anticipated so both could be right (or wrong)!

The fact that it was changed under SMSQ/E to something that seems more 'correct' to me, is all the confirmation I need ;)


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 10:10 am

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...
To make matters more compatible, x as a parameter to 'two' would be automatically local, and help get rid of the bug !
Thanks very much for reportig this awkward bug.
Steve.



Return to “Software & Programming”

Who is online

Users browsing this forum: No registered users and 1 guest