[Oberon] PO2013 - Modules.Load - recursion

[Michael Schierl]

Hello,


Am 30.05.2020 um 19:39 schrieb Tomas Kral:

> Module Oberon imports MenuViewers, TextFrames,
> both depend back on Oberon, which is not loaded, but to be
> loaded.

Not exactly. MODULE Oberon does not IMPORT MenuViewers, nor TextFrames.
MODULE Oberon dynamically loads MODULE System, which IMPORTs MenuViewers
and TextFrames.

But you are right that both of these MODULEs IMPORT Oberon.

That is not different than when you middle-click on Edit.Store, Edit is
dynamically loaded (by TextFrames.Call calling Oberon.Call calling
Modules.Load). Edit IMPORTS both TextFrames and Oberon, so the same kind
of "loop", but no problem.

> But how about this example, it even needs a trick to get modules M0,M1
> compiled.
>
> But recursion during load does not terminate?
>
> MODULE M0;
>   IMPORT M1, Out;
>   PROCEDURE Load*; END Load;
>   PROCEDURE Echo*;
>   BEGIN Out.String("M0 echo"); Out.Ln
>   END Echo;
> BEGIN M1.Echo
> END M0.
>
> MODULE M1;
>   IMPORT M0, Out;
>   PROCEDURE Echo*;
>   BEGIN Out.String("M1 echo"); Out.Ln
>   END Echo;
> BEGIN M0.Echo
> END M1.
>
> M0.Load

Here you have actual cyclic imports, which (as Andreas explained nicely)
is not supported in Project Oberon.

But, like Oberon/System does it, you can get around it by replacing one
of the two IMPORTs by a dynamic loading. If you actually need the two
modules call PROCEDURES of each other, you can declare procedure
variables in the "imported" module and assign them from the "dynamically
loaded" module. That way, the "imported" module can call into the
"dynamically loaded" module without IMPORTing it.

On the other hand, if you have modules so tightly coupled that both need
to IMPORT each other, they are probably in reality just one module and
should therefore be merged into one. Unless, of course, you need two
modules to get around some module size limits (e.g. local variable sizes
limited by the module loader, or string or code sizes limited by the
compiler).


Regards,


Michael