Hi, Simon Peyton-Jones wrote:
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?Folks Another minor H98 glitch.
Consider this:If only there was a formal specification one could consult in cases like this! But wait a minute. There is one [1]!
| > > 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?
... I agree with this. (Actually GHC gets it wrong right now.) AnotherThe 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?!
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.
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/>
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
