Introducing Structured Extended BASIC and TiCodEd

[+dhe]

There is plenty of room on that form, how about just displaying both combinations?

[SteveB]

I found an easy way to preserve the 16x16 when toggling and included a "clear" button. But I am not happy with the whole tab. It is sluggish and the preview doesn't work when you have a scale rate other than 100% for the monitor. I think of a mayor re-write after the next release, wich is close to complete and goes into testing soon. I have some additinal features in mind and will think of a better usage of the screen. 

[+TheBF]

6 minutes ago, SteveB said:

I found an easy way to preserve the 16x16 when toggling and included a "clear" button. But I am not happy with the whole tab. It is sluggish and the preview doesn't work when you have a scale rate other than 100% for the monitor. I think of a mayor re-write after the next release, wich is close to complete and goes into testing soon. I have some additinal features in mind and will think of a better usage of the screen. 

From the wisdom of Fred Brooks

"The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] 

Hence plan to throw one away; you will, anyhow."    

 

“The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.”   

                                                                     ― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

 

May the Forth Force be with you

 

For more of these: https://www.goodreads.com/author/quotes/3174788.Frederick_P_Brooks_Jr_ 

 

[SteveB]

Conway’s law
“Organizations which design systems […] are constrained to produce designs which
are copies of the communication structures of these organizations.”  - Melvin Conway, Computer scientist

 

What does that mean for a single developer isolated by CoViD-19 in his home??

 

But I really prefer agile approaches ... better done than perfect, and moving on from this baseline, even if it sometimes mean starting anew with more knowledge.

Those who think too much get nothing done. Those who not think enough don't get anything useful done, though.  

 

So I think the new character editor will start small and lean on a different base and grow from there in small increments. No beast planned.

 

PS: “As time passes, the system becomes less and less well-ordered. Sooner or later the fixing cease to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. ...A brand-new, from-the-ground-up redesign is necessary.”

 

[+dhe]

If you are looking for idea's - it would be nice to be able to store and playback designs, because many times, the sprites you are designing are going to played in a sequence to form some type of animation. Like TI Invaders, when your missile strikes and enemy ship.

[+Vorticon]

Any possibility of implementing a CASE statement by any chance? A very useful structure for sure...

[SteveB]

On 7/7/2021 at 3:56 PM, Vorticon said:

Any possibility of implementing a CASE statement by any chance? A very useful structure for sure...

Haven't thought on this one yet. The line-concept and line-length of XB limit are limiting the options. We have the ON x GOSUB and the IF THEN [ELSE] as a possible target in Standard XB. What would you want as a CASE ? Pascal for example is quite versatile, more than possible here. Currently SXB commands do not spread over lines, so this would be some work on extending the translator. 

 

One simple variant could be

CASE a OF
   1 : PRINT "Hello"
   2 : PRINT "World"
   3, 4 : PRINT "Goodbye"
END-CASE

could be transcoded to

IF a=1 THEN PRINT "Hello"
IF a=2 THEN PRINT "World"
IF a=3 OR a=4 THEN PRINT "Goodbye"

An ELSE branch would not be possible as you don't know if one branch was already true, except you collect all conditions and add a 

IF NOT (a=1 or a=2 or a=3 or a=4) THEN PRINT "ELSE-Branch"

Not very neat. 

 

I wonder if this would be worth the effort. What do you think?

 

 

[+RXB]

29 minutes ago, SteveB said:

Haven't thought on this one yet. The line-concept and line-length of XB limit are limiting the options. We have the ON x GOSUB and the IF THEN [ELSE] as a possible target in Standard XB. What would you want as a CASE ? Pascal for example is quite versatile, more than possible here. Currently SXB commands do not spread over lines, so this would be some work on extending the translator. 

 

One simple variant could be

CASE a OF
   1 : PRINT "Hello"
   2 : PRINT "World"
   3, 4 : PRINT "Goodbye"
END-CASE

could be transcoded to

IF a=1 THEN PRINT "Hello"
IF a=2 THEN PRINT "World"
IF a=3 OR a=4 THEN PRINT "Goodbye"

An ELSE branch would not be possible as you don't know if one branch was already true, except you collect all conditions and add a 

IF NOT (a=1 or a=2 or a=3 or a=4) THEN PRINT "ELSE-Branch"

Not very neat. 

 

I wonder if this would be worth the effort. What do you think?

 

 

