Locomotive BASIC renum bug

[zhulien]

Interesting today, I found a bug with the renum command.  It does't renum the line number which is part of chain merge.

You could argue that it it isn't a bug, but... it goes against all documentation of what renum does without mentioning any exceptions for chain merge.

There is nothing in the documentation that says you must jump to one of the merged line numbers - and if you want to make a modular basic program given we now can have truely massive ones on sdcards...  interestingly, delete range does work with renum.

anyway...

Lets take this example (it is 3 files)

TEST.BAS

Code Select Expand

10 g$="global"
20 CHAIN MERGE "test1.bas", 30, DELETE 1000-1500
30 GOSUB 1000:GOSUB 70
40 CHAIN MERGE "test2.bas", 50, DELETE 1000-1500
50 GOSUB 1000:GOSUB 70
60 END
70 PRINT m$,g$
80 RETURN

TEST1.BAS

Code Select Expand

1000 m$="A"
1010 return

TEST2.BAS

Code Select Expand

1000 m$="B"
1010 return
What this proves is that you can write truly modular and reusable library code in locomotive BASIC. g$ is just a variable to prove that variables retain their value after the chain merge.  m$ is just a message that is changed upon each module.  

How to make a library, for example... you could use f% as a function number or f$ as a function number and within the merged file, perform the appropate logic.  As locomotive BASIC doesn't have real functions with parameters and return values, be consistent and use some variables consistently like registers... r$ for example for result.

This in combination with my other suggestions...

Code Select Expand

1000 IF blah THEN ELSE 1020
1010   blah2
1020 'END IF

1000 IF blah THEN ELSE 1030
1010   blah2
1020   goto 1050
1030 'ELSE
1040   blah3
1050 'END IF

Unfortunately you can't put the chain merge within a gosub and expect it to return, seems the call stack is lost with the chain merge - which is why we go to the next line upon the chain merge occurring which then does the gosub.

To demonstrate the renum bug, just renum 1,1 and look at the code.  To fix it again, just renum.  don't forget to save without the 1000- as part of test.bas, because... it will modify the DELETE range when renum is done.

[zhulien]

Also, if you used a function number, you can at the entry point (line 1000), use ON f% GOTO function1, function2, function3 etc... or ON f% GOSUB if you prefer

[andycadley]

I suspect it's an intentional limitation. If you renumbered the CHAIN MERGE without renuming the code you load to match, things are going to break anyway.

In fact, checking the 6128+ manual:

"RENUM takes care of all GOSUB, GOTO and other line calls. However, line number references within string expressions, such as those issued in KEY commands, are not altered; neither are line references within REM statements, nor the «line number expression» in a CHAIN or CHAIN MERGE command."

[zhulien]

I stand corrected... it's the online documentation that is incorrect - not the official documentaiton - just checked the 664 manual.  I don't have a 464 one to see what that says.

Every is negatively impacted by chain merge in addition to Gosub.