X-Comment1: #############################################################
X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs #
X-Comment3: # If this address does not work please ask your mail #
X-Comment4: # administrator to update your NRS & mailer tables. #
X-Comment5: #############################################################
Tony Davie asks (re Haskell):
> All the messages pro and anti recursive modules are very interesting but
> my original question has been lost sight of. Are we meant to do
> dependency analysis across module boundaries or not? and if so can
> anyone see how to?
No, we are not meant to do dependency analysis across modules!
The static semantics of a module is defined only relative to the *interfaces
of* the modules it imports. If a pair of modules (A and B) import each
other, then it follows that at least one interface (say A's) will have to be
hand written.
Furthermore, such a hand-written interface had better not lie about the
types of the things exported by the module (though it may give a less
polymorphic type than really exists). There is a way to confirm that
it does not lie: automatically generate B's interface by compiling B,
then automatically generate a new interface to A by compiling A, then
compare this new interface for A with the hand-written one.
All of this stuff is explicitly delegated to the compilation system (5.1.4).
The language semantics only says when a given module, the interfaces
it imports, and the interface it exports are mutually consistent.
In short, *inference* of most general types is not required to work across
mutually-recursive modules. (Of course, a particular compilation system
could implement such type inference, by reading all the modules of
a mutually-recursive group, but it is not required to do so.)
Comments
~~~~~~~~
Like any module system, this is a compromise. SML compromises one way, by
choosing not to allow mutual recursion between modules. We decided to
compromise the other, by allowing mutual recursion, but then accepting
some infelicities in the static semantics in order to make separate
compilation feasible. I don't think either compromise is truly
satisfactory.
Simon
