🚀 go-pugleaf

In article <76170@eerie.acsu.Buffalo.EDU> bowen@cs.Buffalo.EDU (Devon E Bowen) writes:
>Sounds good to me (a lot easier to implement). But at the end of section
>14 of the Report on The Programming Language Modula-2 in Wirth's book, he
>says
>
>	If circular references occur among modules, their order of
>	initialization is not defined.
>
>Which implies this circular nature does exist. Well, I guess I'll just
>leave this feature out until there is a definte need shown for it.

Perhaps the distiction between definiton and implementation modules
will make it more clear: In most current compilers, circular imports
amoung definition modules are disallowed (even if the imported objects
would not cause a cycle by their real definition); however, cycles
amoung implementation modulues are possible.

If you divide the definition and implementation parts logically into
different modules, you may view the dependency graph in such a way
that all sorts of modules are always importing from definition modules.
Then there is never an import from an implementation module, so there is
logically never a cycle.
However, the initialization order amoung the modules in the cycle
is undefined; this is the only problem I can see.

As my opinion, in larger systems cycles amoung implementation modules
are nearly unavoidable, but I cannot prove this. It is just an experience
from practice. Theoretically, you can always break down any well-defined
structure into smaller and smaller submodules, so there would be no need
to allow circular imports.

--Thomas