[Oberon] Numerical CASE Statements in Project Oberon (was: RISC.img)

[Chris Burrows]

> 
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Jan de Kruyf
> Sent: Friday, 6 November 2015 8:37 PM
> To: Paul Reed; ETH Oberon and related systems
> Subject: Re: [Oberon] RISC.img
> 
> 2. Question:
> I see that the 'numerical' CASE implementation is missing in ORP.Mod,
> although it is in the language spec and although we might reasonably
> expect people to port programs from O2 to O7.
> 
> Would it be in the interest of the community for me to try and
> implement that part, at least for constant labels?
> 

Don't even think about implementing it unless you are planning to do it properly - a half-baked solution would be worse than none. e.g. I would expect a complete solution to include the implementation of a RISC6 (or RISC5.1 maybe?) processor which has indexed-branch statements. 

> I am aware that 1. a table driven CASE might take up some codespace
> and 2. that coding it as an IF THEN ELSIF THEN will bring no speed
> advantage. But at the same time there are many instances where a CASE
> statement is easy to write and convenient to read.
>

Apart from 'convenience' an advantage of table-driven CASE over IF THEN ELSIF is that each case usually has a constant performance overhead - there is no preferential treatment for any of the cases. This contrasts with IF THEN ELSIF ladders where it takes longer to reach statements at the end to execute them than those at the beginning. 

However, if constant performance overhead is a requirement it does not necessarily need the existence of a 'numerical' CASE. Another possible way of achieving a constant performance overhead with Oberon is to use an array of procedures where each array element corresponds to each case label. 

> 
> 3. Question:
> Why does the numerical CASE have no ELSE part anymore in O7. It is a
> very convenient error catcher. (i.e. when not all cases are catered
> for, the program does not silently fall through without warning.)
> 

I can't see anywhere in the report that states that "when not all cases are catered for, the program silently falls through without warning". That is not necessarily a correct assumption - one alternative possibility might be to raise an error. Other error-handling behaviour including how to handle duplicate labels, descending ranges etc. etc. would also need to be specified for a complete solution. Implementation limits would also need to be specified e.g. minimum / maximum value of labels etc. 

There might be other considerations but that is all I can think of for now,

Regards,
Chris

Chris Burrows
CFB Software
http://www.astrobe.com