[Oberon] How to write this program in Oberon-07?

[Joerg]

Oleg

In Oberon-07 CASE is mainly thought to allow a rather elegant syntax for type extensions. (No WITH DO anymore)
NW did not even implement the numeric case in his compiler.

My numeric CASE implementation generates a trap for all unmentioned labels.
If you want to overwrite this compiler behaviour you don‘t need an ELSE: just mention the labels explicitely and do nothing.

You could say: this is cumbersome but if you have a large CASE where you would have to mention a lot of labels to do nothing, CASE is not the right construct in the first place (use IF instead)
Although not a great choice for CASE even here it‘s not too cumbersome
(* with trap *)
CASE x OF
| 1: Out.String(“uno“)
| 100: Out.String(“cien“)
END

(* without trap *)
CASE x OF
| 1: Out.String(“uno“)
| 2..99:
| 100: Out.String(“cien“)
END

br
Jörg

> Am 28.01.2022 um 02:01 schrieb Oleg N. Cher <allot at bk.ru>:
> 
> Hi Chris and all,
> 
> But of course you are aware that the latest revisions of the Oberon-07 language report say nothing about the fact that CASE should warn the programmer about an encountered label that is not in the list?
> 
> Yeah, the report doesn't say anything about that.
> 
> So this question, as well as many non-obvious points in Oberon-07, are left to the language's implementers to solve. And in the description of Oberon-2 and Component Pascal there is explicitly about CASE behavior.
> 
> So ELSE for CASE could be useful to include at least ASSERT(FALSE). But since this is not possible, we make our poor programming even poorer.
> 
> 
> Chris Burrows пишет:
>> On Tue, Jan 25, 2022 at 4:06 AM Jörg <joerg.straube at iaeth.ch <mailto:joerg.straube at iaeth.ch>> wrote:
>>    __ __
>>    There is a long debate whether an ELSE in a CASE is something good
>>    or bad.____
>>    That’s a little bit comparable to LOOP/EXIT: At first sight ELSE
>>    looks hand. But if you really had to debug complicated code with a
>>    lot of CASE statements you will conclude that the ELSE is quite
>>    dangerous.____
>>    Let’s assume you forgot an important CASE. Instead of being trapped
>>    (default behaviour of an uncovered CASE without ELSE) the ELSE
>>    catches it, the code goes on with perhaps totally wrong variable
>>    settings and the code error (forgotten CASE) is mostly unnoticed!
>> I agree. Similar potential pitfalls can occur in IF-THEN-ELSIF ladders. It can be a good defensive programming technique to add to the end of these:
>> ELSE
>>  ASSERT(FALSE)
>> END;
>> That will trap current (or future, if related code is changed) possibilities that have been overlooked. As a real-life example of this I would have saved myself several hours of head-banging this week if problematic code I have been investigating had been implemented this way. I was able to replace it with a (more efficient) numeric CASE statement on this occasion.
>> --
>> Chris Burrows
>> CFB Software
>> http://www.astrobe.com
>> ------------------------------------------------------------------------
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon