Feedback request: priority queues in containers

[Louis Wasserman]

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.

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.

Louis Wasserman
wasserman.louis at gmail.com
http://profiles.google.com/wasserman.louis


On Tue, Mar 16, 2010 at 11:10 AM, Tyson Whitehead <twhitehead at gmail.com>wrote:

> On March 16, 2010 09:29:06 Louis Wasserman wrote:
> > I'd like to request some more feedback on the
> > proposed<http://hackage.haskell.org/trac/ghc/ticket/3909>implementation
> > for priority queues in containers.  Mostly, I feel like
> > adding a new module to containers should be contentious, and there hasn't
> > been as much griping or contention as I expected.  The silence is feeling
> > kind of eerie!
>
> Not sure if this is an appropriate question at all as I haven't looked at
> the
> code, but would it be possible to put any primary functionality into a
> class.
>
> I'm thinking something along the lines of how the vector code works.  This
> allows you to use all the higher-order functions (i.e., those implemented
> using the primary functions) on a different underlying implementation.
>
> I've found this particularly useful in wrapping Perl data types.  For the
> Perl
> array, all I had to do was write an class instance for the vector module,
> and
> I have all these higher-order functions I could use from existing code.
>
> It would be very nice to have had something similar to do for the hash
> tables.
> Even to just provide a "native haskell" immutable look into the data so
> Haskell code can extract the components it needs with standard functions.
>
> Cheers!  -Tyson
>
> PS:  I'm still working on the wrapping, so I might change my mind as to how
> useful this really is, but thought I should throw it out there.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100316/a8d8b528/attachment.html