Hmm why not use ON A GOTO or ON A GOSUB?

That would be faster and ON A GOTO in XB is actually in GPL a     CASE A       command.

[+jedimatt42]

4 hours ago, RXB said:

Hmm why not use ON A GOTO or ON A GOSUB?

That would be faster and ON A GOTO in XB is actually in GPL a     CASE A       command.

I think it is too common for the cases of 'A' to be non-linear. If I recall, the ON A GOTO 10, 20, 30, 40, 50  implies that A can have values 1 through 5 as the values of A map positionally to the line number list following GOTO. If A has values 27, 28, 50, 51, 52, 53, 107, it is hard to fit into the ON A GOTO structure.

 

I suppose... 

 

You could collect the set of case values into an array. Then on evaluation, you check your condition value by iterating across that arrow. If it matches a value in the array, that position would be the index into the GOTO line list. If it falls through to not being found, it could be the 'default' case. It would be very challenging to implement the fall through structure of C switch statements, but they are undesired enough, that it could be omitted.

 

https://en.wikipedia.org/wiki/Switch_statement

[+RXB]

46 minutes ago, jedimatt42 said:

I think it is too common for the cases of 'A' to be non-linear. If I recall, the ON A GOTO 10, 20, 30, 40, 50  implies that A can have values 1 through 5 as the values of A map positionally to the line number list following GOTO. If A has values 27, 28, 50, 51, 52, 53, 107, it is hard to fit into the ON A GOTO structure.

 

I suppose... 

 

You could collect the set of case values into an array. Then on evaluation, you check your condition value by iterating across that arrow. If it matches a value in the array, that position would be the index into the GOTO line list. If it falls through to not being found, it could be the 'default' case. It would be very challenging to implement the fall through structure of C switch statements, but they are undesired enough, that it could be omitted.

 

https://en.wikipedia.org/wiki/Switch_statement

If you got to that point with "A" variable that hard to use, you have demonstrated you never thought it out completely.

This is akin to painted into a corner!

[+Lee Stewart]

6 hours ago, RXB said:

Hmm why not use ON A GOTO or ON A GOSUB?

That would be faster and ON A GOTO in XB is actually in GPL a     CASE A       command.

 

The GPL CASE statement is not really a true CASE statement. It is an indexed branch. There is no condition testing. A true CASE statement is simply a convenient and relatively foolproof way of writing a multiple IF ... ELSEIF ... ELSEIF ... [ ELSE ] statement with an optional fall-through, default instruction. It would likely take some pretty clever coding to get this right in XB—especially with the length limitation on an XB line. It could probably be done with GOSUBs or GOTOs, but that line limitation can still be a gotcha.

 

It could be done in XB with multiple statements similar to what @SteveB proposed, but for true CASE format, it should skip all tests after success—something like transcoding

CASE a OF
   1 : PRINT "Hello"
   10 : PRINT "World"
   23, 34 : PRINT "Goodbye"
   default: PRINT "No match"
END-CASE

to

IF a=1 THEN PRINT "Hello" :: GOTO case-end
IF a=10 THEN PRINT "World" :: GOTO case-end
IF a=23 OR a=34 THEN PRINT "Goodbye" :: GOTO case-end
PRINT "No match"
case-end:
! Next statement

or whatever works in TICodEd. The above would even accommodate multiple statements between IFs.

 

...lee

[+RXB]

2 hours ago, Lee Stewart said:

 

The GPL CASE statement is not really a true CASE statement. It is an indexed branch. There is no condition testing. A true CASE statement is simply a convenient and relatively foolproof way of writing a multiple IF ... ELSEIF ... ELSEIF ... [ ELSE ] statement with an optional fall-through, default instruction. It would likely take some pretty clever coding to get this right in XB—especially with the length limitation on an XB line. It could probably be done with GOSUBs or GOTOs, but that line limitation can still be a gotcha.

 

It could be done in XB with multiple statements similar to what @SteveB proposed, but for true CASE format, it should skip all tests after success—something like transcoding

CASE a OF
   1 : PRINT "Hello"
   10 : PRINT "World"
   23, 34 : PRINT "Goodbye"
   default: PRINT "No match"
END-CASE

to

