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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Haskell - Libraries mailing list
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/e34e30e492a7bc40e3da5a05b8e297acb0aeeadc
[8] https://gitlab.haskell.org/ghc/ghc/-/commit/cf35ab9ac7e0f33e39af6af16ecf850e24c2cb79
[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/Data-Monoid.html#t:First
[14] http://downloads.haskell.org/~ghc/8.10.1/docs/html/libraries/base-4.14.0.0/Data-Semigroup.html#t:First
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

chessai .
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 <[hidden email]> 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/e34e30e492a7bc40e3da5a05b8e297acb0aeeadc
[8] https://gitlab.haskell.org/ghc/ghc/-/commit/cf35ab9ac7e0f33e39af6af16ecf850e24c2cb79
[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/Data-Monoid.html#t:First
[14] http://downloads.haskell.org/~ghc/8.10.1/docs/html/libraries/base-4.14.0.0/Data-Semigroup.html#t:First
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann
In reply to this post by Haskell - Libraries mailing list

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

George Wilson
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
<[hidden email]> wrote:

>
>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Haskell - Libraries mailing list
In reply to this post by Haskell - Libraries mailing list
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/fnrfzf1/

Cheers,
Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> 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/fnrfzf1/

Cheers,
Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> 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 <[hidden email]> 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/fnrfzf1/

Cheers,
Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Haskell - Libraries mailing list
In reply to this post by Carter Schonwald
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
<[hidden email]>:

>
> 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 <[hidden email]> 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/fnrfzf1/
>>
>> Cheers,
>> Simon
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Haskell - Libraries mailing list
In reply to this post by Carter Schonwald
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/fnrfzf1/

Am Sa., 25. Apr. 2020 um 19:15 Uhr schrieb Carter Schonwald
<[hidden email]>:

>
> 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 <[hidden email]> 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 <[hidden email]> 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/fnrfzf1/
>>>
>>> Cheers,
>>> Simon
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Keith
In reply to this post by Haskell - Libraries mailing list
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 <[hidden email]> 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/fnrfzf1/

Cheers,
Simon
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Haskell - Libraries mailing list
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 <[hidden email]>:

>
> 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 <[hidden email]> 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/fnrfzf1/
>>
>> Cheers,
>> Simon
>> ________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Haskell - Libraries mailing list
In reply to this post by Haskell - Libraries mailing list
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 <[hidden email]>:
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/fnrfzf1/

Cheers,
Simon

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Haskell - Libraries mailing list
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries