> 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoidinstances, and anything else which forms a Semigroup, will have a Semigroup
instance. GHC will issue a warning when it encounters an instance of Monoid
which is not an instance of Semigroup.There is going to be some push-back on this proposal from those that point out the lack of mempty makes Semigroup less rigorous that a Monoid. That concept can create a debate around what is "anything else which forms a semigroup".I would try to amend the proposal to something much more specific.Here is how I have used Semigroup1) a structure that is already a Monoid2) a structure that is a non-empty form of a Monoid3) a structure where mempty is not constant but a function of the element you would concatenate it toAn example of 3) is concatenating bounding boxes. A zeroed box is certainly an empty box, but it will create a larger box when concatenated with an existing box.The identity concatenation of the current bounding box is always the current bounding box.What other structures do you use Semigroup for?Are there structures in base where there would be a debate about adding an instance?Can we come up with rules for when a Semigroup instance should be added to base?On Sun, Mar 29, 2015 at 5:20 AM, Jeremy <voldermort@hotmail.com> wrote:The proposal to make Semigroup a superclass of Monoid was discussed a while
ago [1], and the conclusion was to "put this off until the dust has settled
from the AMP and FT changes".
Now that 7.10 is out, I would like to re-propose. The proposed plan is
similar to AMP, but less invasive, as (in my subjective experience)
user-defined Monoids are much less common than user-defined Monads.
1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid
instances, and anything else which forms a Semigroup, will have a Semigroup
instance. GHC will issue a warning when it encounters an instance of Monoid
which is not an instance of Semigroup.
2. GHC >7.12 will define Monoid as a subclass of Semigroup.
Stage 2 could be delayed - or in the extreme case, cancelled - if the
warnings following stage 1 indicate that the proposal would cause
significant breakage of existing code, although this is not anticipated.
The rationale for this change is:
1. Semigroup is a popular package (this is relevant in combination with the
following point).
2. Using an existing Monoid as a Semigroup requires redefining it (or
WrappedMonoid), leading to much boilerplate and duplication.
3. NonEmpty is often redefined by beginners (or those who don't think it's
worth having an extra dependency for).
[1] https://mail.haskell.org/pipermail/libraries/2013-June/020188.html
--
View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-tp5767835.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.
_______________________________________________
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