Simon Peyton-Jones wrote

| 2) The semantics of "module M" style entries in export lists seems to | Program 2: module A(module B, ...) where | ~~~~~~~~~~ import qualified B | ... code that doesn't import B ... | | A similar example: now B appears as an import, but there are no | unqualified imports of B, so either "module B" adds nothing to the | export list (except instances?), or else this program is an error. | | Item 5 on p65 (describing entities exported from modules) says that | "module m" exports entities brought into scope from m by one or more | *unqualified* imports. But this example suggests more; that it will | export instances brought into scope from *qualified* imports too. | Perhaps the intention is that "module m" exports all instances, | and all entities that are imported from m with an unqualified name?

I don't think it should matter whether B is imported qualified or not; I propose to remove the *unqualified* adjective in the above quote.

I don't think that this is a good idea. In particular because it may break existing programs. Consider two modules with one common name, e.g. module A where f x = 1 ... a lot of other definitions ... module B where f x = 2 ... a lot more definitions but none conflicting with A's top-level entities ... The following module is legal under the current semantics of the report (and will export everything from A and B except for A.f and in particular will generate no names clashes in the body of the module module C (module A,module B,module C) where import A hiding(f) import qualified A(f) import B ... code using A.f and f (i.e. B.f) ... With your proposed change there will be a name clash for the export of f from module C. Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux@uni-muenster.de