<div dir="ltr">+1 for adding the instances.<div><br></div><div>I'm fairly neutral on the helpers.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 21, 2018 at 1:16 PM, Ryan Scott <span dir="ltr"><<a href="mailto:ryan.gl.scott@gmail.com" target="_blank">ryan.gl.scott@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In response to each of your proposals:<br>
<span class=""><br>
> 1. Add an instance (Monoid c => Applicative (K1 i c))<br>
<br>
</span>This seems like a no-brainer to me. +1<br>
<span class=""><br>
> 2. Add helpers<br>
><br>
>          gmempty :: (Generic a, Applicative (Rep a)) => a<br>
>          gmempty = to (pure ())<br>
><br>
>          gmappend :: (Generic a, Applicative (Rep a)) => a -> a -> a<br>
>          gmappend a b = to (from a <*> from b)<br>
><br>
>          -- also gpure, gap for generic Applicative<br>
<br>
</span>I'm weakly -1 on this. I don't think GHC.Generics should be a place<br>
where we collect combinators for generically implementing various type<br>
class methods. I'd prefer that these be left to downstream libraries,<br>
especially since they're usually extremely straightforward to<br>
implement and wouldn't cross the Fairbairn threshold for me.<br>
<br>
> 3. Add Monoid instances<br>
<br>
I think I support this idea. But just to be sure we're on the same<br>
page: can you say which instances in particular you're adding, and how<br>
you'd implement them?<br>
<br>
Ryan S.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>