Container type classes

[Iavor Diatchki]

Hi,

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.  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://gitlab.haskell.org/ghc/ghc/blob/a0781d746c223636a90a0837fe678aab5b70e4b6/compiler/structures/Collections.hs
>
> 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
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs