Scope of imported names
Karl-Filip Faxen
kff@it.kth.se
Mon, 22 Oct 2001 13:41:31 +0200
Hello again,
Wolfgang wrote
> The Haskell report seems to be inconsistent here (once again). In the =
> beginning of section 5.3 it says =
> =
> Imported names serve as top level declarations: they scope over the e=
ntire
> body of the module but may be shadowed by local NON-TOP-LEVEL binding=
s.
> =
> Thus, the definition of sin in module F is invalid because another =
> top-level declaration of sin already exists due to the (implicit) =
> import of the Prelude. In order to redefine sin locally the imported =
> definition should be hidden and imported only qualified:
> =
> module F where
> import Prelude hiding(sin)
> import qualified Prelude(sin)
> ...
Well, it's not that simple currently. Name clashes are only illegal if th=
ey
lead to unresolvable references. Thus if we have
module Main where
sin x =3D x+1
sin :: Float -> Float
main =3D print (sin 1)
then that program is illegal since in "sin 1" we cannot say which "sin" i=
t
is (from the Prelude or from Main). It is for this reason that it is lega=
l
to use qualified names to refer to top level declarations. Thus, accordin=
g
to the October release of the Report, the following is legal
module Main where
sin x =3D x+1
sin :: Float -> Float
main =3D print (Prelude.sin 1, Main.sin 1)
since the qualified names are different, but in my proposal, one would
instead write
module Main where
sin x =3D x+1
sin :: Float -> Float
main =3D print (Prelude.sin 1, sin 1)
to get the same effect. =
So I do not think that the Report is really inconsistent, it is just very=
intricate. Shadowing imported names is a much easier rule to formulate an=
d
understand, I think. And the same programs can be written as today.
> > What I'm driving at is this: I propose that top level bindings shadow=
> > imported names and that qualified names can not be used to refer to
> > declarations in the same module. =
> =
> The second part is going to conflict with the revised report which reli=
es =
> on the qualified names of entities in order to specify which entites ex=
ported =
> from module M (module M) where { ... }
That's right (this refers to section 5.2, fifth numbered item). What is
the rationale behind requiring the qualified name to be visible also?
> who prefers to forbid shadowing of imported names :-)
Even by nested bindings?
/kff