<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 4, 2016 at 7:50 AM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On 2016-10-04 at 13:12:54 +0200, Yuras Shumovich wrote:<br>
> On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:<br>
><br>
>> It makes additions of names to libraries far less brittle. You can<br>
>> add a<br>
>> new export with a mere minor version bump, and many of the situations<br>
>> where<br>
>> that causes breakage can be fixed by this simple rule change.<br>
><br>
> It would be true only if we also allow imports to shadow each other.<br>
> Otherwise there will be a big chance for name clash yet.<br>
><br>
> Can we generalize the proposal such that subsequent imports shadow<br>
> preceding ones?<br>
<br>
</span>IMO, that would be lead to fragile situations with hard to detect/debug<br>
problems unless you take warnings serious.<br>
<br>
With the original proposal, the semantics of your code doesn't change if<br>
a library starts exposing a name it didn't before. There is a clear<br>
priority of what shadows what.<br>
<br>
However, when we allow the ordering of import statements to affect<br>
shadowing, it gets more brittle and surprising imho:<br>
<br>
For one, we have tooling which happily reorders/reformats import<br>
statements which would need to be made aware that the reordering<br>
symmetry has been broken.<br>
<br>
Moreover, now we get into the situation that if in<br>
<br>
  import Foo -- exports performCreditCardTransaction<br>
  import Bar<br>
<br>
  main = do<br>
     -- ..<br>
     performCreditCardTransaction ccNumber<br>
     --<br>
<br>
'Bar' suddenly starts exporting performCreditCardTransaction as well<br>
(and doing something sinister with the ccNumber before handing it over<br>
to the real performCreditCardTransaction..<wbr>.), it can effectively change<br>
the semantics of a program and this would merely emit a warning which<br>
imho rather deserves to be a hard error.<br>
<br>
However, iirc there is a different idea to address this without breaking<br>
reordering-symmetry, e.g. by allowing explicitly enumerated names as in<br>
<br>
  import Foo (performCreditCardTransaction)<br>
  import Bar<br>
<br>
to shadow imports from other modules which didn't explicitly name the<br>
same import; effectively introducing a higher-priority scope for names<br>
imported explicitly.<br>
<span class="im HOEnZb"><br>
> In that case you may e.g. list local modules after libraries' modules,<br>
> and be sure new identifies in libraries will not clash with local<br>
> ones. Obviously shadowing should be a warning still.<br>
<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>