Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!ifistg!bs3!schoebel
From: schoebel@bs3.informatik.uni-stuttgart.de (Thomas Schoebel)
Newsgroups: comp.lang.modula2
Subject: Re: definition module loops
Message-ID: <10634@ifi.informatik.uni-stuttgart.de>
Date: 13 May 91 14:51:40 GMT
References: <1991May12.071720.29928@ibmpcug.co.uk> <76170@eerie.acsu.Buffalo.EDU>
Sender: news@ifistg.uucp
Organization: Informatik, Uni Stuttgart, W. Germany
Lines: 32

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