Allow top-level shadowing for imported names?

Herbert Valerio Riedel hvriedel at
Tue Oct 4 11:50:58 UTC 2016


On 2016-10-04 at 13:12:54 +0200, Yuras Shumovich wrote:
> On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:
>> It makes additions of names to libraries far less brittle. You can
>> add a
>> new export with a mere minor version bump, and many of the situations
>> where
>> that causes breakage can be fixed by this simple rule change.
> It would be true only if we also allow imports to shadow each other.
> Otherwise there will be a big chance for name clash yet.
> Can we generalize the proposal such that subsequent imports shadow
> preceding ones?

IMO, that would be lead to fragile situations with hard to detect/debug
problems unless you take warnings serious.

With the original proposal, the semantics of your code doesn't change if
a library starts exposing a name it didn't before. There is a clear
priority of what shadows what.

However, when we allow the ordering of import statements to affect
shadowing, it gets more brittle and surprising imho:

For one, we have tooling which happily reorders/reformats import
statements which would need to be made aware that the reordering
symmetry has been broken.

Moreover, now we get into the situation that if in

  import Foo -- exports performCreditCardTransaction
  import Bar

  main = do
     -- ..
     performCreditCardTransaction ccNumber

'Bar' suddenly starts exporting performCreditCardTransaction as well
(and doing something sinister with the ccNumber before handing it over
to the real performCreditCardTransaction...), it can effectively change
the semantics of a program and this would merely emit a warning which
imho rather deserves to be a hard error.

However, iirc there is a different idea to address this without breaking
reordering-symmetry, e.g. by allowing explicitly enumerated names as in

  import Foo (performCreditCardTransaction)
  import Bar

to shadow imports from other modules which didn't explicitly name the
same import; effectively introducing a higher-priority scope for names
imported explicitly.

> In that case you may e.g. list local modules after libraries' modules,
> and be sure new identifies in libraries will not clash with local
> ones. Obviously shadowing should be a warning still.

More information about the ghc-devs mailing list