Monoid for ZipList

Edward Kmett ekmett at
Fri May 4 22:04:05 UTC 2018

It is worth noting that Maybe a and [a] are rather special cases. The former is the monoid you get from adjoining a unit to a semigroup. The latter is the free monoid. Most other monoids for things wrapped in an applicative are either based on the Alternative instance which inherently provides a monoidal structure or based on lifting a monoid pointwise into the data type. 

Here we have at least 3-4 possible, quite reasonable, monoids at play, and no real reason to choose any one of them over the others. In that situation, our general practice thus far has been to resist choosing if a choice hasn't already been made, simply because there is no real manner other than memorization / code inspection for a user to know which instance we happened to pick.

I'm -1 on adding the instance proposed here.

Sent from my iPhone

> On May 3, 2018, at 7:40 PM, 박신환 <ndospark320 at> wrote:
> I aim to make the semantic consistent compared to that of other type classes (here Maybe).
> Also note that your instance is identical to upcoming Ap, as Ap (ZipList a). I also aim to make Monoids as diverse as possible. 
> -----Original Message-----
> From: "Andrew Martin"<andrew.thaddeus at> 
> To: "박신환"<ndospark320 at>; 
> Cc: "Haskell Libraries"<libraries at>; 
> Sent: 2018-05-03 (목) 21:05:24
> Subject: Re: Monoid for ZipList
> There is another possible instance. We can instead write:
>     instance Semigroup a => Semigroup (ZipList a) where
>       (<>) = liftA2 (<>)
>     instance Monoid a => Monoid (ZipList a) where
>       mempty = pure mempty
> This behaves differently, and it is also law-abiding.
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list