I'll try to set up a benchmarking suite to test more recent versions and other functions in the interface.
Thanks!
A maintainable testsuite (so we can check this again in the future) will be useful!
I've occasionally wished for a speed and memory test suite for maps. There are a lot of implementations for haskell, with different tradeoffs, and it would be nice to quantify someone's assertion that "X is so much better than Y" or test a new implementation. This is one area where haskell is much more complicated than an imperative language like python, where you just use a built-in hashmap and performance is going to be basically good for just about all uses. As an aside, definitely +1 on including dlist. It's very useful for Writer, so much so I have my own type aliases for it. However, the name is anything but intuitive to someone looking for a list with efficient appends. Given all the above, one nice contribution of HP could be to package together data structures with the promise that their use and performance are mostly orthogonal and they represent the current best practices for a given access pattern, and documentation describing the differences. I.e. we have list -> dlist -> finger tree sequence with roughly increasing capabilities but also increasing constant costs (I'm guessing) and the same sort of story with maps and arrays. Is documentation part of the goal for HP? Is there a place to put it? It would be nice if it could be integrated into the haddock in a discoverable way, i.e. attached to Data or something, or linked off the main TOC. And it would be nice in general if package haddocks could be linked (or maybe they already can?). I'd be willing to make a start on some documentation and some benchmarks for various access patterns with nice graphs and stuff, if there's interest.