<br><br><div class="gmail_quote">On Fri, May 23, 2008 at 8:54 AM, Ross Paterson <<a href="mailto:ross@soi.city.ac.uk">ross@soi.city.ac.uk</a>> 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'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 "fst . runIdentity . minView" but it "should" have been "fst . runIdentity . minViewWithKey". I say "should" because Map.findMin also returns the pair, and the documentation for the functions made it seem like that's what they should return. But I don'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> <-- 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'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>