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