Hi, Lennart suggested that some time ago, here is the thread from the last time we discussed it: https://mail.haskell.org/pipermail/haskell-prime/2012-July/003702.html I think it is a good plan! -Iavor On Mon, Oct 3, 2016 at 4:46 AM, Richard Eisenberg wrote:

By all means make the proposal -- I like this idea.

...

On Oct 3, 2016, at 4:29 AM, Herbert Valerio Riedel wrote:

Hi *,

I seem to recall this was already suggested in the past, but I can't seem to find it in the archives. For simplicity I'll restate the idea:

foo :: Int -> Int -> (Int,Int) foo x y = (bar x, bar y) where bar x = x+x

results merely in a name-shadowing warning (for -Wall):

foo.hs:4:9: warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding bound at foo.hs:2:5

However,

import Data.Monoid

(<>) :: String -> String -> String (<>) = (++)

main :: IO () main = putStrLn ("Hi" <> "There")

doesn't allow to shadow (<>), but rather complains about ambiguity:

bar.hs:7:23: error: Ambiguous occurrence ‘<>’ It could refer to either ‘Data.Monoid.<>’, imported from ‘Data.Monoid’ at bar.hs:1:1-18 or ‘Main.<>’, defined at bar.hs:4:1

This is of course in line with the Haskell Report, which says in https://www.haskell.org/onlinereport/haskell2010/ haskellch5.html#x11-1010005.3

| The entities exported by a module may be brought into scope in another | module with an import declaration at the beginning of the module. The | import declaration names the module to be imported and optionally | specifies the entities to be imported. A single module may be imported | by more than one import declaration. Imported names serve as top level | declarations: they scope over the entire body of the module but may be | shadowed by *local non-top-level bindings.*

However, why don't we allow this to be relaxed via a new language extensions, to allow top-level bindings to shadow imported names (and of course emit a warning)?

Unless I'm missing something, this would help to keep existing and working code compiling if new versions of libraries start exporting new symbols (which happen to clash with local top-level defs), rather than resulting in a fatal name-clash; and have no major downsides.

If this sounds like a good idea, I'll happily promote this into a proper proposal over at https://github.com/ghc-proposals/ghc-proposals; I mostly wanted to get early feedback here (and possibly find out if and where this was proposed before), before investing more time turning this into a fully fledged GHC proposal.

Cheers, HVR _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

-Edward

On Mon, Oct 3, 2016 at 2:12 PM, Iavor Diatchki wrote:

...

Hi,

Lennart suggested that some time ago, here is the thread from the last time we discussed it:

https://mail.haskell.org/pipermail/haskell-prime/2012-July/003702.h tml

I think it is a good plan!

-Iavor

On Mon, Oct 3, 2016 at 4:46 AM, Richard Eisenberg wrote:

...

By all means make the proposal -- I like this idea.

...

On Oct 3, 2016, at 4:29 AM, Herbert Valerio Riedel

wrote:

...

Hi *,

I seem to recall this was already suggested in the past, but I can't seem to find it in the archives. For simplicity I'll restate the idea:

   foo :: Int -> Int -> (Int,Int)    foo x y = (bar x, bar y)      where        bar x = x+x

results merely in a name-shadowing warning (for -Wall):

   foo.hs:4:9: warning: [-Wname-shadowing]        This binding for ‘x’ shadows the existing binding          bound at foo.hs:2:5

However,

   import Data.Monoid

   (<>) :: String -> String -> String    (<>) = (++)

   main :: IO ()    main = putStrLn ("Hi" <> "There")

doesn't allow to shadow (<>), but rather complains about ambiguity:

   bar.hs:7:23: error:        Ambiguous occurrence ‘<>’        It could refer to either ‘Data.Monoid.<>’,                                 imported from ‘Data.Monoid’ at

bar.hs:1:1-18

...

                             or ‘Main.<>’, defined at bar.hs:4:1

This is of course in line with the Haskell Report, which says in https://www.haskell.org/onlinereport/haskell2010/haskellch5.

html#x11-1010005.3

...

...

The entities exported by a module may be brought into scope in another module with an import declaration at the beginning of the module. The import declaration names the module to be imported and optionally specifies the entities to be imported. A single module may be imported by more than one import declaration. Imported names serve as top level declarations: they scope over the entire body of the module but may be shadowed by *local non-top-level bindings.*

However, why don't we allow this to be relaxed via a new language extensions, to allow top-level bindings to shadow imported names (and of course emit a warning)?

Unless I'm missing something, this would help to keep existing and working code compiling if new versions of libraries start exporting new symbols (which happen to clash with local top-level defs), rather than resulting in a fatal name-clash; and have no major downsides.

If this sounds like a good idea, I'll happily promote this into a proper proposal over at https://github.com/ghc-proposals/ghc-proposals ; I mostly wanted to get early feedback here (and possibly find out if and where this was proposed before), before investing more time turning this into a fully fledged GHC proposal.

Cheers,  HVR _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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

Yuras Shumovich wrote:

...

Can we generalize the proposal such that subsequent imports shadow preceding ones?

Herbert Valerio Riedel wrote:

...iirc there is a different idea... allowing explicitly enumerated names... to shadow imports from other modules which didn't explicitly name the same import; effectively introducing a higher-priority scope for names imported explicitly.

Conversely - the original proposal should be modified to remain an error, not a warning, when the symbol was imported explicitly on an import list and then redefined locally at the top level. This is equivalent to defining a symbol twice in the same scope. Thanks, Yitz