IF a=1 THEN PRINT "Hello" :: GOTO case-end
IF a=10 THEN PRINT "World" :: GOTO case-end
IF a=23 OR a=34 THEN PRINT "Goodbye" :: GOTO case-end
PRINT "No match"
case-end:
! Next statement

or whatever works in TICodEd. The above would even accommodate multiple statements between IFs.

 

...lee

Ok what do you mean not a TRUE CASE statement?

Spoiler

GC0F4  ADD  @FIELD+3,@FIELD+1 Add to low byte
* Branch to evaluation procedure for TAG
       SUB  >30,@TAG          >30 = "0"
       CGE  0,@TAG            If TAG < "0" ILLEGAL CHAR
       BR   ERRUC1
       CGT  >0A,@TAG          TAGS "0" to ":"
       BS   GC11C
       CASE @TAG
       BR   TAG0              "0" RELOCATABLE LENGTH
       BR   LDTG              IGNORE "1" TAG
       BR   LDTG              IGNORE "2" TAG
       BR   ERRUC1            No external REF "3"
       BR   ERRUC1            No external REF "4"
       BR   TAG5              "5" relocatable entry DEF
       BR   TAG6              "6" Absolute entry    DEF
       BR   TAG7              "7" check sum
       BR   LDTG              "8" ignore check sum
       BR   TAG9              "9" Absolute LOAD address
       BR   LDDNE   

How is this not a CASE statement in GPL? Please explain how this is not a CASE statement in GPL?

[moulinaie]

On 12/12/2020 at 6:30 PM, Vorticon said:

while S=0
CALL KEY(0,K,S)
wend

 

160 IF NOT (S=0) THEN GOTO 190
170 CALL KEY(0,K,S)
180 GOTO 160

 

Hi !

 

Just an idea, when you translate the WHILE/WEND structure, it would be faster to do this:

 

160 GOTO 180
170 CALL KEY(O,K,S)
180 IF S=0 THEN 170

The "GOTO" is taken only once instead of every iteration, the TEST is faster as you don't have to use NOT(TEST).

 

Generally, this structure should be faster:

 

WHILE TEST
... intructions...
WEND

line n   GOTO line m
line n+1 ...instructions ...
line m   IF TEST THEN n+1

Guillaume.

[+Lee Stewart]

9 hours ago, moulinaie said:

On 12/12/2020 at 12:30 PM, Vorticon said:

while S=0
CALL KEY(0,K,S)
wend

 

160 IF NOT (S=0) THEN GOTO 190
170 CALL KEY(0,K,S)
180 GOTO 160

 

Hi !   Just an idea, when you translate the WHILE/WEND structure, it would be faster to do this:

160 GOTO 180
170 CALL KEY(O,K,S)
180 IF S=0 THEN 170

The "GOTO" is taken only once instead of every iteration, the TEST is faster as you don't have to use NOT(TEST).

 

Generally, this structure should be faster:

WHILE TEST
... intructions...
WEND

line n   GOTO line m
line n+1 ...instructions ...
line m   IF TEST THEN n+1

Guillaume.

 

In both transcodings, the test should be initialized to the looping condition (S=0, etc.) before the loop.  <---@SteveB, please note.

 

Something like this for your solution, Guillaume:

WHILE TEST
... intructions...
WEND

line n   <set TEST to fail> :: GOTO line m
line n+1 ...instructions ...
line m   IF TEST THEN n+1

 

Edited July 9, 2021 by Lee Stewart
Correction/Clarification

[+TheBF]

8 hours ago, RXB said:

Ok what do you mean not a TRUE CASE statement?

  Hide contents

GC0F4  ADD  @FIELD+3,@FIELD+1 Add to low byte
* Branch to evaluation procedure for TAG
       SUB  >30,@TAG          >30 = "0"
       CGE  0,@TAG            If TAG < "0" ILLEGAL CHAR
       BR   ERRUC1
       CGT  >0A,@TAG          TAGS "0" to ":"
       BS   GC11C
       CASE @TAG
       BR   TAG0              "0" RELOCATABLE LENGTH
       BR   LDTG              IGNORE "1" TAG
       BR   LDTG              IGNORE "2" TAG
       BR   ERRUC1            No external REF "3"
       BR   ERRUC1            No external REF "4"
       BR   TAG5              "5" relocatable entry DEF
       BR   TAG6              "6" Absolute entry    DEF
       BR   TAG7              "7" check sum
       BR   LDTG              "8" ignore check sum
       BR   TAG9              "9" Absolute LOAD address
       BR   LDDNE   

