Hi,

I wasn't aware of that. I don't understand your a) and b) points though. Semigroup is a superclass of Monoid, so doesn't that already express the necessity that everyting which is a Monoid is also a Semigroup? And there's also no boilerplate manual aliasing in my version of your example, or is it?


On Saturday, 14 September 2019, 20:52:56 UTC, Georgi Lyubenov <godzbanebane@gmail.com> wrote:


Haskell allows you to "recursively" define instances of superclasses with functions defined in subclass instances. This is fine:
```
data List a ...
instance Monoid (List a) ...
-- give a definition for mappend here
instance Semigroup (List a) where
  (<>) = mappend
```
You can do a similar thing by first defining Monad for a type and then giving implementations for Functor and Applicative by using Control.Monad.liftM and Control.Monad.ap
The benefit is that you can
a) directly express the necessity that everything which is a Monoid is also a Semigroup already
b) not write the boilerplate of manually aliasing (<>) to mappend
(and in general for bigger chains of typeclasses/more typeclass functions this becomes more convenient)

On Sat, Sep 14, 2019 at 11:36 PM John Villarreal <j0villarreal@yahoo.com> wrote:
Hello Georgi,


I'm confused about WrappedMonoid. How can something have a Monoid instance already without having a Semigroup instance in the first place?

But also what is the benefit of WrappedMonoid over the standard way of defining Semigroups and Monoids for your example

data List a = Nil | Cons a (List a)

instance Semigroup (List a) where
  Nil       <> ys = ys
  Cons x xs <> ys = Cons x (xs <> ys)

instance Monoid (List a) where mempty = Nil

?

Cheers,
John


On Saturday, 14 September 2019, 19:18:01 UTC, Georgi Lyubenov <godzbanebane@gmail.com> wrote:


Hello!

Sorry if this is not the right place to ask!

As of right now (14.09.2019) Data.Semigroup.WrappedMonoid is slated to be deprecated.

I believe that this newtype is actually useful in tandem with DerivingVia, as it allows you to derive the Semigroup instance for something that has a Monoid instance already, as discussed in this twitter thread.

Would it be possible to *not* deprecate it in the future, and instead keep it around for exactly this purpose?

Cheers,
Georgi
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries