If you’re using unqualified and unrestricted imports, there’s still the risk that another module will export something you care about, e.g.
module M where
import I -- currently exports foo
import J -- might be changed in future to export foo
… foo …
So I think you need to use import lists or qualified anyway to avoid any risk of future name clashes – given that, does this change buy much?
It's not often that one gets the chance to change something as
fundamental as the scoping rules of a language. Nevertheless, I would
like to propose a change to Haskell's scoping rules.
The change is quite simple. As it is, top level entities in a module
are in the same scope as all imported entities. I suggest that this
is changed to that the entities from the module are in an inner scope
and do not clash with imported identifiers.
Why? Consider the following snippet
Assume this compiles. Now change the module I so it exports something
called foo. After this change the module M no longer compiles since
(under the current scoping rules) the imported foo clashes with the
Pros: Module compilation becomes more robust under library changes.
Fewer imports with hiding are necessary.
Cons: There's the chance that you happen to define a module identifier
with the same name as something imported. This will typically lead to
a type error, but there is a remote chance it could have the same
Implementation status: The Mu compiler has used the scoping rule for
several years now and it works very well in practice.