Deprecate First and Last in Data.Monoid

[Simon Jakobi]

I have made an MR to deprecate Data.Semigroup.Option:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3388

Am Fr., 13. Apr. 2018 um 18:15 Uhr schrieb Edward Kmett <ekmett at gmail.com>:
>
> I'm +1 on doing this in general.
>
> However, the timing may need to be adjusted slightly in light of the 3-release policy, with which one could argue would indicate that the deprecation warning shouldn't happen until 8.8, though the removal could still happen in 8.10.
>
> The issue there comes from the fact that we're just now getting Semigroup as a superclass of Monoid, so if you want to write code compatible across 3 releases without warnings, for each range of 3 releases sliding over time, as of 8.6 there'd be a window where you couldn't necessarily use Semigroup.First/Last on 8.2 (the bottom edge of the window) in all situations, but the deprecation warning would be screaming at you anyways. An end-goal of being done with this by 8.10 fits nicely, though. Ironically the 3-release policy makes this a bit worse as it'd allow us to straight up remove it in 8.8 sans deprecation, but not warn in 8.6, so 8.10 with deprecation in 8.8 seems a sensible choice.
>
> The Option type can go through the same deprecation timing. It only existed because of the old Monoid instance for Maybe.
>
> -Edward
>
> On Wed, Apr 11, 2018 at 7:46 PM, Andrew Martin <andrew.thaddeus at gmail.com> wrote:
>>
>> I propose that the data types First and Last, provided by Data.Monoid, be marked deprecated in GHC 8.6 and removed in GHC 8.10. The Semigroup-Monoid Proposal (SMP) brought about changes that, I will argue, make these data types (1) unneeded and (2) confusing.
>>
>> Why are they no longer needed? Data.Semigroup provides two identically named data types (First and Last). These have Semigroup instances matches what their names suggest. Additionally, SMP corrects the Monoid instance for Maybe so that it now lifts Semigroup instances instead of Monoid instances. What this means is that, assuming the following imports:
>>
>>     import qualified Data.Monoid as M
>>     import qualified Data.Semigroup as S
>>
>> We have the following equivalences:
>>
>>     M.First a === Maybe (M.First a)
>>     M.Last a === Maybe (M.Last a)
>>
>> When I say "equivalence", I mean that their Monoid instances have the same behavior. Their Show/Read instances are certainly different, and I’m not sure about their Ord instances.
>>
>> Getting back to the second reason, removing these data types would eliminate confusion. It’s strange that Semigroup is a superclass of Monoid, yet they have Data types with conflicting names defined in their respective modules. When you see the data type First, you cannot tell what someone is talking additional context. In general, base strives to avoid duplicate identifiers. The only other exception to this rule I can think of is that Bifunctor and Arrow both use the identifiers first and second. But, the situation  with Data.Semigroup and Data.Monoid is higher impact since people are more likely to import these modules unqualified together.
>>
>> (As an aside, and the confusion I’m talking about here isn’t entirely hypothetical. I got tripped up by this when I first started using the semigroups library. I had to train myself to stop importing Data.Monoid unqualified, because it kept stealing these identifiers)
>>
>> Again, the two reasons are that these are no longer necessary and that they cause confusion. I would appreciate any feedback, including simple nods of agreement or disagreement. Thanks.
>>
>> --
>> -Andrew Thaddeus Martin
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries