Feedback request: priority queues in containers
fox at ucw.cz
Tue Mar 16 12:22:59 EDT 2010
I second that choice. There have been some attempts at using type
classes, notably the Edison library, but it never got widespread.
So I would follow the current containers design.
> 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
> 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.
> Libraries mailing list
> Libraries at haskell.org
More information about the Glasgow-haskell-users