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. > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
