make it a tiny little library thats its own! :) yeah, you'd probably want there to be Eq respecting Coercions flavor and the Ord respecting flavor On Sat, Jun 29, 2019 at 1:04 PM Georg Rudoy <0xd34df00d@gmail.com> wrote:

...

: Off hand that seems like it’d break every single piece of code that uses

сб, 29 июн. 2019 г. в 12:57, Carter Schonwald

Even if the change would be (disregarding the specific naming) to change `IntSet` to `IntSetPoly k` and have `type IntSet = IntSetPoly Int`? I don't have much experience reasoning about this, but looks like it shouldn't really break much.

...

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

More on formalities, should it be a fork or a separate package with just intmap/intset or something else?

...

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.

Great catch! I haven't thought about that.

-- Georg Rudoy

сб, 29 июн. 2019 г. в 13:01, Henning Thielemann :

There is already the enummapset package.

Isn't it using fromEnum/toEnum under the hood, which might have bigger performance penalty than `coerce`? On the other hand, sure, the original suggestion can also be made as a separate library wrapping IntMap/IntSet and all the calls to coerce. I'm happy with that approach too. -- Georg Rudoy

toEnum and fromEnum will be coercions for the types you're talking about anyway. On Sat, Jun 29, 2019, 1:06 PM Georg Rudoy <0xd34df00d@gmail.com> wrote:

сб, 29 июн. 2019 г. в 13:01, Henning Thielemann < lemming@henning-thielemann.de>:

...

There is already the enummapset package.

Isn't it using fromEnum/toEnum under the hood, which might have bigger performance penalty than `coerce`?

On the other hand, sure, the original suggestion can also be made as a separate library wrapping IntMap/IntSet and all the calls to coerce. I'm happy with that approach too.

-- Georg Rudoy _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries