Module re-exportation weekend puzzler

[Iavor S. Diatchki]

Hi,

Simon Peyton-Jones wrote:

  >Folks
  >
  >Another minor H98 glitch.
  >
Are you saying that you think the report doesn't fully define the
meaning of the module system, or just that difficult to understand and
needs to be clarified?

  >  Consider this:
  >
  >| > > module D (module Char) where
  >| > > { import qualified Char; import List as Char }
  >| >
  >| > Everything in List, nothing from Char.
  >|
  >| Interesting... what happens when List and Char overlap here?
  >
If only there was a formal specification one could consult in cases like
this! But wait a minute. There is one [1]!

  >... I agree with this.  (Actually GHC gets it wrong right now.)   Another
  >way to say it is this:
  >
  >	The export item 'module M' exports all entities e such that
  >	a) The qualified name M.e is unambiguous and refers to that
  >entity
  >	b) The unqualified name e is in scope, perhaps ambiguously, and
  >at least
  >		one of its bindings refers to that entity
  >
  >I'll make the one-word change in the Report that Simon suggests, though.
  >
The meaning of "module M" in export lists is rather subtle, and the
above reformulation (or the one-word change) seems to make a subtle
change to it. It is not just a clarification. Is that what you intend?!

Export specifications of the kind "module Simon" have always referred to
entities that are in scope with an unqualified name, so if the
unqualified names are unambiguous, why should the export be considered
ambiguous?

Consider the following example (*):

module Cambridge(module Simon) where
    import PJ as Simon
    import qualified Marlow as Simon

    someone = simon

module Marlow where

    simon = "Simon Marlow"

module PJ where

    simon = "Simon PJ"


Here the qualified name Simon.simon is ambiguous in module Cambridge,
while the unqualified name simon is unambiguous. The use of simon in the
definition of someone is thus OK. More interestingly, the export
specification "module Simon" is also unambiguous, according to our
interpretation of the report. Both someone and the simon exported from
Cambridge refer to "Simon PJ". This agrees with our formal semantics,
and presumably also with what GHC implements. With the proposed change,
the definition of someone would still be OK, but the export
specification "module Simon" would trigger an error message, presumably.

A nice aspect of our formal semantics is that the computation of the
exports and inscope relations, which includes fixpoint iteration to give
meaning to recursive modules, and the error checking can be kept
separate. The change proposed above means that the error checking has to
be integrated with the fixpoint iteration (or that the fixpoint
iteration has to return more than the resulting inscope/export
relations), and thus complicates the specification.

So, while the text in the report might need clarification, we think the
semantic change implied in the above proposal is undesirable. It is
better to leave things status quo.

Iavor, Mark, Thomas


(*) Any similarities with actual persons and places are purely
coincidental! :-)
[1] A Formal Specification of the Haskell 98 Module System
<http://www.cse.ogi.edu/%7Ediatchki/hsmod/>, 2002 Haskell Workshop
<http://www.cse.unsw.edu.au/%7Echak/hw2002/>