[net.lang] Implicit EXPORT?

CSvax:Pucc-H:Physics:hal@pur-ee.UUCP (10/11/83)

	You misunderstood the question I was asking.
	Given:

DEFINITION MODULE A;
EXPORT foo;
TYPE foo=(whatever,...);
END A.
	and
DEFINITION MODULE B;
FROM A IMPORT foo;
EXPORT bar, proc1;
TYPE bar = RECORD
		fld: foo:
		...
	   END;
PROCEDURE proc1;
...
END B.

	Then,

MODULE user;
FROM B IMPORT bar, proc1;

VAR eg: bar;
    f1: foo;			(* Is this declaration valid? *)
(*      ^ undefined identifier (* or should this be the case?*) *)
BEGIN
	(* assume eg is defined *)
	proc1(eg.fld);	(* as pointed out, this is OK *)
	f1 := eg.fld;	(* this is OK, only if the declaration worked *)
END user.
---------

    The Modula-2 report specifies that the name "fld" is exported with "bar"
but does not mention what the status of "foo" is.  A strict interpretation
would require that "foo" be unknown in the module "user".  Of course, the
compiler knows about "foo", that's not the question.  How, do current
implementations handle this.

Hal Chambers
Physcis Dept.
Purdue University
(...!pur-ee!pur-phy!hal)

patcl@tekecs.UUCP (10/13/83)

	"You misunderstood the question I was asking...."

No, I don't believe I did. In fact, I was attempting to
comment on both the compiler's ability to know about
external types, and the scope-of-visibility rules which
apply to those types. Referring to the example which
Hal Chambers presents in his article (pur-phy.1051),
type "foo" is not in fact visible in module "user".
Implicit export/import occurs only for field names
(not their defining types) and enumeration constants.
I would argue strenously that this is as it should be.
There should be *very few* cases where an identifier
can appear inside a module, and not (a) be declared in
that module or (b) appear on an import list for that
module. If it is allowed to "pull in" type names which
are used in the definitions of imported record types,
that is too many cases.  If we do it for records,
then why not also do it for procedure return types?
or formal parameter types?
I do not believe that the language
report is ambiguous on this point. I have also implemented
the language, and did not feel compelled to provide
any deviation from a strict interpretation of the report
on this issue.

I think there are other problems having to do with
separate compilation which should be discussed.
For example, should circular dependencies between
modules be allowed, and if so what is the formal rule
for order of module initialization? Also, what is the
"best" implementation model? Is there something better
than producing a "symbol" file for each compilation
of a definition module?

-- Pat Clancy
   Tektronix