Jump to content
SteveB

Introducing Structured Extended BASIC and TiCodEd

Recommended Posts

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

Share this post


Link to post
Share on other sites

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. 

  • Like 1

Share this post


Link to post
Share on other sites
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_ 

 

  • Like 1

Share this post


Link to post
Share on other sites

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.”

 

  • Like 3

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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?

 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!

  • Sad 1

Share this post


Link to post
Share on other sites
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

  • Like 2

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Lee Stewart
Correction/Clarification

Share this post


Link to post
Share on other sites
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)

 

  • Like 2

Share this post


Link to post
Share on other sites
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'

  • Like 2

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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. 

 

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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

  • Like 1

Share this post


Link to post
Share on other sites
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?

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...