Allow top-level shadowing for imported names?

[Edward Z. Yang]

There is another options: names from local modules (same package) shadow
names from external packages.  But it is not obvious to me that this is
a good idea.

Edward

Excerpts from Herbert Valerio Riedel's message of 2016-10-04 13:50:58 +0200:
> Hi,
> 
> 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.
>