<div dir="ltr"><a href="http://hackage.haskell.org/package/EdisonCore">http://hackage.haskell.org/package/EdisonCore</a><br><div><br></div><div>the Edison packages come to mind as a previous effort in this space</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 29, 2019 at 4:08 PM Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</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">| having a common pattern for naming the operations certainly seems<br>
| nice. I am ambivalent if we do this with a class, or just name the<br>
| operations the same way, and use the module system. <br>
<br>
This was my reaction too. Consistent naming, yes. Using a type class, when every invocation is at a statically known type (i.e. not leveraging the type class) seems less good.<br>
<br>
For example, eqType :: Type -> Type -> Bool, and I can search for every invocation of eqType. That can be very useful. Searching for every use of (==) and figuring out which of those zillions of calls are for equality of Type, is much less attractive.<br>
<br>
But I'm not going to die in the trenches for this. You are doing us a service by making everything systematic. The code that is finally executed will, I hope and believe, be the same either way.<br>
<br>
Simon<br>
<br>
<br>
The type hackery I<br>
| was referring to was the type family for the set elements and map<br>
| keys you were referring to. It looks like the maps we have are<br>
| uniform enough that one type family per class does the job, so I think the<br>
| class you came with looks nice.<br>
| <br>
| -Iavor<br>
| PS: the type hacker I was referring to was having to add more type<br>
| families, for example if we had a map that can only store one type of<br>
| elements, but it looks like this is not the case here.<br>
| <br>
| <br>
| On Wed, May 29, 2019 at 3:48 AM Andreas Klebinger<br>
| <<a href="mailto:klebinger.andreas@gmx.at" target="_blank">klebinger.andreas@gmx.at</a>> wrote:<br>
| ><br>
| > <a href="mailto:ghc-devs-request@haskell.org" target="_blank">ghc-devs-request@haskell.org</a> schrieb:<br>
| > > Hello,<br>
| > ><br>
| > > I think refactoring to use consistent naming is a good idea, but I<br>
| > > am not sure about the class idea.<br>
| > ><br>
| > > To see if it is viable, we should list the types in question and the<br>
| > > operations we'd like to overload.<br>
| > ><br>
| > > I find that with containers there tend to be two cases: either the<br>
| > > operations are similar but not exactly the same and you have to do<br>
| > > type hackery to make things fit, or you realize that you can just<br>
| > > use the same type in multiple places.<br>
| > ><br>
| > > Iavor<br>
| > The function prototype are already part of the merge request. See here:<br>
| > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl" rel="noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl</a><br>
| > <a href="http://ab.haskell.org" rel="noreferrer" target="_blank">ab.haskell.org</a>%2Fghc%2Fghc%2Fblob%2Fa0781d746c223636a90a0837fe678aab5b<br>
| > 70e4b6%2Fcompiler%2Fstructures%2FCollections.hs&data=02%7C01%7Csim<br>
| > onpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C4fe7780126ff475c3c7308d6e45e8586%7C72f988bf86f1<br>
| > 41af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&sdata=lgu4jc9g3x<br>
| > H%2B9nDorkvPZjts9L1RpVLpexed1uJnyXA%3D&reserved=0<br>
| ><br>
| > As for the data structures in question these are:<br>
| > * EnumSet<br>
| > * Data.IntSet<br>
| > * Data.Set<br>
| > * UniqSet<br>
| > * UniqDSet<br>
| ><br>
| > * Data.IntMap<br>
| > * Data.Map<br>
| > * LabelMap<br>
| > * UniqFM<br>
| > * UniqDFM<br>
| > * UniqMap<br>
| ><br>
| > * Maybe the TrieMap Variants<br>
| ><br>
| > Maybe I missed some but these are all I can think of currently. But<br>
| > they are already plenty.<br>
| ><br>
| > Imo using type classes IS a kind of type hackery required "to make<br>
| > things fit".<br>
| > _______________________________________________<br>
| > ghc-devs mailing list<br>
| > <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| > <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail" rel="noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail</a>.<br>
| > <a href="http://haskell.org" rel="noreferrer" target="_blank">haskell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01<br>
| > %7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C4fe7780126ff475c3c7308d6e45e8586%7C72f988<br>
| > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&sdata=fjw2<br>
| > XfNXANsWXsCb4mfQV0UFvyNNW%2BjqUhhCbOcr%2FhQ%3D&reserved=0<br>
| _______________________________________________<br>
| ghc-devs mailing list<br>
| <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask" rel="noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask</a><br>
| <a href="http://ell.org" rel="noreferrer" target="_blank">ell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-<br>
| devs&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C4fe7780126ff475c3c7308d6<br>
| e45e8586%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&a<br>
| mp;sdata=fjw2XfNXANsWXsCb4mfQV0UFvyNNW%2BjqUhhCbOcr%2FhQ%3D&reserved=0<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>