<br><br><div class="gmail_quote">On Fri, May 23, 2008 at 8:54 AM, Ross Paterson &lt;<a href="mailto:ross@soi.city.ac.uk">ross@soi.city.ac.uk</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><br></div><br>
But the library submissions process was only intended for interface<br>
changes, and Scott&#39;s changes to IntMap/IntSet construction and findMax<br>
are performance issues.</blockquote><div><br>Not entirely. I changed the signatures of IntMap.findMin and findMax to return the key/value pair. Previously they only returned the value. I believe this was a typo -- findMin was defined as &quot;fst . runIdentity . minView&quot; but it &quot;should&quot; have been &quot;fst . runIdentity . minViewWithKey&quot;. I say &quot;should&quot; because Map.findMin also returns the pair, and the documentation for the functions made it seem like that&#39;s what they should return. But I don&#39;t think its a major compatibility issue because these functions are still not published in the Haddock indices (<a href="http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-IntMap.html">http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-IntMap.html</a> &lt;-- no findMin there) so whoever is using them is doing so at the risk of code breakage. <br>
<br>But if this still counts as API change I&#39;d be glad to make another that keeps signatures unchanged. However I do think it is ridiculous for findMin to return only the value and not the key as well. <br></div></div>
<br>Scott<br>