Deprecate First and Last in Data.Monoid

[Edward Kmett]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180413/4222cb3d/attachment.html>