Allow top-level shadowing for imported names?

[Elliot Cameron]

I second Herbert's concern. Giving semantics to import order is one of the
greatest plagues of C, C++, Python, etc. It is worth avoiding at all costs.
Herbert's suggestion re: explicitly enumerated names seems to hold promise,
however.

On Tue, Oct 4, 2016 at 7:50 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> 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.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161004/86b8335d/attachment.html>