A case for the BASIC CASE statement

The CASE statement in BBC BASIC is introduced in manuals as a generalisation of the IF…THEN…ELSE statement to situations where there are more than 2 alternatives. Despite the part between the IF and THEN being a condition that is either true or false (values -1 or 0, respectively, in BBC BASIC), all the examples I have seen of the CASE statement do not involve such conditions. The value of the variable or expression following CASE is usually a value from user input, for example, what key is pressed. See, for example, BBC BASIC Reference Manual, Acorn Computers Limited, 1992, pp 84-86, the StrongHelp manual Basic, by Steve Drain and BBC BASIC V, a dabhand guide, Chapter 4, to be found at www.riscos.com/support/developers/basicv. The last two references include some rather obscure examples, but none involving several conditions with values true or false.

Every time I have needed a CASE statement it is as an alternative to nested IF…THEN…ELSE constructs which are neither as clear to understand nor as easy to put together compared to the CASE statement.

A simple example of what I might need is for three different actions according as a variable X satisfies either X <= 3, 3 < X <= 7 or X >7.

I have thought of a general method of dealing with this where one has n conditions C1, C2,…, Cn which take Boolean values B1, B2,…, Bn for a particular input. So each Bi is -1 (true) or 0 (false). Let
B = B1 + 2*B2 + 4*B3 + …. + 2^(n-1)*Bn.
In binary, B encapsulates precisely all 2^n possibilities. So this expression for B follows “CASE” in the CASE statement. Of course, one may need only a few of the 2^n values and so only that number of WHEN lines where the values following each WHEN will be integers in the range 0 to -(2^n – 1).

This recapitulates exactly how one uses bitfields as flags for cases in machine code. Clever C compilers transform switch statements so that their cases correspond to consecutive values of the byte/word holding the flags, and then use a multiple of that byte/word as an offset into a jump table. The big difference between C and interpreted languages like BASIC is that the latter have to evaluate the WHEN expressions at run time, whereas C can perform optimizations (perf) because it already knows what their values are.

Lua does not have a CASE statement; a matter which is regularly brought up by those relatively new to the language. But you can manufacture one by having tables of functions:

switch = function (action_table) return function (choice)
    local action = action_table[choice]
    if action then return action ( )
    else return action_table.default ( )
    end -- if
  end end -- function function
mycase = switch { [c1] = f1; [c2] = f2; .... }
mycase (when_value)

I’m a little unsure what the question is here…

BBC BASIC’s CASE statement is very similar to the switch-type statements in other languages, with a key difference (at least compared to C): the WHEN values are evaluated on the fly, and can be expressions.

Other languages get around this “limitation” of requiring constant values for case by means of the else if construct: David’s example might be coded thus in C:

if (x <= 3.3) {
  // Do something...
} else if (x <= 7.0) {
  // Do something else...
} else {
  // ...or even something else
}

However, the fact that BASIC’s CASE statement’s WHEN conditions are evaluated on the fly (an accident of interpretation vs. compilation, I assume) allows us to easily emulate the else if construct very neatly. The whole point of else if is that there are a sequence of conditions, and the first that’s found to be true gets accepted. In a similar way, BASIC takes the first WHEN that it finds to match the desired value, so if that desired value is TRUE, we get exactly the same behaviour with BASIC executing the first WHEN clause whose expression is found to be TRUE:

CASE TRUE OF
WHEN X <= 3.3
  REM Do something...
WHEN X <= 7
  REM Do something else...
OTHERWISE
  REM ...or even something else
ENDCASE

The value of the variable or expression following CASE is usually a value from user input

Blimey. That’s quite a generalization. I use CASE a lot. Here’s a typical example:

     180 : REPEAT
     190 :   SYS "Wimp_Poll",mask%, block% TO Event%
     200 :   CASE Event% OF
     210 :     WHEN 2:SYS "Wimp_OpenWindow", 0, block%
     220 :     WHEN 3:SYS "Wimp_CloseWindow", 0, block%
     230 :     WHEN 6:PROCMouse
     240 :     WHEN 7:PROCDragBox
     250 :     WHEN 8:PROCKeyPress
     260 :     WHEN 9:PROCSelection
     270 :     WHEN 17,18:PROCMessage
     280 :   ENDCASE
     290 : UNTIL finished%
     300 : SYS "Wimp_CloseDown"

