Stop the deprecation of Data.Monoid.{First,Last}

Hi! For two years there has been a plan ([1], [12]) to deprecate and eventually remove Data.Monoid.{First,Last} ([13]), in order to resolve the name conflict with Data.Semigroup.{First,Last} ([14]). While implementing ([2]) this plan in GHC and the core libraries, and testing the migration in a few packages, I encountered some difficulties which made me question whether the benefits of the deprecation would outweigh its costs: * Code that previously used Data.Monoid.{First,Last} becomes noisier. See e.g. a patch to migrate the summoner package ([3]). * Higher Kinded Data applications of D.M.{First,Last} such as in higgledy ([4]) are difficult to migrate, partly due to missing instances for D.S.{First,Last} ([5]). * Additionally, there's an important difference in the strictness of the Semigroup instances for D.M.{First.Last} and the suggested replacement of (Maybe D.S.{First,Last}): [6], [9]. In sum, the existing migration story is painful in multiple ways. Moreover, D.S.{First,Last} don't actually seem to be useful in practice. I couldn't find any code using them except to define the usual newtype instances. In consequence, I think the deprecation should be scrapped, and the documentation of base updated accordingly. Regarding alternative ways to resolve the name clash, I see the following options: A) Deprecate and remove D.S.{First,Last}. B) Rename D.S.{First,Last}. C) Do nothing. Haskellers are already used to handling the name clash, usually via qualified imports. I would also like to mention that the process surrounding the deprecation has IMHO been somewhat less than ideal: 1. The deprecation was apparently decided without much research on how D.M.{First,Last} are being used in the ecosystem, and without properly testing the suggested migration. 2. Apart from the brief discussion on the libraries mailing list and changes to the haddocks ([7], [8]) for D.M.{First,Last}, there appears not to have been any announcement of the planned deprecation. 3. When, shortly after the haddocks changes, the strictness differences between D.M.First and (Maybe D.S.First) were pointed out on the libraries mailing list ([9]), the deprecation was apparently not reconsidered, nor the documentation updated. I myself wasn't aware of this aspect while I worked on the deprecation! 4. I should have sent this email 9 months ago, when I stopped working on the deprecation. The incorrect information in the haddocks has since caused some confusion ([10], [11]). What do you think? Cheers, Simon [1] https://mail.haskell.org/pipermail/libraries/2018-April/028712.html [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/842 [3] https://github.com/kowainik/summoner/pull/319 [4] https://github.com/i-am-tom/higgledy/issues/4 [5] https://gitlab.haskell.org/ghc/ghc/issues/16636 [6] https://gitlab.haskell.org/ghc/ghc/issues/17967 [7] https://gitlab.haskell.org/ghc/ghc/-/commit/e34e30e492a7bc40e3da5a05b8e297ac... [8] https://gitlab.haskell.org/ghc/ghc/-/commit/cf35ab9ac7e0f33e39af6af16ecf850e... [9] https://mail.haskell.org/pipermail/libraries/2018-May/028818.html [10] https://github.com/conal/checkers/issues/44 [11] https://gitlab.haskell.org/ghc/ghc/issues/18041 [12] https://gitlab.haskell.org/ghc/ghc/issues/15028 [13] http://downloads.haskell.org/~ghc/8.10.1/docs/html/libraries/base-4.14.0.0/D... [14] http://downloads.haskell.org/~ghc/8.10.1/docs/html/libraries/base-4.14.0.0/D...