That makes perfect sense to me. -Edward On Wed, Oct 5, 2016 at 9:02 AM, Yitzchak Gale wrote:

Yuras Shumovich wrote:

...

...

Can we generalize the proposal such that subsequent imports shadow preceding ones?

Herbert Valerio Riedel wrote:

...

...iirc there is a different idea... allowing explicitly enumerated names... to shadow imports from other modules which didn't explicitly name the same import; effectively introducing a higher-priority scope for names imported explicitly.

Conversely - the original proposal should be modified to remain an error, not a warning, when the symbol was imported explicitly on an import list and then redefined locally at the top level. This is equivalent to defining a symbol twice in the same scope.

Thanks, Yitz _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

It is really good to think in terms of a cleverness budget. Every additional feature is not only implementation work, but also maintenance, extra cognitive overhead when adding new features, an extra thing for tooling outside of GHC to support. Personally, I'm on the wall on this one. Here are the things I see in favor of this proposal: 1) It is common practice to use -Wall. Infact, I think it should be a default, and should include more warnings than -Wall (-fwarn-tabs -fwarn-incomplete-uni-patterns -fwarn-incomplete-record-updates -fwarn-identities) 2) It lets us do things that are otherwise quite inconvenient. We can now easily shadow a bunch of identifiers without explicitly hiding them. Things I see against it: 1) It feels like a complicated way to avoid needing a "hiding ()" clause on your imports. 2) There is no good way to use this feature without creating a warning. I would like to be explicit in my name shadowing I'm thinking a pragma like {-# NO_WARN myFunction #-}, or, better yet, the more specific {-# SHADOWING myFunction #-} orso. What if instead we re-framed this as a "top-level where clause", like this: main :: IO () main = putStrLn ("Hi" <> "There") other-function :: IO () other-function = putStrLn ("I can " <> "also use it") -- NOTE: 0 indent! where (<>) :: String -> String -> String (<>) = (++) I would also like to see this extension enabling other top level declarations in where clauses, except not typeclasses. I have discussed this before, IIRC, with Richard, and there was some complexity getting local data types playing well with scoped type variables. It seems like a very worthwhile extension in its own right. I like this top-level where clause, because it riffs on existing syntax. Also, there isn't very much danger in someone accidentally dedenting their where clause to 0 level and not realizing it. The only danger there is if they were also simultaneously relying on scope shadowing (and somehow the types still work out). -Michael On Wed, Oct 5, 2016 at 9:35 AM, Christopher Allen wrote:

I agree with Tom on this. This isn't a good way to spend the cleverness budget.

On Wed, Oct 5, 2016 at 11:34 AM, wrote:

...

I'm weakly against this proposal. I may compile with -Wall, but I read code by many people who don't. When I'm browsing a file and see e.g.

import Network.Socket

and then later in the file, I see a reference to "recvFrom", I currently know exactly what function is being called. I don't want to have to search around every time to make sure a function wasn't redefined in some dark corner of the module.

This allows too much "sneakiness" for my taste.

Tom

...

On Oct 3, 2016, at 04:29, Herbert Valerio Riedel wrote:

Hi *,

I seem to recall this was already suggested in the past, but I can't seem to find it in the archives. For simplicity I'll restate the idea:

foo :: Int -> Int -> (Int,Int) foo x y = (bar x, bar y) where bar x = x+x

results merely in a name-shadowing warning (for -Wall):

foo.hs:4:9: warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding bound at foo.hs:2:5

However,

import Data.Monoid

(<>) :: String -> String -> String (<>) = (++)

main :: IO () main = putStrLn ("Hi" <> "There")

doesn't allow to shadow (<>), but rather complains about ambiguity:

bar.hs:7:23: error: Ambiguous occurrence ‘<>’ It could refer to either ‘Data.Monoid.<>’, imported from ‘Data.Monoid’ at bar.hs:1:1-18 or ‘Main.<>’, defined at bar.hs:4:1

This is of course in line with the Haskell Report, which says in https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1010005...

| The entities exported by a module may be brought into scope in another | module with an import declaration at the beginning of the module. The | import declaration names the module to be imported and optionally | specifies the entities to be imported. A single module may be imported | by more than one import declaration. Imported names serve as top level | declarations: they scope over the entire body of the module but may be | shadowed by *local non-top-level bindings.*

However, why don't we allow this to be relaxed via a new language extensions, to allow top-level bindings to shadow imported names (and of course emit a warning)?

Unless I'm missing something, this would help to keep existing and working code compiling if new versions of libraries start exporting new symbols (which happen to clash with local top-level defs), rather than resulting in a fatal name-clash; and have no major downsides.

If this sounds like a good idea, I'll happily promote this into a proper proposal over at https://github.com/ghc-proposals/ghc-proposals; I mostly wanted to get early feedback here (and possibly find out if and where this was proposed before), before investing more time turning this into a fully fledged GHC proposal.

Cheers, HVR _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Wed, Oct 5, 2016 at 7:05 PM, Brandon Allbery wrote:

On Wed, Oct 5, 2016 at 10:02 PM, Michael Sloan wrote:

...

What if instead we re-framed this as a "top-level where clause", like this:

main :: IO () main = putStrLn ("Hi" <> "There")

other-function :: IO () other-function = putStrLn ("I can " <> "also use it")

-- NOTE: 0 indent!

where (<>) :: String -> String -> String (<>) = (++)

This would actually be slightly odd parse-wise, as we're already *in* an unindented where clause (module ... where)

Ahh, of course! Good point, that makes this idea rather unappealing - it is indeed inconsistent. Just throwing ideas out there!

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net