<div dir="ltr"><div>the restrictions seems reasonable but they add quirks to a mostly regular language, take time to understand and explain to a beginner.</div><div>It feels like they are not in the spirit of Oberon...all because of fear of missing out on performance? <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 30, 2020 at 12:38 PM Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jörg, see inline comments:<br>
<br>
    > Andreas<br>
    ><br>
    > >    1. Global case variables p in a case statement CASE p OF .. END<br>
    ><br>
    >Module initializers can not have a CASE. But this seems acceptable.<br>
<br>
Module initializers can always call a procedure Init, where a local variable is<br>
assigned to the global one, and the CASE statement uses only the local one.<br>
<br>
    >>                                               <br>
    >>    2. Assignments *to* case variables p *within* the scope of a CASE statement  <br>
    ><br>
    >If needed, declare a local variable and „mirror“ p. Seems an acceptable restriction.<br>
<br>
I don’t see why one *should* be allowed to assign something *to* a case variable in<br>
the first place. It breaks the whole idea of the type case statement, namely that<br>
the type of the case variable remains *constant* among the statements of a particular<br>
branch of the case statement. But yes, using a local variable is always possible.<br>
<br>
    >>                            <br>
    >>    3. Passing a pointer case variable p as a VAR parameter to a procedure P(p)<br>
    ><br>
    > I could imagine an example where you have a CASE in a loop and the procedure<br>
    > P returns an object with another type to be<br>
    > processed by the next iteration.<br>
    > Here the „trick“ with the local variable as mentioned above can help as well.<br>
    > Restriction for such     >rare cases seems acceptable.<br>
    ><br>
<br>
Seems like an edge case. Never seen! But yes, here too, local variables can be used.<br>
<br>
    > Jörg<br>
<br>
All in all, the restrictions seem quite acceptable. The reason for *keeping* the<br>
type case statement is mainly efficiency. Nevertheless, I could live without it<br>
and use only *IS*.<br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>