<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On Dec 13, 2016 1:26 PM, "Oleg Grenrus" <<a href="mailto:oleg.grenrus@iki.fi">oleg.grenrus@iki.fi</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text"><br></div>I'm not sure we want `transformers`  to depend on `containers` either,<br>
not even mentioning `vector` and `unordered-containers`. Also there are<br>
people stuck with `transformers-0.4` (GHC 7.10).<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Good point, although practically speaking, containers currently *can't* depend on transformers, because transformers is not currently a GHC boot package. There'll probably be room for your compat package for a while, but you'll have to chase those bounds :-/.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
>     Current implementations are naive, but more obviously correct.<br>
><br>
> More than what?<br>
<br>
</div>It seems that implementation for Data.Map is indeed "check size, compare<br>
lists", but e.g for vector it uses streaming framework to make things<br>
fuse, I still use "check size, compare lists" approach.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I believe the only containers structures with non-boring instances of any of those classes are Data.IntMap, Data.IntSet, and Data.Tree.</div><div dir="auto"><br></div><div dir="auto">Side question: why doesn't Read1 have the ReadPrec-based methods that Read does?</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div></div>