[Oberon] IMPORT Modules: why does order matter?

[Jörg]

Okay.
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.
Jörg

> 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
>>                                                                       END
> 
> 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
> well.
> 
> 
> Regards,
> 
> 
> Michael
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon