Allow top-level shadowing for imported names?
eacameron at gmail.com
Tue Oct 4 15:13:03 UTC 2016
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,
On Tue, Oct 4, 2016 at 7:50 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs