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

[Luca Boasso]

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?

On Fri, Oct 30, 2020 at 12:38 PM Andreas Pirklbauer <
andreas_pirklbauer at yahoo.com> wrote:

> Jörg, see inline comments:
>
>     > Andreas
>     >
>     > >    1. Global case variables p in a case statement CASE p OF .. END
>     >
>     >Module initializers can not have a CASE. But this seems acceptable.
>
> Module initializers can always call a procedure Init, where a local
> variable is
> assigned to the global one, and the CASE statement uses only the local one.
>
>     >>
>     >>    2. Assignments *to* case variables p *within* the scope of a
> CASE statement
>     >
>     >If needed, declare a local variable and „mirror“ p. Seems an
> acceptable restriction.
>
> I don’t see why one *should* be allowed to assign something *to* a case
> variable in
> the first place. It breaks the whole idea of the type case statement,
> namely that
> the type of the case variable remains *constant* among the statements of a
> particular
> branch of the case statement. But yes, using a local variable is always
> possible.
>
>     >>
>     >>    3. Passing a pointer case variable p as a VAR parameter to a
> procedure P(p)
>     >
>     > I could imagine an example where you have a CASE in a loop and the
> procedure
>     > P returns an object with another type to be
>     > processed by the next iteration.
>     > Here the „trick“ with the local variable as mentioned above can help
> as well.
>     > Restriction for such     >rare cases seems acceptable.
>     >
>
> Seems like an edge case. Never seen! But yes, here too, local variables
> can be used.
>
>     > Jörg
>
> All in all, the restrictions seem quite acceptable. The reason for
> *keeping* the
> type case statement is mainly efficiency. Nevertheless, I could live
> without it
> and use only *IS*.
>
> --
> 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/20201030/be3b9fa1/attachment-0001.html>