Simon, Great and thorough explanation! Indeed the CLC was not sufficiently thorough here. I'm really sorry to anyone this deprecation notice has negatively impacted (Conal and Sandy, probably others). I should have been more vocal in the past about my thoughts that this was a bad idea. Since then, even more has been discovered which shows this to not be good overall. Again, I'm very sorry to anyone the deprecation notice may have negatively affected, and we will work harder to make sure things like this happen with as little frequency as possible. Also, FWIW, I'm in favour of (C), do nothing but correct the documentation, because I actually do use D.S.{First,Last} relatively often, especially with Foldable1. As I mentioned on the GHC Trac, I use both of these qualified. Thanks Simon for all of your work and all of your sleuthing. On Fri, Apr 10, 2020, 8:30 PM Simon Jakobi via Libraries < libraries@haskell.org> wrote:
Hi!
For two years there has been a plan ([1], [12]) to deprecate and eventually remove Data.Monoid.{First,Last} ([13]), in order to resolve the name conflict with Data.Semigroup.{First,Last} ([14]).
While implementing ([2]) this plan in GHC and the core libraries, and testing the migration in a few packages, I encountered some difficulties which made me question whether the benefits of the deprecation would outweigh its costs:
* Code that previously used Data.Monoid.{First,Last} becomes noisier. See e.g. a patch to migrate the summoner package ([3]).
* Higher Kinded Data applications of D.M.{First,Last} such as in higgledy ([4]) are difficult to migrate, partly due to missing instances for D.S.{First,Last} ([5]).
* Additionally, there's an important difference in the strictness of the Semigroup instances for D.M.{First.Last} and the suggested replacement of (Maybe D.S.{First,Last}): [6], [9].
In sum, the existing migration story is painful in multiple ways.
Moreover, D.S.{First,Last} don't actually seem to be useful in practice. I couldn't find any code using them except to define the usual newtype instances.
In consequence, I think the deprecation should be scrapped, and the documentation of base updated accordingly.
Regarding alternative ways to resolve the name clash, I see the following options:
A) Deprecate and remove D.S.{First,Last}. B) Rename D.S.{First,Last}. C) Do nothing. Haskellers are already used to handling the name clash, usually via qualified imports.
I would also like to mention that the process surrounding the deprecation has IMHO been somewhat less than ideal:
1. The deprecation was apparently decided without much research on how D.M.{First,Last} are being used in the ecosystem, and without properly testing the suggested migration.
2. Apart from the brief discussion on the libraries mailing list and changes to the haddocks ([7], [8]) for D.M.{First,Last}, there appears not to have been any announcement of the planned deprecation.
3. When, shortly after the haddocks changes, the strictness differences between D.M.First and (Maybe D.S.First) were pointed out on the libraries mailing list ([9]), the deprecation was apparently not reconsidered, nor the documentation updated. I myself wasn't aware of this aspect while I worked on the deprecation!
4. I should have sent this email 9 months ago, when I stopped working on the deprecation. The incorrect information in the haddocks has since caused some confusion ([10], [11]).
What do you think?
Cheers, Simon
[1] https://mail.haskell.org/pipermail/libraries/2018-April/028712.html [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/842 [3] https://github.com/kowainik/summoner/pull/319 [4] https://github.com/i-am-tom/higgledy/issues/4 [5] https://gitlab.haskell.org/ghc/ghc/issues/16636 [6] https://gitlab.haskell.org/ghc/ghc/issues/17967 [7] https://gitlab.haskell.org/ghc/ghc/-/commit/e34e30e492a7bc40e3da5a05b8e297ac... [8] https://gitlab.haskell.org/ghc/ghc/-/commit/cf35ab9ac7e0f33e39af6af16ecf850e... [9] https://mail.haskell.org/pipermail/libraries/2018-May/028818.html [10] https://github.com/conal/checkers/issues/44 [11] https://gitlab.haskell.org/ghc/ghc/issues/18041 [12] https://gitlab.haskell.org/ghc/ghc/issues/15028 [13] http://downloads.haskell.org/~ghc/8.10.1/docs/html/libraries/base-4.14.0.0/D... [14] http://downloads.haskell.org/~ghc/8.10.1/docs/html/libraries/base-4.14.0.0/D... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Sat, 11 Apr 2020, Simon Jakobi via Libraries wrote:
For two years there has been a plan ([1], [12]) to deprecate and eventually remove Data.Monoid.{First,Last} ([13]), in order to resolve the name conflict with Data.Semigroup.{First,Last} ([14]).
I find it sad, that in 2020 we still discuss removing things because of name clashes. In order to conform to the PVP we should import explicitly or with qualification anyway. If users depend on the Maybe-First in Monoid then I am happy with maintaining both Semigroup.First and Monoid.First.

