[Oberon] IMPORT Modules: why does order matter?
joerg.straube at iaeth.ch
Sun Mar 3 14:35:36 CET 2019
The cases where I did the EXIT elimination so far were „easy“ ones with direct childs. If you have nested IFs it‘s getting uglier indeed.
> Am 03.03.2019 um 14:22 schrieb Michael Schierl <schierlm at gmx.de>:
> Hello Jörg,
>> Am 03.03.2019 um 14:02 schrieb Jörg:
>> Automatic replacement of EXIT is something along these rules:
>> * LOOP statSeq END —> done := FALSE; REPEAT statSeq UNTIL done;
>> * IF cond THEN statSeq; EXIT END; —> IF cond THEN statSeq; done := TRUE
>> statSeq2 ELSE statSeq2
> This does not take into account EXIT statements that are nested deeper
> (in IF, CASE, WITH, or probably (not sure if allowed in OBERON-2) nested
> FOR loops).
> My approach (which causes ugly code) would be:
> Rewrite »LOOP statSeq END« to
> »done := FALSE; REPEAT statSeq' UNTIL done;«
> while statSeq' is derived from statSeq by
> - wrapping every individual statement in
> »IF NOT done THEN statement END«
> - if the statement is a block statement, derive its nested statement
> sequences by the same way
> - rewrite nested FOR loops (if allowed) to terminate if done is true
> - replace every EXIT by done := TRUE;
> Other EXIT which are found and not eliminated by these rules are either
> a bug in the rewriting algorithm implementation or a compile error in
> the original source code.
> In case every EXIT statement is only contained in an IF statement that
> is a direct child of the LOOP, Jörg simpler's algorithm could be used as
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon