Thinking about what's missing in our library coverage

[Evan Laforge]

>> 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.