Proposal: Make Semigroup as a superclass of Monoid

[Carter Schonwald]

Greg,

the proposal is for Semigroup s => Monoid s, not  for Monoid s => Semigroup
s , which is what i believe you're reading the proposal to say.

a large number of statistical aggregatory and analytical data structures
are semigroups but emphatically not monoids because they lack the notion of
a zero element! over the past 8 months alone i've probably 5-10 different
data structures for statistical ingestion that were semigroups but not
monoids.

point being, semigroups are well defined  mathematical objects, and i deal
with many many things that are semigroups and not monoids, especially in
data analysis application domains.  I can provide a few example later this
week if you want.


On Sun, Mar 29, 2015 at 8:33 PM, Greg Weber <greg at gregweber.info> wrote:

> > 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.
>
> 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 Semigroup
>
> 1) a structure that is already a Monoid
> 2) a structure that is a non-empty form of a Monoid
> 3) a structure where mempty is not constant but a function of the element
> you would concatenate it to
>
> An 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 at 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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150329/7e0b69d6/attachment.html>