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

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Fri Oct 30 18:38:28 CET 2020

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*.

More information about the Oberon mailing list