CSvax:Pucc-H:Physics:hal@pur-ee.UUCP (10/11/83)
This was meant as a followup to Pat Clancy's comments in net.lang
but the followup command posted the response as a separate article.
Therefore I'm posting it here (actually it's more appropriate for this
newsgroup anyhow). The question concerned the implicit export of record
field types.
-----------
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
adrian@ru-cs44.UUCP (Adrian Pell) (10/14/83)
We use the University of New South Wales M2 compiler (on Unix v7)
which is derived from the original RT-11 compiler written at ETH Zurich.
As far as I can see, Hal's comment is correct that 'foo' should be
unknown in module user, and, indeed, our compiler bears that out producing
the following output.
+++++++++++++++++++++++++++++++++++++++++++
1 MODULE user;
2 FROM B IMPORT bar, proc1;
3
4 VAR eg: bar;
5 f1: foo; (* Is this declaration valid? *)
**** ^73: identifier not declared
6 (* ^ undefined identifier (* or should this be the case?*) *)
7 BEGIN
8 (* assume eg is defined *)
9 proc1(eg.fld); (* as pointed out, this is OK *)
10 f1 := eg.fld; (* this is OK, only if the declaration worked *)
11 END user.
+++++++++++++++++++++++++++++++++++++++++++
This seems to be not unreasonable since the only symbol file examined
whilst compiling user.mod is that generated by B, which contains only
a description of bar and proc1. In particular, it only knows the
size of the individual fields in bar, not their structure.
Another point: our compiler enforces QUALIFIED export from definition
modules as noted in the last paragraph of section 14 of the Modula-2
report.
--
Adrian Pell ({vax135,mcvax,edcaad}!ukc!ru-cs44!adrian)
Computer Science Dept.
University of Reading
UK