[Oberon] Serious type loophole in type case statements and a possible fix

[Andreas Pirklbauer]

    > the restrictions seems reasonable but they add quirks to a mostly regular
    > language, take time to understand and explain to a beginner.
    > It feels like they are not in the spirit of Oberon...all because of fear of
    > missing out on performance?

Good point. The implementation also has its quirks, but in the end
only adds a few lines of code to the compiler. The quirks from the
programmer’s point of view are indeed more problematic. How do
you explain to a programmer that he can’t make an assignment
*to* a case variable *inside* a case statement?

As I have stated earlier, I could live without the type CASE statement
and use only IS instead. I don’t think performance really matters all
that much, but I have no data to back this up - I just observe that in
a “typical” type case statement, e.g. in MenuViewers or TextFrames,
the case variable is not accessed all that often. So it’s hard to believe
that a few extra type guards will make a big difference.

It’s sort of the same question, whether one should re-introduce the
numeric case statement, when one can use the (slower) IF instead.

To be consistent, one should therefore perhaps say: Either one
keeps *both* the numeric CASE statement *and* the type
CASE statement, or neither of them. Would be a classical
Wirthian simplication. (numeric case statements already
are not implemented in the official Oberon-07 compiler).

Finally, there is still the issue of legacy code: From day one, the
type case statement (or WITH statement in earlier versions of
the language) has been used, eg in the Oberon viewer system.

And in the documentation, in the books, etc. For 30+ years.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20201030/3c3d97b0/attachment.html>