<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Good morning all,<div><br></div><div>I have now split Richard's commit in two, so that it's explicit in the commit history that we are adding those instances:</div><div><br></div><div><a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5509/diffs?commit_id=2cbad0e7ced9de896eb9a1732631786a6adb676a">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5509/diffs?commit_id=2cbad0e7ced9de896eb9a1732631786a6adb676a</a><br></div><div><br></div><div><u>Ben</u>: I have briefly tried to add the Hlint annotations, but it turned out to be trickier than anticipated. I couldn't find any easy way in HLint to add a custom hint on a *typeclass instance*, and adding something like this into `compiler/.hlint.yaml` didn't change anything:</div><div><br></div><div><div>- modules:</div><div>  - {name: GHC.Data.Bag, badidents: [mempty], message: "Use emptyBag as it's more descriptive"}</div><div>  - {name: GHC.Data.Bag, badidents: [(<>)], message: "Use unionBags as it's more descriptive"}</div></div><div><br></div><div>(I suspect that's not what's the badidents syntax is for). I have also tried to add two `ANN` to the definitions, like this:</div><div><br></div><div><div>{-# ANN (<>) ("HLint: use unionBags as it's more descriptive" :: String) #-}</div><div>instance Semigroup (Bag a) where</div><div>  (<>) = unionBags</div></div><div><br></div><div>However, this won't work as (<>) is imported qualified and there is no way in the ANN syntax to specify a fully qualified identifier. However, I suspect this is not the correct syntax either, as `(<>)` is really the *typeclass* method, but we want to target the particular instance implementation.</div><div><br></div><div><u>Having said that</u>, Richard carefully defined `(<>) = unionBags` and `mempty = emptyBag`, so I agree that using `(<>)` and `mempty` would be more opaque but at the end of the day it should have the asymptotic complexity than using `unionBags` and `emptyBag` (modulo dictionary passing, but I hope that won't each our lunch). </div><div><br></div><div>A.</div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Apr 2021 at 02:20, Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>> writes:<br>
<br>
> Hi devs,<br>
><br>
> In the work on simplifying the error-message infrastructure (heavy lifting by Alfredo, in cc), I've been tempted (twice!) to add<br>
><br>
>> instance Semigroup (Bag a) where<br>
>>   (<>) = unionBags<br>
>> <br>
>> instance Monoid (Bag a) where<br>
>>   mempty = emptyBag<br>
><br>
> to GHC.Data.Bag.<br>
><br>
> The downside to writing these is that users might be tempted to write<br>
> e.g. mempty instead of emptyBag, while the latter gives more<br>
> information to readers and induces less manual type inference (to a<br>
> human reader). The upside is that it means Bags work well with<br>
> Monoid-oriented functions, like foldMap.<br>
><br>
> I favor adding them, and slipped them into !5509 (a big commit with<br>
> lots of other stuff). Alfredo rightly wondered whether this decision<br>
> deserved more scrutiny, and so I'm asking the question here.<br>
><br>
My sense is that adding the instances is a Good Thing. However, I do<br>
think that we probably ought to refrain from using (<>) and mempty where<br>
more specific functions would do. Adding a lint would be one way to<br>
accomplish this. Hiding the functions from GhcPrelude would be another.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>