Thank you for this writeup Simon.
At this stage I would lean towards stopping the deprecation with
option C (do nothing to resolve the name clash).
I would be interested to hear some counter-arguments however.
Cheers,
George
On Sat, 11 Apr 2020 at 16:59, Henning Thielemann
On Sat, 11 Apr 2020, Simon Jakobi via Libraries wrote:
For two years there has been a plan ([1], [12]) to deprecate and eventually remove Data.Monoid.{First,Last} ([13]), in order to resolve the name conflict with Data.Semigroup.{First,Last} ([14]).
I find it sad, that in 2020 we still discuss removing things because of name clashes. In order to conform to the PVP we should import explicitly or with qualification anyway. If users depend on the Maybe-First in Monoid then I am happy with maintaining both Semigroup.First and Monoid.First. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Thanks for the feedback, everyone! :) Since option (C) received the most support, I opened an MR to implement it: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154 Once it is merged, I will make an announcement of this change, as requested on r/haskell: https://www.reddit.com/r/haskell/comments/g3glwn/migration_path_for_last_c/f... Cheers, Simon

it might be good to add some remark that the semigroup version is *more* strict/the moniod version is *less* strict? On Sat, Apr 25, 2020 at 10:57 AM Simon Jakobi via Libraries < libraries@haskell.org> wrote:
Thanks for the feedback, everyone! :)
Since option (C) received the most support, I opened an MR to implement it:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154
Once it is merged, I will make an announcement of this change, as requested on r/haskell:
https://www.reddit.com/r/haskell/comments/g3glwn/migration_path_for_last_c/f...
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

or ... are we merely slowing down the deprecation path? are there technical
reasons aside from paucity of effort for eventual removal?
On Sat, Apr 25, 2020 at 1:13 PM Carter Schonwald
it might be good to add some remark that the semigroup version is *more* strict/the moniod version is *less* strict?
On Sat, Apr 25, 2020 at 10:57 AM Simon Jakobi via Libraries < libraries@haskell.org> wrote:
Thanks for the feedback, everyone! :)
Since option (C) received the most support, I opened an MR to implement it:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154
Once it is merged, I will make an announcement of this change, as requested on r/haskell:
https://www.reddit.com/r/haskell/comments/g3glwn/migration_path_for_last_c/f...
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

A deprecation would need a viable migration path. I don't have one,
and I don't want to invest more time into this right now.
I think we should refrain from anticipating a future deprecation since
that seems to cause library authors not to provide instances for these
types:
https://www.reddit.com/r/haskell/comments/g3glwn/migration_path_for_last_c/f...
Am Sa., 25. Apr. 2020 um 19:15 Uhr schrieb Carter Schonwald
or ... are we merely slowing down the deprecation path? are there technical reasons aside from paucity of effort for eventual removal?
On Sat, Apr 25, 2020 at 1:13 PM Carter Schonwald
wrote: it might be good to add some remark that the semigroup version is *more* strict/the moniod version is *less* strict?
On Sat, Apr 25, 2020 at 10:57 AM Simon Jakobi via Libraries
wrote: Thanks for the feedback, everyone! :)
Since option (C) received the most support, I opened an MR to implement it:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154
Once it is merged, I will make an announcement of this change, as requested on r/haskell:
https://www.reddit.com/r/haskell/comments/g3glwn/migration_path_for_last_c/f...
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Yes, the surprising strictness of Maybe's Semigroup instance should
probably be documented for now. It might be worth changing too, but
that should probably be discussed separately. (And it has been
discussed before:
https://mail.haskell.org/pipermail/libraries/2018-May/028818.html
)
Am Sa., 25. Apr. 2020 um 19:14 Uhr schrieb Carter Schonwald
it might be good to add some remark that the semigroup version is *more* strict/the moniod version is *less* strict?
On Sat, Apr 25, 2020 at 10:57 AM Simon Jakobi via Libraries
wrote: Thanks for the feedback, everyone! :)
Since option (C) received the most support, I opened an MR to implement it:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154
Once it is merged, I will make an announcement of this change, as requested on r/haskell:
https://www.reddit.com/r/haskell/comments/g3glwn/migration_path_for_last_c/f...
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Apropos of this, can we get flexible instances for Compose?
It seems like there's some agreement that ignoring the composition is the most useful way to generate fully saturated instances (since requiring e.g. 'composition of a monoid with semigroup' is more useful than 'composition of a monoid with a monoid').
—
Sent from my phone with K-9 Mail.
On April 25, 2020 10:56:35 AM EDT, Simon Jakobi via Libraries
Thanks for the feedback, everyone! :)
Since option (C) received the most support, I opened an MR to implement it:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154
Once it is merged, I will make an announcement of this change, as requested on r/haskell:
https://www.reddit.com/r/haskell/comments/g3glwn/migration_path_for_last_c/f...
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Hi Keith,
Pzlease see https://gitlab.haskell.org/ghc/ghc/issues/17859, and feel
free to comment there.
Cheers,
Simon
Am Di., 28. Apr. 2020 um 15:20 Uhr schrieb Keith
Apropos of this, can we get flexible instances for Compose?
It seems like there's some agreement that ignoring the composition is the most useful way to generate fully saturated instances (since requiring e.g. 'composition of a monoid with semigroup' is more useful than 'composition of a monoid with a monoid'). — Sent from my phone with K-9 Mail.
On April 25, 2020 10:56:35 AM EDT, Simon Jakobi via Libraries
wrote: Thanks for the feedback, everyone! :)
Since option (C) received the most support, I opened an MR to implement it:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154
Once it is merged, I will make an announcement of this change, as requested on r/haskell:
https://www.reddit.com/r/haskell/comments/g3glwn/migration_path_for_last_c/f...
Cheers, Simon ________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Carter, Daniel: Could you either approve !3154 or suggest an improvement or a different course of action? Thanks! :) Simon Am Sa., 25. Apr. 2020 um 16:56 Uhr schrieb Simon Jakobi < simon.jakobi@googlemail.com>:
Thanks for the feedback, everyone! :)
Since option (C) received the most support, I opened an MR to implement it:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154
Once it is merged, I will make an announcement of this change, as requested on r/haskell:
https://www.reddit.com/r/haskell/comments/g3glwn/migration_path_for_last_c/f...
Cheers, Simon

