Deprecating Exports (#134); Recommendation: accept
Hi, alanasp has proposed a Deprecating Exports mechanism: https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_... The gist is explained by this: module Data.List ( ... {-# DEPRECATE lines "Exported from Data.String instead" #-} , lines ...t ) where i.e. DEPRECATE pragmas in export lists cause warning when some other module uses the deprecated symbol when it is imported (only) via some deprecated export. This is a GSOC 2018 project, mentored by Matthew Pickering and Erik de Castro Lopo. The feature has a clear use-case, is self-contained and David Feuer (the containers maintainer) has already confirmed that there is a real demand for this. I suggest acceptance! As always, I will understand silence as tactic consensus. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
I have a bunch of question about this proposal, but I wrote them on the proposal discussion page, as this is what folks asked for, last time I had some questions. I think answering them would make the proposal more clear. It seems to me that the use of this extension is somewhat limited, but it could be useful on occasion so I could take it or leave it. It's been a while since I've looked at the GHC source, but I don't think that implementing this would be completely trivial, as I don't thing GHC currently cares about *how* names came to in scope, just what they refer to. But, I believe this is usually not a big factor in our discussions, just though I'd mention it. -Iavor On Thu, May 24, 2018 at 3:23 AM Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
alanasp has proposed a Deprecating Exports mechanism:
https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_...
The gist is explained by this:
module Data.List ( ... {-# DEPRECATE lines "Exported from Data.String instead" #-} , lines ...t ) where
i.e. DEPRECATE pragmas in export lists cause warning when some other module uses the deprecated symbol when it is imported (only) via some deprecated export.
This is a GSOC 2018 project, mentored by Matthew Pickering and Erik de Castro Lopo.
The feature has a clear use-case, is self-contained and David Feuer (the containers maintainer) has already confirmed that there is a real demand for this. I suggest acceptance!
As always, I will understand silence as tactic consensus.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Hi, in fact, GHC knows how something is imported; it uses this information to report redundant imports. So I can optimistically hope that the implementation effort is reasonable. Cheers, Joachim Am 24. Mai 2018 19:04:45 MESZ schrieb Iavor Diatchki <iavor.diatchki@gmail.com>:
I have a bunch of question about this proposal, but I wrote them on the proposal discussion page, as this is what folks asked for, last time I had some questions. I think answering them would make the proposal more clear.
It seems to me that the use of this extension is somewhat limited, but it could be useful on occasion so I could take it or leave it. It's been a while since I've looked at the GHC source, but I don't think that implementing this would be completely trivial, as I don't thing GHC currently cares about *how* names came to in scope, just what they refer to. But, I believe this is usually not a big factor in our discussions, just though I'd mention it.
-Iavor
On Thu, May 24, 2018 at 3:23 AM Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
alanasp has proposed a Deprecating Exports mechanism:
https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_...
The gist is explained by this:
module Data.List ( ... {-# DEPRECATE lines "Exported from Data.String instead" #-} , lines ...t ) where
i.e. DEPRECATE pragmas in export lists cause warning when some other module uses the deprecated symbol when it is imported (only) via some deprecated export.
This is a GSOC 2018 project, mentored by Matthew Pickering and Erik
de
Castro Lopo.
The feature has a clear use-case, is self-contained and David Feuer (the containers maintainer) has already confirmed that there is a real demand for this. I suggest acceptance!
As always, I will understand silence as tactic consensus.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Aha, yes, I see that `GlobalRdrElement` has a list of imports that caused it to come in scope. I guess then the main change in types would be to `IfaceExport`, which is currently just an `AvailInfo` to something that would keep track of what's deprecated. Seems doable. On Thu, May 24, 2018 at 10:35 AM Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
in fact, GHC knows how something is imported; it uses this information to report redundant imports. So I can optimistically hope that the implementation effort is reasonable.
Cheers, Joachim
Am 24. Mai 2018 19:04:45 MESZ schrieb Iavor Diatchki < iavor.diatchki@gmail.com>:
I have a bunch of question about this proposal, but I wrote them on the proposal discussion page, as this is what folks asked for, last time I had some questions. I think answering them would make the proposal more clear.
It seems to me that the use of this extension is somewhat limited, but it could be useful on occasion so I could take it or leave it. It's been a while since I've looked at the GHC source, but I don't think that implementing this would be completely trivial, as I don't thing GHC currently cares about *how* names came to in scope, just what they refer to. But, I believe this is usually not a big factor in our discussions, just though I'd mention it.
-Iavor
On Thu, May 24, 2018 at 3:23 AM Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
alanasp has proposed a Deprecating Exports mechanism:
https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_...
The gist is explained by this:
module Data.List ( ... {-# DEPRECATE lines "Exported from Data.String instead" #-} , lines ...t ) where
i.e. DEPRECATE pragmas in export lists cause warning when some other module uses the deprecated symbol when it is imported (only) via some deprecated export.
This is a GSOC 2018 project, mentored by Matthew Pickering and Erik
de
Castro Lopo.
The feature has a clear use-case, is self-contained and David Feuer (the containers maintainer) has already confirmed that there is a real demand for this. I suggest acceptance!
As always, I will understand silence as tactic consensus.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
I'm ok with acceptance (I recall this idea has come up several times in the past, it's definitely useful sometimes). But I agree with Iavor that the proposal needs some details to be nailed down. Cheers Simon On 24 May 2018 at 18:04, Iavor Diatchki <iavor.diatchki@gmail.com> wrote:
I have a bunch of question about this proposal, but I wrote them on the proposal discussion page, as this is what folks asked for, last time I had some questions. I think answering them would make the proposal more clear.
It seems to me that the use of this extension is somewhat limited, but it could be useful on occasion so I could take it or leave it. It's been a while since I've looked at the GHC source, but I don't think that implementing this would be completely trivial, as I don't thing GHC currently cares about *how* names came to in scope, just what they refer to. But, I believe this is usually not a big factor in our discussions, just though I'd mention it.
-Iavor
On Thu, May 24, 2018 at 3:23 AM Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,
alanasp has proposed a Deprecating Exports mechanism: https://github.com/alanasp/ghc-proposals/blob/patch-2/ proposals/deprecating_exports_proposal.rst
The gist is explained by this:
module Data.List ( ... {-# DEPRECATE lines "Exported from Data.String instead" #-} , lines ...t ) where
i.e. DEPRECATE pragmas in export lists cause warning when some other module uses the deprecated symbol when it is imported (only) via some deprecated export.
This is a GSOC 2018 project, mentored by Matthew Pickering and Erik de Castro Lopo.
The feature has a clear use-case, is self-contained and David Feuer (the containers maintainer) has already confirmed that there is a real demand for this. I suggest acceptance!
As always, I will understand silence as tactic consensus.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Dear Committee, Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner:
alanasp has proposed a Deprecating Exports mechanism: https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_...
I suggest acceptance!
thanks Iavor, Simon and Richard for refining the proposal (and sorry for missing some of the obvious shortcomings). I believe the author addressed the concerns, and now the proposal is better. I even more suggest acceptance. If there is still disagreement, please speak up. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
I have some reservations, though I like the overall idea. I've posted on GitHub. Richard
On Jun 23, 2018, at 12:13 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:
Dear Committee,
Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner:
alanasp has proposed a Deprecating Exports mechanism: https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_...
I suggest acceptance!
thanks Iavor, Simon and Richard for refining the proposal (and sorry for missing some of the obvious shortcomings). I believe the author addressed the concerns, and now the proposal is better.
I even more suggest acceptance. If there is still disagreement, please speak up.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Hi Richard, have your reservations been addressed and/or resolved? My impression is that overall, we approve of the feature, and I suggest we accept the proposal as it, confident that any remaining corner cases will be resolved in the process of implementing it, and in a way that will be fine. Cheers, Joachim Am Samstag, den 23.06.2018, 23:46 -0400 schrieb Richard Eisenberg:
I have some reservations, though I like the overall idea. I've posted on GitHub.
Richard
On Jun 23, 2018, at 12:13 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:
Dear Committee,
Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner:
alanasp has proposed a Deprecating Exports mechanism: https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_...
I suggest acceptance!
thanks Iavor, Simon and Richard for refining the proposal (and sorry for missing some of the obvious shortcomings). I believe the author addressed the concerns, and now the proposal is better.
I even more suggest acceptance. If there is still disagreement, please speak up.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
I generally agree, but Simon M and I have both staked out opposite opinions on the second bullet in https://github.com/ghc-proposals/ghc-proposals/pull/134#issuecomment-3997267... <https://github.com/ghc-proposals/ghc-proposals/pull/134#issuecomment-399726779> Simon, do you have a response to my thoughts there? I'm happy enough to let my other complaint be lazily resolved during implementation. Thanks, Richard
On Jul 8, 2018, at 9:47 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi Richard,
have your reservations been addressed and/or resolved?
My impression is that overall, we approve of the feature, and I suggest we accept the proposal as it, confident that any remaining corner cases will be resolved in the process of implementing it, and in a way that will be fine.
Cheers, Joachim
Am Samstag, den 23.06.2018, 23:46 -0400 schrieb Richard Eisenberg:
I have some reservations, though I like the overall idea. I've posted on GitHub.
Richard
On Jun 23, 2018, at 12:13 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:
Dear Committee,
Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner:
alanasp has proposed a Deprecating Exports mechanism: https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_...
I suggest acceptance!
thanks Iavor, Simon and Richard for refining the proposal (and sorry for missing some of the obvious shortcomings). I believe the author addressed the concerns, and now the proposal is better.
I even more suggest acceptance. If there is still disagreement, please speak up.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Hi, I sense that we are happy with the feature and specification so far, with corner cases resolved during implementation, and thus accept it now. Cheers, Joachim Am Sonntag, den 08.07.2018, 22:10 -0400 schrieb Richard Eisenberg:
I generally agree, but Simon M and I have both staked out opposite opinions on the second bullet in https://github.com/ghc-proposals/ghc-proposals/pull/134#issuecomment-3997267... Simon, do you have a response to my thoughts there?
I'm happy enough to let my other complaint be lazily resolved during implementation.
Thanks, Richard
On Jul 8, 2018, at 9:47 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi Richard,
have your reservations been addressed and/or resolved?
My impression is that overall, we approve of the feature, and I suggest we accept the proposal as it, confident that any remaining corner cases will be resolved in the process of implementing it, and in a way that will be fine.
Cheers, Joachim
Am Samstag, den 23.06.2018, 23:46 -0400 schrieb Richard Eisenberg:
I have some reservations, though I like the overall idea. I've posted on GitHub.
Richard
On Jun 23, 2018, at 12:13 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:
Dear Committee,
Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner:
alanasp has proposed a Deprecating Exports mechanism: https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_...
I suggest acceptance!
thanks Iavor, Simon and Richard for refining the proposal (and sorry for missing some of the obvious shortcomings). I believe the author addressed the concerns, and now the proposal is better.
I even more suggest acceptance. If there is still disagreement, please speak up.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
participants (4)
-
Iavor Diatchki -
Joachim Breitner -
Richard Eisenberg -
Simon Marlow