More feedback on Haskell 98 modules from the Programatica Team
Wed, 08 Aug 2001 10:56:45 +0200
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
> | *unqualified* imports. But this example suggests more; that it
> | 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
> 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)
... 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 Lux Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259
Universitaet Muenster Email: email@example.com