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@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.andr...@gmx.at> wrote: > | > > | > ghc-devs-requ...@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@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@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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