How is this not a CASE statement in GPL? Please explain how this is not a CASE statement in GPL?

This is a good question. From what I can read there are many differing ideas on case statements that echo down through the history of computing.

 

My take on these discussions to the question: "Is this a case statement?" 

 

 It is if you say it is.  

 

https://www.encyclopedia.com/computing/dictionaries-thesauruses-pictures-and-press-releases/case-statement

 

Some things that people discuss. (argue about)  

• Is it a re-organized if,then.else mechanism
• Does it have a fall-through clause (Pascal style is No)
• Does it break out early at a specific case like switch in C or are all "cases" evaluated after the one that is found.
• Can compilers optimize it well
  • In this area, a computed table like GPL has, is often the end result of the optimized compilation. (but not always)
  • The high level language may provide lots of bells and whistles in the syntax but distills it into a vector table. 
  • GPL makes you set it up yourself since the compiler is more akin to an assembler.

 

Clearly the "correct" solution is a programmable programming language.   (tongue placed firmly in cheek)

 

[+jedimatt42]

9 hours ago, RXB said:

Ok what do you mean not a TRUE CASE statement?

  Reveal hidden contents

GC0F4  ADD  @FIELD+3,@FIELD+1 Add to low byte
* Branch to evaluation procedure for TAG
       SUB  >30,@TAG          >30 = "0"
       CGE  0,@TAG            If TAG < "0" ILLEGAL CHAR
       BR   ERRUC1
       CGT  >0A,@TAG          TAGS "0" to ":"
       BS   GC11C
       CASE @TAG
       BR   TAG0              "0" RELOCATABLE LENGTH
       BR   LDTG              IGNORE "1" TAG
       BR   LDTG              IGNORE "2" TAG
       BR   ERRUC1            No external REF "3"
       BR   ERRUC1            No external REF "4"
       BR   TAG5              "5" relocatable entry DEF
       BR   TAG6              "6" Absolute entry    DEF
       BR   TAG7              "7" check sum
       BR   LDTG              "8" ignore check sum
       BR   TAG9              "9" Absolute LOAD address
       BR   LDDNE   

How is this not a CASE statement in GPL? Please explain how this is not a CASE statement in GPL?

No one is saying it isn't a GPL case statement.

 

However the GPL's CASE statement is extremely limited with respect to the classic computer science capabilities of a 'switch' statement.

 

Maybe by 'classic' I intend the word 'common'

[moulinaie]

2 hours ago, Lee Stewart said:

 

In both transcodings, the test should be initialized to the looping condition (S=0, etc.) before the loop.  <---@SteveB, please note.

 

Something like this for your solution, Guillaume:

WHILE TEST
... intructions...
WEND

line n   <set TEST to fail> :: GOTO line m
line n+1 ...instructions ...
line m   IF TEST THEN n+1

 

Great remark !

It depends on the program... In the case of the CALL KEY, yes, S=0 is required.

 

Some other programs may have initialized the variable to something.

 

But... the WHILE/WEND structure is not really correct for the CALL KEY loop, the best would be:

REPEAT

CALL KEY(0,K,S)

UNTIL S<>0

 

As the "S" value is needed for the test, as you underligned it.

 

Guillaume.

[+RXB]

12 hours ago, moulinaie said:

Hi !

 

Just an idea, when you translate the WHILE/WEND structure, it would be faster to do this:

 

160 GOTO 180
170 CALL KEY(O,K,S)
180 IF S=0 THEN 170

The "GOTO" is taken only once instead of every iteration, the TEST is faster as you don't have to use NOT(TEST).

 

Generally, this structure should be faster:

 

WHILE TEST
... intructions...
WEND

line n   GOTO line m
line n+1 ...instructions ...
line m   IF TEST THEN n+1

Guillaume.

Hmm RXB has

170 CALL KEY("",5,K,S) ! same as 170 CALL KEY(5,K,S) :: IF S=0 THEN 170

Or it has same thing

170 CALL KEY("123",5,K,S) ! same as 170 CALL KEY(5,K,S) :: IF K<>1 OR K<>2 OR K<>3 THEN 170 

Or RXB has

170 CALL ONKEY("123",5,K,S) GOTO 200,300,400 ! same as a huge XB number of lines

 

 

So this is covered 100% in RXB vs anything in any other XB made.

I just shows it has a WHILE WEND, CASE value and built in IF value THEN loops.

 

P.S. look at how little number of characters you have to type to do the same thing you would do in another language

with the added bonus of less lines to do exactly the same thing.

[+RXB]

3 hours ago, jedimatt42 said:

No one is saying it isn't a GPL case statement.

 

However the GPL's CASE statement is extremely limited with respect to the classic computer science capabilities of a 'switch' statement.

 

Maybe by 'classic' I intend the word 'common'

So C is compiled and GPL is compiled? Explain to me how C version of case is better when they are both functionally the same?

I looked up CASE for other languages and GPL works exactly the same and you have to make sure you do not do stupid things

like use a Floating Point in a Integer CASE or String Variable or Data Type, so making the claim that GPL case is not the same

strikes me as just flat out BIAS if anything.

[+OLD CS1]

In some instances of converting WHILE/WEND loops into TI BASIC, I have used something like this

10 FOR S=-1 TO 1
20 CALL KEY(0,K,S)
30 NEXT S

This particular construction obviously skips a second press of the same key which returns S=-1, but each instance is context-tailored.  That, and I am not certain of the performance hit but it, of course, can be measured.^*

 

Extended BASIC's restrictions on FOR/NEXT appearing in IF/THEN/ELSE statements can cause some problems in this type of conversion, but only minimally.  For example, this is illegal in Extended BASIC

25 IF K=64 THEN NEXT S

Some other BASICs, such as GW-BASIC, do support this construct.

 

DO FOREVER and similar WHILE loops are fun, as well.  Use a control variable which will never have the result of the FOR limit condition

10 FOR K=0 TO 255
20 REM DO SOME STUFF
30 CALL KEY(0,K,S)
40 REM DO SOME OTHER STUFF
50 NEXT K
60 PRINT "THIS LINE WILL NEVER EXECUTE"

 

Not sure if this is mentioned anywhere (I did not see it in the XB manual,) but the limit of a FOR statement is only evaluated at the start of the loop.  Thus, this snippet

5 A=5
10 FOR B=1 TO A*2
15 A=3
20 PRINT B
25 NEXT B

when run produces the output of numbers 1 through 10, not 1 through 6.

 

Another handy feature (from the TI Extended BASIC manual, page 87)

Quote

If initial-value exceeds limit at the beginning of the FOR-NEXT loop, none of the statements in the loop are executed. Instead execution continues with the first statement after the NEXT statement.

 

The implication of flow in a FOR/NEXT loop is the magic is not the NEXT statement, but rather it sends execution back to the beginning of the loop to see if the limit condition has been met.  Like a musical repeat in which the beginning, not the end, of the section is marked with the number of repeats.

 

* Approximately four seconds slower per 1,000 iterations in TI BASIC, eight seconds per 1,000 iterations in Extended BASIC.

[+Vorticon]

On 7/8/2021 at 1:21 PM, SteveB said:

Haven't thought on this one yet. The line-concept and line-length of XB limit are limiting the options. We have the ON x GOSUB and the IF THEN [ELSE] as a possible target in Standard XB. What would you want as a CASE ? Pascal for example is quite versatile, more than possible here. Currently SXB commands do not spread over lines, so this would be some work on extending the translator. 

 

One simple variant could be

CASE a OF
   1 : PRINT "Hello"
   2 : PRINT "World"
   3, 4 : PRINT "Goodbye"
END-CASE

could be transcoded to

IF a=1 THEN PRINT "Hello"
IF a=2 THEN PRINT "World"
IF a=3 OR a=4 THEN PRINT "Goodbye"

An ELSE branch would not be possible as you don't know if one branch was already true, except you collect all conditions and add a 

IF NOT (a=1 or a=2 or a=3 or a=4) THEN PRINT "ELSE-Branch"

Not very neat. 

 

I wonder if this would be worth the effort. What do you think?

 

 

It does not have to be very neat on the XB side as long as it works. It's just so much easier and clearer with a CASE statement when using ticoded. 

 

[+RXB]

This is much more clear and easy to read and much less to type in RXB:

 

170 CALL ONKEY("123",5,K,S) GOTO 200,300,400

 

You can also do this for the enter key and a string :

 

170 CALL ONKEY(CHR$(13)&"123",5,K,S) GOTO 1000,200,300,400 :: GOTO 170

 

