PRINT premonition

[Silvester]

Just puzzled by a odd problem I had with a SuperBASIC function, a trivial example is;

DEF FN weird$(a$)
a$=a$&a$ : RETurn 'gotcha'
END DEF

a$='hello'
PRINT a$\weird$(a$)\a$

You would expect the PRINT statement to first print the unaltered a$, a newline, 'gotcha', another newline then the altered a$. But the first a$ gets prematurely altered by the subsequent FN call! ;

hellohello
gotcha
hellohello

Minerva, JS and SMSQ/E all do the same. But if you repeat the PRINT statement with SMSQ/E it starts filling the screen with garbage (bad string ident?).

The original FN I wrote simply strips the next word from a calling string, reduces the string length accordingly, and returns the word. It works fine normally, just produced odd results when I checked it with a simple multiple PRINT statement as above.

[RWAP]

I think the problem is that the parameter is treated as a single element - although it is an unusual bug - and probably a very unusual circumstance.

[tofro]

I must say I can't see anything wrong with what you're observing (although I do admit it might look odd at the first glance):

For any PROCEDURE or FUNCTION that is called from SuperBASIC, Basic needs to evaluate all of the arguments before it actually calls the procedure or function - That's one of the fundamental concepts in BASIC and also true for PRINT.

In your specific case, BASIC sees three arguments for PRINT: a$, a function call and another a$ - what it has to do is remember where a$ is (because S*BASIC always handles string arguments for FN and PROC as references), call weird$ and evaluate the return value, remember again where a$ is and call PRINT with the three arguments. The fact that the program changes what actually is at the location "where a$ is", is called a side effect of the function - And that is always showing 'weird' results.

It is wrong to assume that BASIC would evaluate arguments (in your case those of PRINT) one after the other and PRINT them. The only thing that your program shows well is that FUNCTION side effects and mix of global and local variables can be very tricky to foresee and are thus commonly considered bad programming habit. A function should only affect its RETurn value, nothing else.

If the program is changed to have 3 PRINT calls instead of one, this should give the expected results of "hello", "gotcha" and "hello hello" - But is a different program

I have tried the program with QPC2 and SMSQ and couldn't see anything wrong with it. Behaves exactly as it should (but not like you want ).

This is BTW not only behavior of SuperBASIC - You can easily write the very same program with C, Pascal and (god beware) Java.

Regards,
Tobias

[Silvester]

I suspected as much, nicely put. Still throws SMSQ/E v319 a curveball though (repeat the PRINT).

[tofro]

I suspected as much, nicely put. Still throws SMSQ/E v319 a curveball though (repeat the PRINT).

I have tried this

Code: Select all

100 DEFine FuNction weird$(a$)
110 a$=a$&a$ : RETurn 'gotcha'
120 END DEFine
140 a$='hello'
150 PRINT a$\weird$(a$)\a$
160 PRINT a$\weird$(a$)\a$

piece of code in QPC2/SMSQ/E 3.16 and it works fine (well, with the quirk you observe.) Then the error you're seeing must have been introduced in one of the newer versions.

EDIT: Checked the SMSQ/E change log: No hints to changes in S*Basic between 3.16 and 3.19

Regards,
Tobias

[RWAP]

Which smsq/e v3.19 are you using?

I just tried it on QPC2 (smsq/e v3.08) - that demonstrates a different result:

hellohello
gotcha
hellohello

but the second print line gives:
gotcha
gotcha
hellohellohellohello

Even worse is if I add 4 print lines and then run the program a couple of times - see the attached screenshot:

smsqe-odd.gif (5.92 KiB) Viewed 3784 times

So this could explain the oddities experienced

[Silvester]

Gold SMSQ/E v2.90 (a good version as Tony Tebby put it when releasing v2.98) exhibits same result. Its moot because it works fine otherwise, just PRINT befuddles it.