infelicity in module imports
Thu, 5 Jul 2001 01:02:14 -0700
| | > Currently, you are permitted to write
| | >=20
| | > import A hiding (f)
| | > import B as A (f)
| | >=20
| | > and this means that everything exported from module A is visible,=20
| | > with the exception that function `f' is overridden by a different=20
| | > definition from module B. Here, a reference to `A.f' is resolved=20
| | > unambiguously to `B.f'.
| | In my understanding of the report, this is not true. Quoting from=20
| | section 5.3 of the report=20
| | "The hiding clause only applies to unqualified names. In the
| | example, the name M.C is brought into scope."
| | Thus, in your example, the declaration import A hiding (f) will
| | A.f into scope and thus A.f is ambiguous!
Wolfgang is correct. I don't see how the report can be read any other
| However, if you are indeed correct, then we have an even stranger
| import A (g)
| brings only A.g into scope, but
| import A hiding (f)
| brings both A.f and A.g into scope! So `hiding' is doing the=20
| opposite of hiding, and in fact _reveals_ names.
No, that's not so. Let's assume that A exports f,g,h.
The report says (first sentence of 5.3.1) "if the
qualified keyword is omitted, both qualified and unqualified names are
brought into scope". So both the above imports bring into scope
A.f and A.g and A.h; the former also brings unqualified 'g' into scope,
the latter also brings 'g' and 'h' into scope.
In short, an import *always* brings the entire *qualified* set of names
Hiding and revealing applies only to unqualified names. I must say that
thought GHC implemented this rule; if not I should fix it.
As to whether this is a good design, I'm sure one could suggest others,
I'm very strongly biased against fixing anything that is not a Bug.
As to whether it is clearly stated, presumably the answer is 'no', since
Malcolm (an expert by any lights) has misunderstood it in two different
ways. That I would like to fix.
Can anyone suggest a way to make the report clearer?