Unused IMPORTs

[DGDanforth]

Info=>Analyze module
marks an import as "never used" if the import is not directly accessed within a module.
But that is wrong.
Why? Because it leads the user to believe the module can be deleted from the IMPORT list.
However, there are cases when doing so can lead to disaster.

Gardens Point Component Pascal uses the strategy of "cross initialization" where module B initializes module C.
IF module A imports B and C but does not use B then one would think they could remove B, however,
this leaves C uninitialized. A call by A to C can cause traps. For example in Gardens Point (Gp) in C a division by
size is performed where it is has been assumed that size has previously been set to some nonzero value. When
B is not loaded that assumption is false.

I never do "cross initialization" so have never encountered the problem before converting Gp to BlackBox.

I believe Analyze needs to be modified.

Comments?
-Doug

[Josef Templ]

If there is an import in the import list that only exists because of
the side effect of the imported module body, such an import should be marked by a comment.
Then you don't remove it accidentally at a later time. This is independent from gp.

If gp is using this exotic form of an import heavily it should be fixed in gp
but not in the Analyzer.

You would remove an important feature of the Analyzer.

- Josef

[DGDanforth]

Josef,
I agree.

Secondary comment:
IF A IMPORTS B,C THEN the load order is B, C, A.
IF B IMPORTs C THEN the load order is C, B, A.
The load order is a function of the dependencies between the modules.

That can affect program development.

Just my 2 cents.
-Doug

[cfbsoftware]

Doug,

Firstly, be careful if you want your programs to always work as expected on different Oberon / Component Pascal systems.

There should be no problem if

• A IMPORTS B, and
• B IMPORTS C

because, as you say, the order of module initialisation should always be C, B then A.

If, on the other hand:

• A IMPORTS B and C, and
• B does not IMPORT C, and
• C does not IMPORT B

you should not write any code which relies on B and C being initialised in any particular order as it will be implementation-dependent.

Secondly, which might be related to your original question:

I have occasionally encountered what I believe to be a problem with GPCP where A IMPORTS B and B IMPORTS C. Even though A does not directly reference anything from C but I find I have to add C to the IMPORT list of A to get it to work properly. As far as I know that should not be necessary. However, so far I have been unsuccessful in finding a simple example to use to report the problem.