Module re-exportation weekend puzzler

[Thomas Hallgren]

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/>