Multiple IF THEN ELSE on the same line?

[Dbug]

While working on Encounter, I realized that the length of the program was more or less caused by many situations needed to do tests involving three possible combinations:
- If A and B then do something
- If A and C then do something else
- Do something else

A concrete example:
11370 IF (S$="TWI" )AND (TW=0) THEN PRINT"CROAK":GOTO11407
11371 IF (S$="TWI") AND (TW<>0) THEN PRINT"You don't have any":GOTO10000

Basically this should be like that:
IF (S$="TWI") THEN IF(TW=0)THEN PRINT"CROAK":GOTO11407 ELSE PRINT"You don't have any":GOTO10000

The question is: Without scoping operator, how do we know with certainty how the ELSE are handled?
Is it doing the ELSE regarding the S$="TWI" check, or the TW=0 check?

Basically the source code is littered with small one liner functions jumps just to handle this.

If someone has a definitive guide on how to handle multi-level IF THEN ELSE; please share

[Dbug]

I found a solution

[Dbug]

So, the solution is to do a negative check and use THEN ELSE:

Code: Select all

11370 IF (S$="TWI" )AND (TW=0) THEN PRINT"CROAK":GOTO11407
11371 IF (S$="TWI") AND (TW<>0) THEN PRINT"You don't have any":GOTO10000

becomes

Code: Select all

IF (S$<>"TWI") THEN ELSE IF(TW=0)THEN PRINT"CROAK":GOTO11407 ELSE PRINT"You don't have any":GOTO10000

[NekoNoNiaow]

Code: Select all

IF (S$<>"TWI") THEN ELSE IF(TW=0)THEN PRINT"CROAK":GOTO11407 ELSE PRINT"You don't have any":GOTO10000

Interesting but quite hard to read.
I guess this is another kind of syntax which is better left to be generated by a preprocessor from a higher level pseudo BASIC language with the required scoping.

[Dbug]

"Quite hard to read" is subjective.

Considering that complexity is one of the parameters that makes things difficult to understand, I would say that the two lines of IF are not much simpler to decode, and despite being almost idiomatic leave the room for errors where the second variable does not match the one in the other line

When I started C, I thought the idiomatic string copy implementation was hard to read, but now when I see while (*dest++=*src++); I don't even have to think about what it does because it has entered into my "idiomatic elements for this language" category (not be confused with the "idiotic elements" of course, which is a totally different ball of nonsensical madness )

But yes, it's probably something a real "BASIC optimizer" could do for you.

[retroric]

Hi,

For what it's worth, here's a small test I wrote (for a completely different matter that is however slightly related to your "Encounter" series...) to see whether (and how many) imbricated IF THEN ELSE statements worked in Oric BASIC:

I honestly was amazed it did work...

Code: Select all

10 L=1:GOSUB100
20 L=2:GOSUB100
30 L=3:GOSUB100
40 L=4:GOSUB100
50 END
100 IF L=1 THEN D=7 ELSE IF L=2 THEN D=5 ELSE IF L=3 THEN D=3 ELSE IF L=4 THEN D=2
110 PRINT "L=";L;", D=";D
120 RETURN

I do however vaguely remember there is a bug with the "ELSE" statement in the Oric, but I don't quite remember what is is, and I didn't encounter it in my test... I THOUGHT it was if you put 2 instructions after the ELSE, then only the first one got executed, but I wrote another small program to test that and it isn't the case, so the "ELSE" bug must be something different...

Code: Select all

200 L=0:A=0:B=0:GOSUB 300
210 L=1:A=0:B=0:GOSUB 300
220 END
300 IF L=0 THEN A=10:B=20 ELSE A=1:B=2
310 PRINT "L=";L;", A=";A;", B=";B
320 RETURN

I'm not sure if it is of any help but I thought it demonstrates that you could express your 3 cases in a single line as:

Code: Select all

IF condition1 THEN statement1 ELSE IF condition2 THEN statement2 ELSE IF condition3 THEN statement3

PS - I still hate this "basic" BASIC language though, because you still have to use GOTO's all over the place to achieve some (not so complex) execution flows... I do remember though how thrilled I was when I got GFA BASIC on the Atari ST (and then later, Visual Basic on WIndows...)

[Chema]

Okay, I might be completely misunderstanding the issue here, but is it related to the dangling else problem? If so, I am pretty sure the Oric BASIC interpreter acts either way, most probably by matching each ELSE to the latest IF that was 'seen'. In any case in a predictable way...

I must be totally out of point about what the question is.