Please consider GHC Proposal #575 for acceptance.

Dear Steering Committee, I strongly endorse GHC Proposal #575 https://github.com/ghc-proposals/ghc-proposals/pull/575, which suggests the introduction of deprecation pragmas on instances. The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities. The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience. In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration. Best Regards, Moritz

LGTM +1
On 19 May 2023, at 10:05, Moritz Angermann
wrote: Dear Steering Committee,
I strongly endorse GHC Proposal #575 https://github.com/ghc-proposals/ghc-proposals/pull/575, which suggests the introduction of deprecation pragmas on instances.
The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration.
Best Regards, Moritz
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

This mostly seems like an obvious win. Evolvability demands that any artifact that we produce support deprecations warnings. The one concern I have that is somewhat unique to deprecating instances is that users don't *explicitly* use an instance. There's an implicit chain of resolutions that leads to the use of a deprecated instance. Will that make it hard for users to understand *why* their program is bad, and *how* to fix it? It might just be brevity on Vlad's part, but I found it notable that the NFData example[1] just says "Don't use NFData (a -> b)." It gives no advice on what to do instead. With function deprecations it's usually easy to suggest replacements. I don't think this is a reason to reject the proposal, probably just something that library authors will need to be careful about when deprecating instances. [1]: https://github.com/int-index/ghc-proposals/blob/int-index/deprecated-instanc... On Fri, May 19, 2023, at 05:05, Moritz Angermann wrote:
Dear Steering Committee,
I strongly endorse GHC Proposal #575 https://github.com/ghc-proposals/ghc-proposals/pull/575, which suggests the introduction of deprecation pragmas on instances.
The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration.
Best Regards, Moritz
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I support acceptance, but I have asked a question about syntax.
Simon
On Fri, 19 May 2023 at 10:05, Moritz Angermann
Dear Steering Committee,
I strongly endorse GHC Proposal #575 https://github.com/ghc-proposals/ghc-proposals/pull/575, which suggests the introduction of deprecation pragmas on instances.
The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration.
Best Regards, Moritz _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I support acceptance as well. Eric's concern is a good point, but it probably shouldn't be an obstacle to acceptance as 1/ the current proposal is still a clear improvement on the situation 2/ it's unlikely that there is a cost-effective way to improve on this axis. Adam complains about semantics in the Github thread [1]. Probably something worth improving before merging. [1]: https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r12136538... On Wed, 24 May 2023 at 11:10, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
I support acceptance, but I have asked a question about syntax.
Simon
On Fri, 19 May 2023 at 10:05, Moritz Angermann
wrote: Dear Steering Committee,
I strongly endorse GHC Proposal #575 https://github.com/ghc-proposals/ghc-proposals/pull/575, which suggests the introduction of deprecation pragmas on instances.
The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration.
Best Regards, Moritz _______________________________________________ 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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Yes, to be clear I don't my concern as something to block on, it's a watch-out-for for library authors. On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote:
I support acceptance as well.
Eric's concern is a good point, but it probably shouldn't be an obstacle to acceptance as 1/ the current proposal is still a clear improvement on the situation 2/ it's unlikely that there is a cost-effective way to improve on this axis.
Adam complains about semantics in the Github thread [1]. Probably something worth improving before merging.
[1]: https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r12136538...
On Wed, 24 May 2023 at 11:10, Simon Peyton Jones
wrote: I support acceptance, but I have asked a question about syntax.
Simon
On Fri, 19 May 2023 at 10:05, Moritz Angermann
wrote: Dear Steering Committee,
I strongly endorse GHC Proposal #575 https://github.com/ghc-proposals/ghc-proposals/pull/575, which suggests the introduction of deprecation pragmas on instances.
The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration.
Best Regards, Moritz
_______________________________________________ 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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Dear all,
I believe the remaining concerns have been addressed. Are there any further
concerns
regarding this proposal? Otherwise, I recommend we accept it.
Cheers,
Moritz
On Wed, 7 Jun 2023 at 22:59, Eric Seidel
Yes, to be clear I don't my concern as something to block on, it's a watch-out-for for library authors.
On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote:
I support acceptance as well.
Eric's concern is a good point, but it probably shouldn't be an obstacle to acceptance as 1/ the current proposal is still a clear improvement on the situation 2/ it's unlikely that there is a cost-effective way to improve on this axis.
Adam complains about semantics in the Github thread [1]. Probably something worth improving before merging.
[1]:
https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r12136538...
On Wed, 24 May 2023 at 11:10, Simon Peyton Jones
wrote: I support acceptance, but I have asked a question about syntax.
Simon
On Fri, 19 May 2023 at 10:05, Moritz Angermann <
Dear Steering Committee,
I strongly endorse GHC Proposal #575 < https://github.com/ghc-proposals/ghc-proposals/pull/575>, which suggests
The proposal is a logical extension of Haskell's existing deprecation
facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
The lack of instance deprecation hinders controlled evolution of
moritz.angermann@gmail.com> wrote: the introduction of deprecation pragmas on instances. libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
In summary, Proposal #575 represents a valuable improvement for
Haskell. I urge the committee to give it favorable consideration.
Best Regards, Moritz
_______________________________________________ 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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ 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

I'm in support, this is a nice improvement. Cheers, Adam On 28/06/2023 06:18, Moritz Angermann wrote:
Dear all,
I believe the remaining concerns have been addressed. Are there any further concerns regarding this proposal? Otherwise, I recommend we accept it.
Cheers, Moritz
On Wed, 7 Jun 2023 at 22:59, Eric Seidel
mailto:eric@seidel.io> wrote: Yes, to be clear I don't my concern as something to block on, it's a watch-out-for for library authors.
On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote: > I support acceptance as well. > > Eric's concern is a good point, but it probably shouldn't be an > obstacle to acceptance as 1/ the current proposal is still a clear > improvement on the situation 2/ it's unlikely that there is a > cost-effective way to improve on this axis. > > Adam complains about semantics in the Github thread [1]. Probably > something worth improving before merging. > > [1]: > https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r12136538... https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r12136538... > > On Wed, 24 May 2023 at 11:10, Simon Peyton Jones >
mailto:simon.peytonjones@gmail.com> wrote: >> I support acceptance, but I have asked a question about syntax. >> >> Simon >> >> On Fri, 19 May 2023 at 10:05, Moritz Angermann mailto:moritz.angermann@gmail.com> wrote: >>> Dear Steering Committee, >>> >>> I strongly endorse GHC Proposal #575 <https://github.com/ghc-proposals/ghc-proposals/pull/575 https://github.com/ghc-proposals/ghc-proposals/pull/575>, which suggests the introduction of deprecation pragmas on instances. >>> >>> The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities. >>> >>> The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience. >>> >>> In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration. >>> >>> Best Regards, Moritz
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

I'm happy to accept.
I think I would gone a little further, and allowed the pragmas to appear in
either order (DEPRECATED then OVERLAPPABLE or OVERLAPPABLE then
DEPRECATED), but the proposal allows on the former.
But it's a matter of taste and I'm OK with the choice.
Simon
On Wed, 28 Jun 2023 at 06:19, Moritz Angermann
Dear all,
I believe the remaining concerns have been addressed. Are there any further concerns regarding this proposal? Otherwise, I recommend we accept it.
Cheers, Moritz
On Wed, 7 Jun 2023 at 22:59, Eric Seidel
wrote: Yes, to be clear I don't my concern as something to block on, it's a watch-out-for for library authors.
On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote:
I support acceptance as well.
Eric's concern is a good point, but it probably shouldn't be an obstacle to acceptance as 1/ the current proposal is still a clear improvement on the situation 2/ it's unlikely that there is a cost-effective way to improve on this axis.
Adam complains about semantics in the Github thread [1]. Probably something worth improving before merging.
[1]:
https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r12136538...
On Wed, 24 May 2023 at 11:10, Simon Peyton Jones
wrote: I support acceptance, but I have asked a question about syntax.
Simon
On Fri, 19 May 2023 at 10:05, Moritz Angermann <
Dear Steering Committee,
I strongly endorse GHC Proposal #575 < https://github.com/ghc-proposals/ghc-proposals/pull/575>, which suggests
The proposal is a logical extension of Haskell's existing deprecation
facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
The lack of instance deprecation hinders controlled evolution of
moritz.angermann@gmail.com> wrote: the introduction of deprecation pragmas on instances. libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
In summary, Proposal #575 represents a valuable improvement for
Haskell. I urge the committee to give it favorable consideration.
Best Regards, Moritz
_______________________________________________ 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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ 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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, with plenty of supporting voices and no dissent, this is accepted. Will merge. Cheers, Joachim Am Mittwoch, dem 28.06.2023 um 07:18 +0200 schrieb Moritz Angermann:
Dear all,
I believe the remaining concerns have been addressed. Are there any further concerns regarding this proposal? Otherwise, I recommend we accept it.
Cheers, Moritz
On Wed, 7 Jun 2023 at 22:59, Eric Seidel
wrote: Yes, to be clear I don't my concern as something to block on, it's a watch-out-for for library authors.
On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote:
I support acceptance as well.
Eric's concern is a good point, but it probably shouldn't be an obstacle to acceptance as 1/ the current proposal is still a clear improvement on the situation 2/ it's unlikely that there is a cost-effective way to improve on this axis.
Adam complains about semantics in the Github thread [1]. Probably something worth improving before merging.
[1]: https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r12136538...
On Wed, 24 May 2023 at 11:10, Simon Peyton Jones
wrote: I support acceptance, but I have asked a question about syntax.
Simon
On Fri, 19 May 2023 at 10:05, Moritz Angermann
wrote: Dear Steering Committee,
I strongly endorse GHC Proposal #575 https://github.com/ghc-proposals/ghc-proposals/pull/575, which suggests the introduction of deprecation pragmas on instances.
The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration.
Best Regards, Moritz
_______________________________________________ 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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ 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
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 (7)
-
Adam Gundry
-
Arnaud Spiwack
-
Chris Dornan
-
Eric Seidel
-
Joachim Breitner
-
Moritz Angermann
-
Simon Peyton Jones