Syntax Error?

[+mizapf]

Interestingly, the multiple statement line has somewhat gone out of fashion, although languages like C could easily have them. I sometimes shudder when I see Extended Basic code that I wrote long ago, trying to squeeze as much as possible on one line ... and now feel regret for doing that.

 

Is there a significant performance gain, or only saved memory space?

[Opry99er]

You know, Michael-- I'm not 100% sure. LOL

 

I know when I started using XB (having graduated from BASIC) I just saw it as "COOL" that you could do that. It became part of my style of coding.

 

I don't necessarily cram as much onto a line as I can, but I like to have "thoughts" on one line... If the program is a "book", the block in which the lines reside is a "chapter", I like to think of the multi-statement line as a "page" in a chapter in a book.

 

The reason I like using multi-statement lines is that I can start them with an IF-THEN and then complete the subsequent tasks that are dependent upon the IF THEN inside that line. Assuming the "IF" is false, the program skips the entire rest of the line and jumps to the next line. It is an easy way to organize and compartmentalize "thoughts" in code for me.

Edited March 27, 2015 by Opry99er

[Opry99er]

The joys of debugging a recursive GOSUB block escape me right now.

 

Let's just say I am knee deep in sh** and trying to dig my way out with some original TI joysticks-o-pain.

 

Good news is, I've squashed 5 or 6 so far and I think I am getting close...

 

 

 

Done... Code is well in hand, debugged, functional and KICK ASS if I do say so myself.

 

Anyway, I did away with the delay loop there. I basically did a "GOSUB Keyscan" in order to hold the screen until a key is pressed... then continued on with the RETURN to retrace my steps back toward the top of the code block. Works alot better than a delay loop. Lets the user stay in control of the menu and not have a delay dictated upon them.

 

I updated the LoBR thread with the new, updated, debugged, and functional block of code.

 

 

Thanks again, guys. This has been a really educational thread and it helped me more than you know.

Edited March 27, 2015 by Opry99er

[RXB]

 

 

 

Done... Code is well in hand, debugged, functional and KICK ASS if I do say so myself.

 

Anyway, I did away with the delay loop there. I basically did a "GOSUB Keyscan" in order to hold the screen until a key is pressed... then continued on with the RETURN to retrace my steps back toward the top of the code block. Works alot better than a delay loop. Lets the user stay in control of the menu and not have a delay dictated upon them.

 

I updated the LoBR thread with the new, updated, debugged, and functional block of code.

 

 

Thanks again, guys. This has been a really educational thread and it helped me more than you know.

A cool feature of RXB is a CALL KEY that is also a IF THEN ELSE.

 

10 CALL ONKEY("YyNn",5,K,S) GOTO 200,200,300,300

20 GOTO 10

is the same as

10 CALL KEY(5,K,S) :: IF K=89 OR K=121 then 200 ELSE IF K=78 OR K=110 then 300

20 GOTO 10

[Opry99er]

Hehe.... That is cool...

[+mizapf]

I know when I started using XB (having graduated from BASIC) I just saw it as "COOL" that you could do that. It became part of my style of coding.

 

Hehe ... this sounds a bit like my motivation from those times. Well, we knew that other BASICs allowed for muti-statement lines, but not our TI BASIC, so it's understandable that we made use of it.

 

I'm not fully sure, but I somewhat *hope* that the following lines were not from me.

 

 

32100 SUB FEIN(V,W)
32101 W=INT(W) :: V=INT(V) :: H$="123456789ABCDEF" :: VG=INT(V/8) :: WG=INT(W/8) :: VR=V-VG*8+1 :: WR=W-WG*8+1 :: CALL GCHAR(VG+1,WG+1,Q) :: Z=VR*2+INT(WR/4.1)-1
32102 W1=INT((WR/4.1-INT(WR/4.1))*4.1+.5) :: IF Q=32 THEN K=K+1 :: Q=K+32 :: C$=RPT$("0",16) ELSE CALL CHARPAT(Q,C$)
32103 C$=SEG$(C$,1,Z-1)&SEG$(H$,POS(H$,SEG$(C$,Z,1),1) OR 2^(4-W1),1)&SEG$(C$,Z+1,15) :: CALL CHAR(Q,C$) :: CALL HCHAR(VG+1,WG+1,Q) :: SUBEND

 

The worst problem with the multi-statement lines, as we see in your code, are with IF-THEN-ELSE constructs. While C and its descendants use braces to indicate blocks, there was always the question how to interpret ELSE statement1 :: statement2. Is statement2 a part of ELSE, or the next command?

[Opry99er]

True... I don't use ELSE all that much, however.

 

If I can, I just jump to the next program line. That acts as my ELSE in most circumstances.... Exceptions would be multi compares like KEYscans.

 

100 CALL KEY(0,K,S) :: IF S=0 THEN 100

 