Well – it’s sort of a value from user input, but not in the sense I think you meant.

A simple example of what I might need is for three different actions according as a variable X satisfies either X <= 3, 3 < X <= 7 or X >7.

CASE TRUE OF
WHEN X<=3:PROC<less equal>
WHEN X>7:PROC<more than>
OTHERWISE PROC<inrange>
ENDCASE

CASE is not quick, so an altenative might be:

DEFPROCinrange(X)
 IF X<=3 THEN PROC<less equal>:ENDPROC
 IF X<=7 THEN PROC<inrange>:ENDPROC
 PROC<more than>
ENDPROC

This is more effective if there are more checks.

The CASE construct can also be used for ‘lazy evaluation’:

CASE TRUE OF
WHEN <A>,<B>:<A OR B>
OTHERWISE <NOT(A OR B>>
ENDCASE

CASE FALSE OF
WHEN <NOT A>,<NOT B>:<A AND B>
OTHERWISE <NOT(A AND B>>
ENDCASE

@Clive
Your quote from my post is taken out of context, or maybe I didn’t make the context clear enough. I was referring to examples of using the CASE statement in the BBC BASIC manuals I have seen, not how programmers usually use it of which I have no idea. See the previous sentence to the one you have quoted, and you can check the examples in the manuals I have cited.

Thanks for other replies which I will mull over.

maybe I didn’t make the context clear enough

Not clear enough for me, certainly, but that’s probably more my fault than yours.

The CASE statement in BBC BASIC is introduced in manuals as a generalisation of the IF…THEN…ELSE statement to situations where there are more than 2 alternatives.

That is correct. One could write something like:

IF meh% = 1 THEN
  Do Something
ELSE
  IF meh% = 2 THEN
    Do Something Else
  ELSE
    IF meh% = 3 THEN
      Do Something Yet Again Different
    ELSE
      IF....

    ENDIF
  ENDIF
ENDIF

This sort of structure may work for a small number of choices, however when there are numerous choices – Wimp Poll events, or handling function keypresses, for instance – a CASE structure is much tidier.
You will note that Steve’s DEFPROCinrange example above uses multiple ENDPROCs, which some people may frown upon. Certainly, when you get above a certain complexity, CASE is tidier.

Despite the part between the IF and THEN being a condition that is either true or false (values -1 or 0, respectively, in BBC BASIC), all the examples I have seen of the CASE statement do not involve such conditions.

The answer is staring you straight in the face. The example in the BBC manual on page 85:

CASE GET$ OF
  WHEN "L", "l" : ...
  WHEN "R", "r" : ...
  WHEN "D", "d" : ...
  WHEN "U", "u" : ...
ENDCASE

Here, the logical TRUE/FALSE is implied. You are looking at the result of GET$. The first test, is it a “L” or an “l”? There will only be a yes or no answer here. Either it is an upper or lower case letter L, or it is not. If it is, then this is a logically TRUE statement, so the stuff that follows is executed. If not, we progress to the next line.

The next example in the BBC guide uses integers, opening the CASE statement with the value of the guess% variable. The first test is to see if guess% is equal to X%. If it is, you win. The next test is to see if it is one less than or more than X%. If it is, you were oh-so-close. Otherwise, you don’t win.

The format is a little different because rather than perform a direct comparison of something like you do with an IF statement, you specify what you want to check in the original CASE statement; and then each line basically checks whatever value is that line against that provided in the beginning.

Like this:

CASE A OF
  WHEN X   : This checks "is X the same as A?"
  WHEN Y   : This checks "is Y the same as A?"
  WHEN Z,Q : This checks "is Z or Q the same as A?"
  OTHERWISE: This happens if X, Y, Z, and Q are NOT the same as A.
ENDCASE

Granted, the two examples given are a bit crap. There’s another, arguably better, example on page 72 of dealing with keyboard input (under the section Inputting data).

I was referring to examples of using the CASE statement in the BBC BASIC manuals I have seen, not how programmers usually use it of which I have no idea.

Now, now.
Once you have an idea of what the keyword is supposed to do, it is exactly by looking at how and when other programmers use such structures that you will come to better understand how and when to employ the structure in your own programs.

Here’s one to consider. CASE is great when you have a simple known list of values that you wish to compare this with that. Poll events, Wimp messages, key press codes, ANSI colour codes, whatever.
But when it comes to complex situations (compare this and this against that minus this) or when you are writing a heuristic sort of function (such as an auto-scaling chart) where the data on both sides of the scale and vary, CASE is really not what you want to be using. To give an example of the latter, imagine a chart of atmospheric pressure. Normally the air pressure does not change that much. It will often vary between around 1010 and 1025. Now if you have a run of days where the pressure hangs around 1020, you’ll want your chart to cover maybe 5mbar +/- 1020 so that changes can be seen, because if your chart spans 30mbar to account for 1000 to 1030, then days like that will appear like a flat line.
Then every so often you’ll get an Ophelia or a Brian, meaning you can expect values closer to 965 and, I think, yesterday, Brian troughed at an extremely low LOW of 946. Once it has passed through, the pressure will be back to the usual 1010-1020ish. Now your chart may need to auto-scale itself to something like 70mbar (which, yes, is insane, but that’s an Atlantic storm for you). Dealing with the computation and plotting of that, and knowing when and where to place the guide lines, and how far apart. That’ll be a pile on complex IF statements. CASE won’t cut it here.

The book will tell you what CASE is. The other real-life examples and numerous programs will instruct you on how and when to use CASE.

Rick makes a good point. A manual for BASIC cannot be expected to be a tutorial on programming in general. The trouble with huge long IF THEN ELSEIF … statements is that they are hard to read (spaghetti logic) and sometimes involve unnecessary computation. The ideal is a program whose compiled code has no conditionals at all, only jumps. In the case of the Wimp_Polling loop, for example, the conditional bit is really only an artefact of the programming language used. In the RiscLua task library
the relevant code is:

while not quit do
  reason, err = sys (poll, self.mask or 0, b, self.time)
  -- use your own mask maybe
  action = handler[reason or "sys_error"]
  if action then  quit, err = action (self) end -- if
 end -- while

CASE is not quick

Is it any worse than some nested IF … THEN … ELSE? The issue, as I understand it, is that BASIC has to scan forward looking for the WHEN statements; doesn’t it have to do the same for the ELSE and ENDIF statements, too?

In the case of

CASE TRUE OF
WHEN X<=3:PROC<less equal>
WHEN X>7:PROC<more than>
OTHERWISE PROC<inrange>
ENDCASE

vs.

DEFPROCinrange(X)
 IF X<=3 THEN PROC<less equal>:ENDPROC
 IF X<=7 THEN PROC<inrange>:ENDPROC
 PROC<more than>
ENDPROC

doesn’t the CASE version benefit from not having to evaluate any of the conditional expressions after one has returned TRUE?

CASE is not quick

Unless it’s in a bit of code that gets executed one hell of a lot, this is a matter of no consequence whatsoever. And if part of your program is that heavily used, why isn’t that bit being done in assembler?

once you know the reason code you know exactly which handler to use.

A bit like the Basalt extensions to BASIC where you can do:

REGW @Wimp_OpenWindow FNOpenWindow

and the function is called whenever the event occurs.

Is it any worse than some nested IF … THEN … ELSE?

No, because that is poor, too, for the same reason that you give. Both are exacerbated by including a lot of code in the clauses, between WHENs or THEN|ELSE|ENDIF. It is the search for the next clause or ENDCASE|ENDIF that is the poor bit.

But a single-line IF is relatively much quicker.

doesn’t the CASE version benefit from not having to evaluate any of the conditional expressions after one has returned TRUE?

Because you exit the PROC, that is also so in the IF example. In that particular example I doubt there is any advantage, but a long list of conditions might. The CASE is more easily understood, though.

Unless it’s in a bit of code that gets executed one hell of a lot,

But I have seen many examples of just that, where there is a CASE structure in a loop. I do it myself, because it is just the convenient way to write editable code.

CASE is great when you have a simple known list of values that you wish to compare this with that.

With tongue-in-cheek, might I suggest ON...PROC for that?

<stir> If I wanted fast, I’d be using a switch() statement. </stir>

The ideal is a program whose compiled code has no conditionals at all, only jumps.

This is marginally relevant to that observation. Some years back nemo and I had a lengthy discusion of how to speed up CASE with precalculated jumps, This would be more like a SWITCH structure. I have held on to this as a long-term aim, but BASIC is not friendly to it.

where there is a CASE structure in a loop

Surely – but is the loop being executed millions of times? Could be, if it’s in a sorter with a big list to sort, say – and that really would be worth writing in Assembler.

The example I gave is in a loop – but it only goes round the loop once per WIMP poll. If every app being polled did that, it really wouldn’t matter a toss (unless you had say ten thousand apps running at once…)

it really wouldn’t matter a toss

A lot of poor BASIC programming practices do not really matter, because speed is rarely relevant in a desktop user environment. Nevertheless, I hate to see memory and speed used recklessly. ;-)

A lot of poor BASIC programming practices do not really matter, because speed is rarely relevant

That’s a different issue, though. It’s not poor practice to use CASE where it improves clarity, even if it hits speed – unless speed is actually important in a particular case. It very rarely is. Whereas clarity is generally important. (I’m a fine one to talk: my code is often as clear as mud.)

Some replies to the above.
The use of TRUE following CASE is mentioned in the dabhand online manual I quoted, but not in Acorn’s manual and not, as far as I can see, in Steve Drain’s Basic StrongHelp manual (Steve, your manual is nevertheless much appreciated). In this context (Clive), the dabhand example involves Boolean expressions which can be seen as conditions, but I don’t think this is very helpful for someone meeting the CASE construct for the first time. Have a look at it.

@Rick

Here, the logical TRUE/FALSE is implied. You are looking at the result of GET$. The first test, is it a “L” or an “l”? There will only be a yes or no answer here. Either it is an upper or lower case letter L, or it is not. If it is, then this is a logically TRUE statement, so the stuff that follows is executed. If not, we progress to the next line.

I did resalise this, but we are talking about manuals where readers are meeting the CASE statement for the first time. Surely the first examples should include those that refer transparently to conditions which are either true or false. It is a mistake to assume learners will be able to sort this out rather than be put off. Your example starting CASE GET% OF ….. only repeats what I have already referred to in the manuals.

I am being called for dinner, will read more of your long post later.

I have read through the rest of Rick’s ‘tutorial’, but it doesn’t answer, as some others have, the situation I described. Rick, thanks for your long explanation that you must have spent a long time writing, but I don’t need an explanation of the examples that I have already understood in the manuals.

My first thought on the CASE TRUE OF … method, is that it could look messy if the condition following WHEN is complicated; but, yes, I must look at it further.

I think CASE TRUE OF is a wonderful piece of “logical & concise, but brilliantly unclear” coding. The kind of thing one wrote in the days when one was trying to cram more logic into 32KB of memory on a BBC Model B than clarity would have allowed.

First up, this:

The ideal is a program whose compiled code has no conditionals at all, only jumps.

This might have made sense when programming a 6502. On the ARM, even the ARM2, taking a jump means two instruction cycles are lost (as the pipeline must refill). On later ARMs, longer pipelines but predictive execution. Still, if the processor has conditionals at zero cost, surely the ideal is a program whose compiled code has conditionals and no jumps?

Now to the CASE TRUE OF issue. Why does this cause people problems? What you are doing here is a little odd looking, but not out of the world odd.
Recall I wrote above the bit where “is X equal to A?” and “Is Y equal to A?”. Well, replace A with TRUE and you’re just stepping through the list with “is X TRUE?”, “is Y TRUE?”. The thing to remember here is that CASE will abort upon the first logically true statement:

X% = TRUE
Y% = FALSE
Z% = TRUE

CASE TRUE OF
  WHEN X% : PRINT "X"
  WHEN Y% : PRINT "Y"
  WHEN Z% : PRINT "Z"
ENDCASE

Will only print “X”, not “X” and “Z”.

Again, once you understand that you are performing a comparison between the statement given to the CASE command (whatever it may be) and the statement(s) given in each WHEN command, it does become a simple logic test. Either it matches, or it doesn’t. Leaving you to ponder if CASE TRUE OF was devised just to troll people. :-)

Speaking of trolling, let me provide an example of something that is proper BASIC accepted by the interpreter, but is insane troll logic.

X% = 1
PRINT FNa, FNb, FNc
END

DEFFNa
  X% += 1
DEFFNb
  X% += 1
DEFFNc
  X% += 1
=X%

Does this:

>RUN
       4       6       7
>

This is much akin to CASE TRUE OF. It is valid because it is logically sound and accepted by the interpreter. It is, however, horrible code for the two obvious reasons (function modifying a global and a function with three entry points). I’m inclined to think that anybody who writes code like that probably ought to rethink their algorithm instead of trying clever tricks…