Re: Error in opening the Library module file

Jugoslav Dujic <jdujic@xxxxxxxxx> wrote:

Please see Mike's example in post #2 in this thread -- circular USEs
are in contained routines rather than in module declaration sections;
I am aware that cyclic dependency is prohibited in the latter form,
but I'm not sure about the example at hand.

That is still disallowed. I'm sure I recall some discussion of that
somewhere. Might even have beeen an interp, though I half think it might
have beeen concluded to be "clear enough" (as standard-speak goes) to
not need a formal interp. The language prohibiting the cyclic dependency
doesn't make any distinction between the module specification part and
the contained procedures. It just talks about the module, which includes
both parts equally.

While I don't off-hand think that USEs in the contained routines can get
into the same kind of contradiction as I mentioned in my previous post,
they are still disallowed by the standard.

If one is truly desparate, one workaround for that kind of issue is to
have an external procedure instead of a module one. Perhaps one could
isolate the "problem" by having a module procedure that called the
external one. I've been tempted by that approach and might even have
temporarily hacked some code like that, but in the end, I've always
taken a different approach, perhaps reorganizing things. I think that
the "always" is literally true there; anyway, I can't off-hand think of
any exceptions that I left in production code.

I'll note that a solution for some common cases is in the submodule
stuff of the f2003 submodules TR (not f2003 itself, but the TR that came
out essentially simultaneously with f2003 and is being implemented be
some vendors in advance of f2003 itself). I would not claim that
submodules address all such problems, but they do address one major
cause of this kind of issue. I personally view submodules as a way to
have a dependency relationship other than a tree - specifically to
reverse the dependency at some points, having "low-level"
implementations depend on "high-level" interface specifications rather
than the other way around.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.