Container type classes

[Carter Schonwald]

http://hackage.haskell.org/package/EdisonCore

the Edison packages come to mind as a previous effort in this space

On Wed, May 29, 2019 at 4:08 PM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> | 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190603/74146712/attachment-0001.html>