Deprecating Exports (#134); Recommendation: accept

Joachim Breitner

24 May 2018 24 May '18

6:23 a.m.

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/

Attachments:

signature.asc (application/pgp-signature — 833 bytes)

Show replies by date

Iavor Diatchki

24 May 24 May

1:04 p.m.

New subject: Deprecating Exports (#134); Recommendation: accept

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

Joachim Breitner

1:35 p.m.

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 :

...

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

...

Iavor Diatchki

1:47 p.m.

New subject: Deprecating Exports (#134); Recommendation: accept

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

...

Simon Marlow

2:13 p.m.

New subject: Deprecating Exports (#134); Recommendation: accept

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

Joachim Breitner

23 Jun 23 Jun

12:13 p.m.

New subject: Deprecating Exports (#134); Recommendation: accept

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/

Richard Eisenberg

11:46 p.m.

New subject: Deprecating Exports (#134); Recommendation: accept

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

Joachim Breitner

8 Jul 8 Jul

9:47 p.m.

New subject: Deprecating Exports (#134); Recommendation: accept

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 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/

Richard Eisenberg

10:10 p.m.

New subject: Deprecating Exports (#134); Recommendation: accept

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

Joachim Breitner

14 Jul 14 Jul

2:52 p.m.

New subject: Deprecating Exports (#134); Recommendation: accept

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 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 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/

2502

Age (days ago)

2553

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Iavor Diatchki
Joachim Breitner
Richard Eisenberg
Simon Marlow