[Oberon] Numerical CASE Statements in Project Oberon

[Jan de Kruyf]

Good morning David,

> or perhaps he hasn't made a final determination on CASE.

I like to believe that too.
Ultimately the proof of the pudding is in the eating. Things have changed
before in Oberon.
Sometimes on good scientific grounds, sometimes on the basis of practical
deliberations.

What Wirth always _has_ argued against is needless inflation of the
language just because of 'feature fever'.
And I agree wholeheartedly with that sentiment.

At the same time of course we are slowly getting to the point where we need
to carry the idea forward ourselves.

cheers,

j.



On Mon, Nov 23, 2015 at 1:20 AM, David Egan Evans <sinuhe at xmission.com>
wrote:

> It appears that since 2013 (2011?) Wirth had intended type extension use
> of CASE only as a type guard (similar to its use in Pascal with variant
> records). See the second version of the differences document for this.
>
> What's curious is that though he added the type guard use of CASE in the
> Report this year, he didn't otherwise remove CASE from it as he indicated
> (differences document), and implemented in PO2013. Perhaps this was a
> concession on Wirth's part in the Report, or perhaps he hasn't made a final
> determination on CASE.
>
> Either way, I doubt he'll extend CASE in PO2013. CASE is now like Pascal
> again, but without the requirement for a trap (and thus no need for ELSE. A
> trap is implementation dependent). I think it more likely that he'll remove
> CASE from the Report, other than its use as a type guard for RECORD
> extension. However, with Wirth you never know.
> --
> http://oberon07.com
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20151123/4a04116d/attachment.html>