<div class="gmail_quote">On Wed, Mar 17, 2010 at 4:52 AM, Yitzchak Gale <span dir="ltr"><<a href="mailto:gale@sefer.org">gale@sefer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This I'm not sure about. I've considered using PQ's perhaps<br>
two or three times during the past few years, and ended up not using<br>
them at all.</blockquote><div><br></div><div>I'd prefer for personal anecdote not to be the driver of discussions like this. Personally, I've never used Data.Tree or Data.Graph from the containers package, and doubt that I ever will, but it doesn't break my arm or steal my wristwatch if they're available.</div>
<div><br></div><div>The types in the containers package have subtly different APIs and degrees of control over things like strictness, and also have almost no test coverage along with few signs of usage-driven optimisation. The bar for adding more code to that package is thus pretty low, in my opinion. If I had time, I'd replace it entirely.</div>
<div><br></div><div>My advice would be not to stress over whether priority queues go into containers. It's not some pristine thing of beauty that deserves treatment with velvet gloves. If you want a good source of stress, create a replacement package that makes me happy :-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> True, perhaps I would have used them if there had been a<br>
simple and reliable PQ implementation at my fingertips. But it's<br>
definitely not a ubiquitous meme like Map or Set.<br>
<br>
How about recording this great work as yet one more PQ package<br>
on hackage. But make it far more usable than all of the others<br>
by two simple steps:<br>
<br>
1. In the package description, say simply and clearly what purpose<br>
this package is designed to serve, as you have described in this<br>
thread.<br>
<br>
2. Submit this package for canonicalization as part of the Haskell<br>
Platform. I would for one would support its inclusion.<br>
<div class="im"><br>
> both the C++ STL and java.util.* provide just a vanilla priority queue,<br>
> reflecting those design choices in those languages<br>
<br>
</div>As does Python. In Python, though, the PQ implementation is not<br>
a built-in class in the default namespace (as are dict and set).<br>
Rather, it is one of the "batteries included" libraries that come with<br>
Python. I think that's the right place for it in Haskell, too.<br>
<br>
Please do consider this suggestion. However, if we do not quickly<br>
reach a consensus on this, I will withdraw my suggestion and advocate<br>
inclusion in containers as originally proposed. The difference between<br>
those options is far less important than the risk of losing this great work<br>
to haggling.<br>
<br>
Thanks,<br>
Yitz<br>
<div><div></div><div class="h5">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br>