Container type classes

[Simon Peyton Jones]

| having a common pattern for naming the operations certainly seems
| nice.   I am ambivalent if we do this with a class, or just name the
| operations the same way, and use the module system. 

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.

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.

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.

Simon


 The type hackery I
| was referring to was the type family for the set elements and map
| keys you were referring to.    It looks like the maps we have are
| uniform enough that one type family per class does the job, so I think the
| class you came with looks nice.
| 
| -Iavor
| PS: the type hacker I was referring to was  having to add more type
| families, for example if we had a map that can only store one type of
| elements, but it looks like this is not the case here.
| 
| 
| On Wed, May 29, 2019 at 3:48 AM Andreas Klebinger
| <klebinger.andreas at gmx.at> wrote:
| >
| > ghc-devs-request at haskell.org schrieb:
| > > Hello,
| > >
| > > I think refactoring to use consistent naming is a good idea, but I
| > > am not sure about the class idea.
| > >
| > > To see if it is viable, we should list the types in question and the
| > > operations we'd like to overload.
| > >
| > > I find that with containers there tend to be two cases: either the
| > > operations are similar but not exactly the same and you have to do
| > > type hackery to make things fit, or you realize that you can just
| > > use the same type in multiple places.
| > >
| > > Iavor
| > The function prototype are already part of the merge request. See here:
| > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
| > ab.haskell.org%2Fghc%2Fghc%2Fblob%2Fa0781d746c223636a90a0837fe678aab5b
| > 70e4b6%2Fcompiler%2Fstructures%2FCollections.hs&data=02%7C01%7Csim
| > onpj%40microsoft.com%7C4fe7780126ff475c3c7308d6e45e8586%7C72f988bf86f1
| > 41af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&sdata=lgu4jc9g3x
| > H%2B9nDorkvPZjts9L1RpVLpexed1uJnyXA%3D&reserved=0
| >
| > As for the data structures in question these are:
| > * EnumSet
| > * Data.IntSet
| > * Data.Set
| > * UniqSet
| > * UniqDSet
| >
| > * Data.IntMap
| > * Data.Map
| > * LabelMap
| > * UniqFM
| > * UniqDFM
| > * UniqMap
| >
| > * Maybe the TrieMap Variants
| >
| > Maybe I missed some but these are all I can think of currently. But
| > they are already plenty.
| >
| > Imo using type classes IS a kind of type hackery required "to make
| > things fit".
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
| > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01
| > %7Csimonpj%40microsoft.com%7C4fe7780126ff475c3c7308d6e45e8586%7C72f988
| > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&sdata=fjw2
| > XfNXANsWXsCb4mfQV0UFvyNNW%2BjqUhhCbOcr%2FhQ%3D&reserved=0
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C4fe7780126ff475c3c7308d6
| e45e8586%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&a
| mp;sdata=fjw2XfNXANsWXsCb4mfQV0UFvyNNW%2BjqUhhCbOcr%2FhQ%3D&reserved=0