Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site tekecs.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxi!houxm!ihnp4!zehntel!tektronix!tekecs!patcl
From: patcl@tekecs.UUCP
Newsgroups: net.lang
Subject: Re: Implicit EXPORT?
Message-ID: <3069@tekecs.UUCP>
Date: Wed, 12-Oct-83 19:15:09 EDT
Article-I.D.: tekecs.3069
Posted: Wed Oct 12 19:15:09 1983
Date-Received: Fri, 14-Oct-83 04:56:47 EDT
Organization: Tektronix, Wilsonville OR
Lines: 37


	"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