Re: Proposal: Make Semigroup as a superclass of Monoid

my one concern is that we'd be force to give all the various map data structures out there a left biased "First" style semigroup instance if we keep the current default monoid instances that containers and list-tries provide for historical reasons. and at least in the applications i write, i want the semigroup that merges those keys. On Sun, Mar 29, 2015 at 3:14 PM, Evan Laforge wrote:

On Sun, Mar 29, 2015 at 5:20 AM, Jeremy wrote:

...

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.

I think I'm generally in favor, but in my experience is the reverse of this. I have tons of Monoids and only a few Monads. All of my Monads also had Applicative defined because I wanted to use (<$>) and (<*>), however none of my Monoids have Semigroup, because they all have a natural mempty, and there's nothing "extra" in Semigroup that would tempt me to add an instance. So while AMP meant no changes for me, "Semi MP" would definitely force code changes in many places (every 'instance .*Monoid', which is 31 in one project).

That said I don't have to worry about backward compatibility so I don't mind. For someone who maintains libraries, they would have to add a dependency on 'semigroup', which is going to pull in a number of other dependencies, but it mostly seems to be stuff people are probably already depending on. Except unordered-containers maybe. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries