<div dir="ltr">The latest Oberon language definition by NW that I have found is Revision 1.10.2013 / 3.5.2016<div>(see <a href="http://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf">http://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf</a>).</div><div><br></div><div>It does have a numeric CASE statement.</div><div><br></div><div>My interpretation of what might have happened is this:</div><div>In Oberon07 the numeric CASE had been dropped, but later it has been reintroduced</div><div>but the ELSE has been forgotten.</div><div>To me, a numeric CASE without an ELSE is pointless.</div><div>The compiler needs to emit a range check anyway for generating a TRAP if there is no ELSE.</div><div>The ELSE part comes (almost) for free.</div><div>If the ELSE check is done outside the CASE, it is actually done twice.</div><div><br></div><div>In contrast to some postings, by the way, the labels are not forced to start with 0</div><div>and they can also be negative (by specifying a negative named constant).</div><div>In a real implementation, it would be much simpler to allow any ConstantExpr</div><div>of appropriate result type, though.</div><div><br></div><div>My conclusion so far is: If the numeric CASE is not implemented but only specified,</div><div>it should not be taken literally.</div><div><br></div><div>- Josef</div></div>