Re: Allow top-level shadowing for imported names?
Michael Sloan wrote:
> It is really good to think in terms of a cleverness budget...
> Here are the things I see in favor of this proposal:
>
> 1) It is common practice to use -Wall...
> 2) It lets us do things that are otherwise quite inconvenient...
You missed the most important plus:
0) It fixes an inconsistency and thus simplifies Haskell syntax.
So in my opinion this is not a cleverness proposal, it's a
simplication.
> 2) There is no good way to use this feature without creating a
> warning.
I'm not sure what you mean. There is already a warning for
shadowing. Except shadowing from imports, where it is an
error instead. The proposal is to eliminate that special
case.
> 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.
The same applies to shadowing in every other context.
Adding such a pragma might indeed be a nice idea. But
it should apply consistently to shadowing in all contexts,
not just for import shadowing. In any case, this
would be a separate proposal.
-Yitz
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
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
> allber...@gmail.com ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
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)
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
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.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
Re: Allow top-level shadowing for imported names?
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 > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
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.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
--
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
Re: Allow top-level shadowing for imported names?
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.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
Re: Allow top-level shadowing for imported names?
Yeah... let's not have import order sensitivity. On Wednesday, October 5, 2016, 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 > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
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
Re: Allow top-level shadowing for imported names?
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
Re: Allow top-level shadowing for imported names?
On Tue, Oct 4, 2016 at 7:12 AM, 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. Could you give a concrete example of what you are worried about? It's already legal to have a clash between imported names as long as you don't refer to the colliding name. For example if one of my imports A exports a name `foo` which I don't use, and then another import B starts to export the same name `foo`, there won't be any error as long as I continue to not use `foo`. Regards, Reid Barton ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
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 > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
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
Re: Allow top-level shadowing for imported names?
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 com>
> 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 > edu>
> > wrote:
> >
> > >
> > > By all means make the proposal -- I like this idea.
> > >
> > > >
> > > > On Oct 3, 2016, at 4:29 AM, Herbert Valerio Riedel > > > ail.com>
> > > 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.hask
Re: Allow top-level shadowing for imported names?
I for one would really like to see this go in. (I've commiserated with
Lennart in the past about the fact that the previous proposal just sort of
died.)
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.
-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.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
>>
>
>
> ___
> 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
Re: Allow top-level shadowing for imported names?
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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
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
RE: Allow top-level shadowing for imported names?
Fine with me!
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Herbert Valerio Riedel
| Sent: 03 October 2016 09:29
| To: ghc-devs
| Subject: Allow top-level shadowing for imported names?
|
| 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
| b.com%2Fghc-proposals%2Fghc-
| proposals&data=01%7C01%7Csimonpj%40microsoft.com%7C6cb5253b609241e0b10
| 008d3eb675d5e%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=COdAXpXOOox
| mAnZSBnJfbF%2BTctssVUlqn%2BiccABrkF0%3D&reserved=0; 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
Re: Allow top-level shadowing for imported names?
I don't see why not. (But then again I wasn't around for Haskell98!)
Edward
Excerpts from Herbert Valerio Riedel's message of 2016-10-03 10:29:06 +0200:
> 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
