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
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