Problem with parameter to a SuperBASIC machine code extension

[swensont]

> BTW: Has anyone tried to run my reflection toolkit with compiled code (IMHO NO chance with Turbo and most probably also not even with QLiberator).

I've not tried your toolkit, mostly because I don't care about line number with SuperBasic. I write all SuperBasic without line numbers and let my pre-processor do all of the dirty work. The code looks so much better with no line numbers. I can't imagine programming with C, Pascal, Perl, or awk with line numbers, so why do it with SuperBasic. (just my 2 cents).

Tim

[NormanDunbar]

What Tim said! I haven't used line numbers in Super basic for ages!

Cheers,
Norm.

[ql_freak]

Good news:

Today I finished the "main" program of the missing function, and it seems to work.

Bad News:

I'm programming top (mostly very easy) down (mostly very complicated) and the 2 (assembler) subroutines, which do the real work, must still be written (they are currently only dummies, but at least they are called from the main program[!]).

[ql_freak]

I've not tried your toolkit, mostly because I don't care about line number with SuperBasic. ... line numbers, so why do it with SuperBasic. (just my 2 cents).

You MUST bother with line numbers, if you want to merge another S(uper)BASIC program to your main program, e.g. a library SuperBASIC program (which only contains PROCedures and FuNctions)!

That's why I have started to write the Reflection Toolkit. With the REF_GETLNFREE%() S(uper)BASIC function and my "rn" (C) program it is now possible to merge ANY S(uper)BASIC program file which does not use GO TOs (SUBs, ...).

Now I'm trying (today I realized, that I most probably will succeed) to write a FuNction which allows to port programs which are using GO (TO/SUB/...).

Please note: Programs with GO... cannot be MERGEd directly, you first must port them. But this should be easy (if I will succeed).
Note 2: Ported programs using "my trick" will be slower than using GO... directly(!). Most often you won't notice it, but there may be programs (where a GO... is used in [deeply nested, often called] loops), which will be notably slower.

[swensont]

> You MUST bother with line numbers, if you want to merge another S(uper)BASIC program to your main program

Not if all of your programs don't have any line numbers. If I want to use a procedure written by someone else, I will covert it to not have line numbers.

Also, I don't use MERGE, I use "#include file_ssb". This adds the file name "file_ssb" to the existing program as it is processed.

Tim

[NormanDunbar]

You MUST bother with line numbers, if you want to merge another S(uper)BASIC program to your main program, e.g. a library SuperBASIC program (which only contains PROCedures and FuNctions)!

Nope! If you use Tim's excellent (and I cannot praise it highly enough!) Structured SuperBASIC utility, you never need a line number again. Even for GO TO, GO SUB and RESTORE, no line numbers are required and the code still works.

Merging other library functions? Simple, there's an "include" command which allows multiple depths of nested "includes" for as deep as you need to go, provided you don't run out of file channel in the channel table of course.

Tim gave his blessing to me to make some changes. These are based on Tim's version 2.7.2 --- available from https://github.com/SinclairQL/Structure ... /tag/2.7.2 and from Tim. Tim still uses that version as it does all he needs to do. I'm using 2.7.2g which is available from https://github.com/SinclairQL/Structure ... tag/2.7.2g.

I thoroughly recommend you give it a try.


Cheers,
Norm.

[Derek_Stewart]

Hi,

I try to never use GOTO, GOSUB and the RESTORE command is a nightmare.

I usually use SSB which when it first appeared was all I was looking for. so I use that by default now, which gave the use of labels instead of line number references.

If the Line Numbers could be not displayed in TK2 ED, would this encourage the use of Procedures and Functions rather that GOSUB and GOTO