Hi! I have just rebased my MR https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154. Carter, Daniel: Both of you should have the necessary permissions to approve the MR now. Please do so or let me know why you do not approve. Carter: To expand on my somewhat brusque answer (apologies!) to your questions:
are we merely slowing down the deprecation path? are there technical reasons aside from paucity of effort for eventual removal?
As I tried to explain in the original email of this thread (https://mail.haskell.org/pipermail/libraries/2020-April/030357.html), it took me quite a lot of effort to discover the issues with the old migration path. I'd expect that vetting any other migration plan would take a similar amount of effort. As long as no one volunteers to explore a new migration path, I believe we shouldn't speculate that the deprecation will eventually happen. In any case, I currently believe that any removal of Data.Monoid.{First,Last} would cause substantial inconvenience for their current users. If you would still like to resolve the name conflict, I believe that the easier path would be to rename Data.Semigroup.{First,Last} which AFAICT are still used much less than the Monoid versions. I'll leave it to others to propose any such change. Cheers! Simon

Pardon the delay, busy month! (Though it’s a strange busy stressful time for many I suppose) Pester me on irc if I don’t followup in the next two days. :) On Mon, May 25, 2020 at 6:25 PM Simon Jakobi via Libraries < libraries@haskell.org> wrote:
Hi!
I have just rebased my MR https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3154.
Carter, Daniel: Both of you should have the necessary permissions to approve the MR now. Please do so or let me know why you do not approve.
Carter: To expand on my somewhat brusque answer (apologies!) to your questions:
are we merely slowing down the deprecation path? are there technical reasons aside from paucity of effort for eventual removal?
As I tried to explain in the original email of this thread (https://mail.haskell.org/pipermail/libraries/2020-April/030357.html), it took me quite a lot of effort to discover the issues with the old migration path. I'd expect that vetting any other migration plan would take a similar amount of effort. As long as no one volunteers to explore a new migration path, I believe we shouldn't speculate that the deprecation will eventually happen.
In any case, I currently believe that any removal of Data.Monoid.{First,Last} would cause substantial inconvenience for their current users.
If you would still like to resolve the name conflict, I believe that the easier path would be to rename Data.Semigroup.{First,Last} which AFAICT are still used much less than the Monoid versions.
I'll leave it to others to propose any such change.
Cheers!
Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
participants (6)
-
Carter Schonwald
-
chessai .
-
George Wilson
-
Henning Thielemann
-
Keith
-
Simon Jakobi