Page 1 of 2

BASIC: Returning non-scalar values from Procs

Posted: Mon Nov 27, 2017 2:05 pm
by Sparrowhawk
Hi,

Does SuperBasic have some way of returning non-scalar values from procedures?

In some other current BASICs, I can return objects (eg VB) or pass in a pointer address to a structure, in effect do a pass by reference (eg PureBasic).

It's been a long time since I did any SuperBASIC coding, so I may have overlooked it, but I can't see any obvious way to to do so - maybe S*Basic has something?

I'd rather avoid having to use globals if at all possible.

PS - I could not find any references to pointers in Jan Jones' book.

Re: BASIC: Returning non-scalar values from Procs

Posted: Mon Nov 27, 2017 3:00 pm
by martyn_hill
Hi Sparrowhawk

Whilst only scalers can be returned directly from S*Basic FNs (SuperBasic or SBasic), both variants allow Arrays to be passed by reference in the parameter list of a PROC or FN.

e.g.

DIM a%(100)
b%=99
a%(b%)=32767
...
MyProc a%,b%
...
DEFine PROCedure MyProc(x,y)
x(y)=0
END DEFine

Would cause a%(99) to be reset from 32767 to 0 as a result of calling the procedure.

NB - I consciously changed the variable types from INTeger to F.P. in the formal parameter-list to highlight another 'curiosity' (and bone of contention for typed-data purists...) of S*Basic - namely that the types of x and y are inherited from the types of the actual parameters passed at run-time. Bad practice, but interesting...

Note that if you want to compile in TURBO, not only do the types of the actual parameters get 'coerced' in to the types defined in the formal-parameter list, but for non-scalers/arrays, you must also precede the PROC/FN definition with a REFERENCE x(0) for each named non-scaler in the formal list in order to match the S*Basic pass-everything-by-reference paradigm.

In fact S*Basic needs help in order to pass by value - you must force an 'expression' out of your actual parameter - e.g. by placing in its own pair of parentheses, e.g.

MyProc (a%), b%

Should be enough to leave a%(99) as 0 after return from the PROC. Or pass only a slice of the original array:

MyProc a%(0 to 9), b%

All good fun!

Re: BASIC: Returning non-scalar values from Procs

Posted: Mon Nov 27, 2017 3:13 pm
by tofro
martyn_hill wrote: NB - I consciously changed the variable types from INTeger to F.P. in the formal parameter-list to highlight another 'curiosity' (and bone of contention for typed-data purists...) of S*Basic - namely that the types of x and y are inherited from the types of the actual parameters passed at run-time. Bad practice, but interesting...
Disputable whether this is bad practice or a feature - The way it is, you can, for example, write a procedure that sorts an array regardless of whether it's a string or integer array. QLiberator used to come with an example program doing exactly that - And making it very clear that competing S*Basic compilers wouldn't be able to compile such programs.

Tobias

Re: BASIC: Returning non-scalar values from Procs

Posted: Mon Nov 27, 2017 3:20 pm
by martyn_hill
I'm all for it, myself :-)

I recall thinking in my Computing lectures at Uni how backward those strict-data-typed development platforms were in not allowing such flexibility :-)

That was back in Modula-2 days, mind you (showing my age)...

Re: BASIC: Returning non-scalar values from Procs

Posted: Tue Nov 28, 2017 8:17 am
by vanpeebles
martyn_hill wrote:That was back in Modula-2 days, mind you (showing my age)...
Is that the one with the spinning tapes and rows of flashing lights? :lol:

Re: BASIC: Returning non-scalar values from Procs

Posted: Tue Nov 28, 2017 8:47 am
by Zarchos
martyn_hill wrote:I'm all for it, myself :-)

I recall thinking in my Computing lectures at Uni how backward those strict-data-typed development platforms were in not allowing such flexibility :-)

That was back in Modula-2 days, mind you (showing my age)...
This is what I thought too, when I studied ADA for about 2 years, in a French Uni (in fact no : fortunately, not a University (which would be Facultés in French, but in an I.U.T,
Institut Universitaire de Technologie, where, contrary to the French 'facultés' you do have a lot to learn and you do have a lot of code to produce, exams every weeks, plus
projects to complete, be it alone or in groups. Studying from Monday 8' oclock to Saturday 12' oclock, and most of the time end of courses is 6 o'clock.
I then went to study at the Derby University and well if the maths were too dificult for me, the computer science courses were just an appalling farce).

Now, when you understand how 'safe' your code must be for everything that has to do with railway systems, missile guidance, or rockets, or devices used to heal people like
scanners or I.R.Ms, well : I do understand having a strongly typed language will allow the compiler to warn you of all possible errors, overflows and so on ... your running code could experience.
You can not add lettuces with carrots in ADA, unless you really know you are manipulating lettuces and carrots, and this is very intelligent.

Each programming language has its own vertues, and strong typed languages do have many vertues.

Re: BASIC: Returning non-scalar values from Procs

Posted: Tue Nov 28, 2017 5:07 pm
by martyn_hill
vanpeebles wrote:
martyn_hill wrote:That was back in Modula-2 days, mind you (showing my age)...
Is that the one with the spinning tapes and rows of flashing lights? :lol:
Alright, alright - not THAT old!

Re: BASIC: Returning non-scalar values from Procs

Posted: Tue Nov 28, 2017 8:11 pm
by NormanDunbar
Hmm. My first foray into professional computing involved spinning tapes and flashing lights. It was an ICL1966 running George 2. Compiling a (Cobol) program required two days as the compiler was run as a job and the results printed off during the night. Listings delivered next morning first thing.
Did I mention the program was written by hand on coding sheets and punched in by the punch girls? Unless we did it ourselves on a manual punch card machine!

Thankfully we upgraded to a 2966 running VME and finally got a screen editor so I could type my own code - still from coding sheets though, but I had the ability to compile there and then.

Those were (not) the days!

Cheers,
Norm.

PS. Sorry, I've gone off topic, again.

Re: BASIC: Returning non-scalar values from Procs

Posted: Tue Nov 28, 2017 10:32 pm
by stevepoole
Hi,
The nearest thing to 'C' style 'pointers' on the QL is possibly to reserve memory and PEEK and POKE values into it.
That way you get beyond the QL array integer limit of dimensions, and have the advantage that the memory is globally accessible if you wish.
If you are good enough to use 'pointers' correctly, you should be able to safely use such DIY 'arrays'.
Of course the safe way is to first write code in an error-checked language, then once tested, to move on to PEEking and POkEing.
But definitely not for beginners.
Regards,
Steve.

Re: BASIC: Returning non-scalar values from Procs

Posted: Tue Nov 28, 2017 11:25 pm
by JonS
Ah, good old George 2! I think XEKA was the Cobol compiler. As for VME, I still use it and the screen editor after 37 years.