mitchellwrosen/hackage-the-good-parts.md

## hackage-the-good-parts.md

      
    Raw
  

              hackage-the-good-parts.md
            
          
    The Good Parts

ki

Version: 1.0.0.1
unboxed-ref

Version: 0.4.0.0
Unboxed IORef/STRef. If you have an IORef Int, then e.g. IORefU Int will perform many fewer allocations.
The only (somewhat) sketchy part is the library hasn't been touched in 5+ years (as of 2022). But it still builds, and doesn't
have any outdated dependencies, so shrug.
witch

Version: 1.1.5.0
Principled conversion type classes. The API is a little bit messy (why isn't there just one Witch module?) but it seems to be
better than all alternative attempts at this idea that I've come across.

The Okay Parts

aeson

Version: 2.1.1.0
The de-facto JSON toolkit. The API is terrifyingly large and messy, and the documentation is far too verbose. I get lost in
these haddocks every time. A big blah.
containers

Version: 0.6.6
A collection of useful and highly-optimized data structures, primarily Map, Set, and Seq.
The not great parts:


The API is sprawling.
There are many exposed guts, which should be neatly tucked away in a separate containers-internal
Data.IntMap.Internal
Data.IntMap.Internal.Debug
Data.IntMap.Strict.Internal
Data.IntSet.Internal
Data.Map.Internal
Data.Map.Internal.Debug
Data.Map.Strict.Internal
Data.Sequence.Internal
Data.Sequence.Internal.Sorting
Data.Set.Internal
Utils.Containers.Internal.BitQueue
Utils.Containers.Internal.BitUtil
Utils.Containers.Internal.StrictPair

Additionally, the maps' APIs are duplicated due across Lazy and Strict modules; in my experience, Lazy is not very
useful, and could be somewhat easily emulated (though not with exactly the same performance characteristics) in client code
by using a lazy wrapper like data Thunk a = Thunk a.
Data.IntMap.{Lazy,Strict}
Data.IntMap.Merge.{Lazy,Strict}
Data.Map.{Lazy,Strict}
Data.Map.Merge.{Lazy,Strict}


The Data.Graph and Data.Tree modules are not very impressive, and not nearly as useful Map/Set/Sequence. They feel
like they could exist in separate packages.


The Not Great, No Offense Parts

deepseq

Version: 1.4.8.0
I simply never need to deeply evaluate every node in a data structure. It's a big, clunky hammer, and relies on users to write
"correct" or "morally correct" instances anyway.
Whatever use cases of NFData there are (what are they?!) I feel should instead be supported by some compiler primitive.