150 IF K>51 THEN 100 ELSE IF K<49 THEN 100

200 ON K-48 GOSUB 1000,2000,3000

Edited March 27, 2015 by Opry99er

[Opry99er]

And yea... those lines are pretty rough. LOL!!

[+InsaneMultitasker]

 

32100 SUB FEIN(V,W)
32101 W=INT(W) :: V=INT(V) :: H$="123456789ABCDEF" :: VG=INT(V/8) :: WG=INT(W/8) :: VR=V-VG*8+1 :: WR=W-WG*8+1 :: CALL GCHAR(VG+1,WG+1,Q) :: Z=VR*2+INT(WR/4.1)-1
32102 W1=INT((WR/4.1-INT(WR/4.1))*4.1+.5) :: IF Q=32 THEN K=K+1 :: Q=K+32 :: C$=RPT$("0",16) ELSE CALL CHARPAT(Q,C$)
32103 C$=SEG$(C$,1,Z-1)&SEG$(H$,POS(H$,SEG$(C$,Z,1),1) OR 2^(4-W1),1)&SEG$(C$,Z+1,15) :: CALL CHAR(Q,C$) :: CALL HCHAR(VG+1,WG+1,Q) :: SUBEND

The worst problem with the multi-statement lines, as we see in your code, are with IF-THEN-ELSE constructs. While C and its descendants use braces to indicate blocks, there was always the question how to interpret ELSE statement1 :: statement2. Is statement2 a part of ELSE, or the next command?

 

Interesting... I find your IF..THEN sample code very easy to interpret. On the other hand, nested IF..THEN..ELSE statements can lead to much sorrow.

I actually prefer multi-line statements in my XB programs. The compact code and ability to group it all together appeals to me.

[senior_falcon]

True... I don't use ELSE all that much, however.

 

If I can, I just jump to the next program line. That acts as my ELSE in most circumstances.... Exceptions would be multi compares like KEYscans.

 

100 CALL KEY(0,K,S) :: IF S=0 THEN 100

 

150 IF K>51 THEN 100 ELSE IF K<49 THEN 100

200 ON K-48 GOSUB 1000,2000,3000

 

(Edit) !!!!!!!!!!Guess I remembered wrong! The following is not right!!!!!!!!!!

 

If I remember right, VALIDATE works with CALL KEY. So you could write this way:

100 VALIDATE("123")

110 CALL KEY(0,K,S)::IF S<1 THEN 110

120 ON K-48 GOSUB 1000,2000,3000

and then remember to change the validate if you want to scan the entire keyboard.

Edited March 28, 2015 by senior_falcon

[Opry99er]

^^Agreed^^

 

Multi-line statements are pretty important to avoiding GOTO spaghetti for me. Having written several utility programs and a few games, I think I am starting to get my rhythm with XB. At first it was stumble, stumble, luck into success, learn, stumble, stumble, repeat.

 

Now, while I'm still learning each time I try something new, I feel I have found a style which suits me and I have confidence that I can sit down and make XB do pretty much what I want.

 

TIdBiT has REALLY helped compartmentalize my thought process.

 

Anyway, sorry for the tangent.. But I think it is cool to look at different programs from different programmers and see differences... Nuances that are unique to the author.

[senior_falcon]

Looks like my memory is not what it used to be - my post #35 above is a bunch of baloney!

[Gazoo]

Looks like my memory is not what it used to be - my post #35 above is a bunch of baloney!

 

Hey, I like baloney! Especially on a sandwich.

 

The perfect Baloney sandwich has 2 pieces of white bread. Butter one piece and spread mustard on the other. Use 3 pieces of baloney and 2 pieces of american cheese, alternate them between the 2 pieces of bread. Starting at the bottom the layers should go like this - bread, baloney, cheese, baloney, cheese, baloney, bread. Serve with a dill pickle slice and potato chips. Heavenly!

 

Gazoo

[Opry99er]

Actually, that sounds absolutely delicious....

[RXB]

Guess I remembered wrong! The following is not right!

If I remember right, VALIDATE works with CALL KEY. So you could write this way:

100 VALIDATE("123")

110 CALL KEY(0,K,S)::IF S<1 THEN 110

120 ON K-48 GOSUB 1000,2000,3000

and then remember to change the validate if you want to scan the entire keyboard.

VALIDATE only works in

 

10 ACCEPT AT(24,3) VALIDATE("123") SIZE(1):A$

 

LOL just read your next post.

Edited March 28, 2015 by RXB

[senior_falcon]

I think what I was thinking about is this:

10 CALL KEY(3,K,S)

20 INPUT A$

and now INPUT will use a key unit of 3, which will not accept lower case letters until you do a CALL KEY(5,K,S)

 

Don't know how I got it so turned around, but next time I will verify before posting.