<div dir="ltr">make it a tiny little library thats its own! :) <div><br></div><div>yeah, you'd probably want there to be Eq respecting Coercions flavor and the Ord respecting flavor</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 29, 2019 at 1:04 PM Georg Rudoy <<a href="mailto:0xd34df00d@gmail.com">0xd34df00d@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">сб, 29 июн. 2019 г. в 12:57, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>>:<br>
> 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.<br>
<br>
Even if the change would be (disregarding the specific naming) to<br>
change `IntSet` to `IntSetPoly k` and have `type IntSet = IntSetPoly<br>
Int`? I don't have much experience reasoning about this, but looks<br>
like it shouldn't really break much.<br>
<br>
> 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<br>
<br>
More on formalities, should it be a fork or a separate package with<br>
just intmap/intset or something else?<br>
<br>
> 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.<br>
<br>
Great catch! I haven't thought about that.<br>
<br>
-- <br>
  Georg Rudoy<br>
</blockquote></div>