I'm not willing to do this sort of typeclass wrapper thing, primarily because nothing else in containers does -- even though we might have a Mapping type class that handles both IntMap and Map, we don't.<div><br></div>
<div>I'm inclined to let that design choice stand, as far as containers is concerned. It would make perfect sense to write a new package with such a type class and offering instances for the containers priority queue implementations, but I prefer to stick with the style that containers already seems to use -- that is, exporting separate modules without a unifying type class, but with nearly-identical method signatures.</div>
<div><br clear="all">Louis Wasserman<br><a href="mailto:wasserman.louis@gmail.com">wasserman.louis@gmail.com</a><br><a href="http://profiles.google.com/wasserman.louis">http://profiles.google.com/wasserman.louis</a><br>
<br><br><div class="gmail_quote">On Tue, Mar 16, 2010 at 11:10 AM, Tyson Whitehead <span dir="ltr"><<a href="mailto:twhitehead@gmail.com">twhitehead@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On March 16, 2010 09:29:06 Louis Wasserman wrote:<br>
> I'd like to request some more feedback on the<br>
</div>> proposed<<a href="http://hackage.haskell.org/trac/ghc/ticket/3909" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/3909</a>>implementation<br>
<div class="im">> for priority queues in containers. Mostly, I feel like<br>
> adding a new module to containers should be contentious, and there hasn't<br>
> been as much griping or contention as I expected. The silence is feeling<br>
> kind of eerie!<br>
<br>
</div>Not sure if this is an appropriate question at all as I haven't looked at the<br>
code, but would it be possible to put any primary functionality into a class.<br>
<br>
I'm thinking something along the lines of how the vector code works. This<br>
allows you to use all the higher-order functions (i.e., those implemented<br>
using the primary functions) on a different underlying implementation.<br>
<br>
I've found this particularly useful in wrapping Perl data types. For the Perl<br>
array, all I had to do was write an class instance for the vector module, and<br>
I have all these higher-order functions I could use from existing code.<br>
<br>
It would be very nice to have had something similar to do for the hash tables.<br>
Even to just provide a "native haskell" immutable look into the data so<br>
Haskell code can extract the components it needs with standard functions.<br>
<br>
Cheers! -Tyson<br>
<br>
PS: I'm still working on the wrapping, so I might change my mind as to how<br>
useful this really is, but thought I should throw it out there.<br>
</blockquote></div><br></div>