Making Int{Map,Set} polymorphic over the key type

[Carter Schonwald]

Off hand that seems like it’d break every single piece of code that uses
those data structures today or at the very least possibly weaken type
inference in some cases.

Or maybe I’m over thinking things.

I do think it’d be super to experiment with that as a child package so we
can all try it out and see how the ux compares vs the usual approaches
people do today


One possible gotcha / law that would need to be true for such new types is
that the Ord and Eq instanced would have to be the same as INT.  AT least
for some parts of the container api.

On Sat, Jun 29, 2019 at 12:46 PM Georg Rudoy <0xd34df00d at gmail.com> wrote:

> Hi folks,
>
> What do you think about making IntMap and IntSet polymorphic over the keys
> as long as the key type k is Coercible to Int?
>
> The motivation is that oftentimes one needs to have a collection of
> newtype wrappers around Int, and then they have to either unpack/repack it
> around the relevant containers (which is not nice), or just use
> HashMap/HashSet (which is perhaps suboptimal).
>
> If this is a direction the community might deem reasonable, I'd be happy
> to work on this and make a PR to the containers repo (perhaps after
> discussing the specific details about naming, etc).
>
>
> --
>   Georg Rudoy
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190629/19ba9ebd/attachment.html>