CHR$(13) is the ENTER KEY

[SteveB]

On 7/9/2021 at 7:43 AM, moulinaie said:

Hi !

 

Just an idea, when you translate the WHILE/WEND structure, it would be faster to do this:

 

160 GOTO 180
170 CALL KEY(O,K,S)
180 IF S=0 THEN 170

The "GOTO" is taken only once instead of every iteration, the TEST is faster as you don't have to use NOT(TEST).

Hi Guillaume,

 

you are absolutely right, I figured this one out already myself and this is how the WHILE...WEND is handled since version 1.1. I did it differently in version 1.0 as it is better readable in the resulting XB code, especially when you nest WHILE...WEND. But while using the tool for myself I discovered that

1. I use REPEAT..UNTIL much more often 
2. Speed is king
3. Maintainability of the code in XB does not suffer that much

My goal with TiCodEd and SXB was always to produce XB code that could be maintained independently, I don't want anybody to be "locked in" with the tool. No evil empire lurking ... ?

 

Steve

[SteveB]

14 hours ago, Vorticon said:

It does not have to be very neat on the XB side as long as it works. It's just so much easier and clearer with a CASE statement when using ticoded. 

The main challenge for me is that TiCodEd currently works line-by-line, but there are two just use-cases to rework this. One is the CASE-Statement, another would be the breaking of the line length-limit by doing a GOSUB for BEGIN-END blocks. Version 1.2 is in testing for quite a while and might get released next week. It would be a good opportunity to play with this afterwards. I have no clue yet on how to inject the new lines, because you can't just append them at the end. They must be inserted before the first SUB Statement. 

 

Back to the CASE Statement. A flexible alternative would be a GOSUB-Routine for each branch.

CASE a OF
   1 : PRINT "Hello"
   2 : PRINT "World"
   3, 4 : PRINT "Goodbye"
   ELSE PRINT "U-oh!"  
END-CASE

could be done as

ON 1-(a=1)-2*(a=2)-3*(a=3 or a=4) GOSUB CASEELSE, CASE001, CASE002, CASE003
...

CASEELSE: PRINT "U-Oh" :: RETURN
CASE001: PRINT "Hello" :: RETURN
CASE002: PRINT "World" :: RETURN
CASE003: PRINT "Goodbye" :: RETURN

You would have a full XB line for each branch. Or should the RETURN be on the next line? There a quite some variants thinkable, i.e. splitting the line to a CASEVAR calculation and then a ON CASEVAR GOSUB line to fit more cases in.

 

Would this one fit your needs?

 

 case.sxb or as TIFILES in XB case

 

Or would the original IF-THEN work better?

 

[+Vorticon]

59 minutes ago, SteveB said:

The main challenge for me is that TiCodEd currently works line-by-line, but there are two just use-cases to rework this. One is the CASE-Statement, another would be the breaking of the line length-limit by doing a GOSUB for BEGIN-END blocks. Version 1.2 is in testing for quite a while and might get released next week. It would be a good opportunity to play with this afterwards. I have no clue yet on how to inject the new lines, because you can't just append them at the end. They must be inserted before the first SUB Statement. 

 

Back to the CASE Statement. A flexible alternative would be a GOSUB-Routine for each branch.

CASE a OF
   1 : PRINT "Hello"
   2 : PRINT "World"
   3, 4 : PRINT "Goodbye"
   ELSE PRINT "U-oh!"  
END-CASE

could be done as

ON 1-(a=1)-2*(a=2)-3*(a=3 or a=4) GOSUB CASEELSE, CASE001, CASE002, CASE003
...

CASEELSE: PRINT "U-Oh" :: RETURN
CASE001: PRINT "Hello" :: RETURN
CASE002: PRINT "World" :: RETURN
CASE003: PRINT "Goodbye" :: RETURN

You would have a full XB line for each branch. Or should the RETURN be on the next line? There a quite some variants thinkable, i.e. splitting the line to a CASEVAR calculation and then a ON CASEVAR GOSUB line to fit more cases in.

 

Would this one fit your needs?

 

 case.sxb or as TIFILES in XB case

 

Or would the original IF-THEN work better?

 

The problem with ON GOSUB is that the variable can only have discreet sequential integer values starting at 1, which would be very restrictive.

I much prefer the flexibility of IF/THEN at the expense of elegance.