<div dir="ltr">Ryan, sounds good to meĀ </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 26, 2019 at 9:17 AM Ryan Scott <<a href="mailto:ryan.gl.scott@gmail.com">ryan.gl.scott@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
You may find the discussion at<br>
<a href="https://mail.haskell.org/pipermail/libraries/2018-February/028571.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/libraries/2018-February/028571.html</a><br>
interesting. The summarized version of that post is that<br>
Data.Functor.Compose was originally brought over from the transformers<br>
library, which adheres to a very Haskell98 mindset in its design. In<br>
particular, the maintainer of transformers would likely not have added<br>
the Semigroup or Monoid instances you propose, since they require the<br>
FlexibleContexts language extension. This explains why there exists an<br>
`instance (Eq1 f, Eq1 g, Eq a) => Eq (Compose f g a)` and not an<br>
`instance Eq (f (g a)) => Eq (Compose f g a)`, among other things.<br>
<br>
Of course, Data.Functor.Compose now lives in the base library, not<br>
transformers, so we need not prescribe to the same design philosophy.<br>
I don't feel too strongly about the issue, so if other people feel<br>
like adding Semigroup/Monoid instances that require FlexibleContexts<br>
is a good idea, I could get on board with that. What do others think?<br>
<br>
Ryan S.<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">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-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>