1. 10
  1.  

  2. 3

    I went for the (Vector ...) approach in Waargonaut. Then provided the tools to give the library consumer all the choices when it comes to deciding which structure to finally end up with. Worked out well, I think, given all the contortions I went through to allow for preserving total information when decoding and handling those weird arse JSON “strings”… ><”

    1. 2

      Waargonaut looks so good! Can’t wait for the Stackage release, we’d like to use it at Flipstone :)

      1. 3

        There’s a PR that loosens a few of the bounds and increases the number of GHCs that it will build with… Not sure if that’s enough to push it over the line? There are a few packages it depends on that can be difficult to build so Stackage might be choking on them, not sure.

    2. 1

      So, why not a TrieMap where the keys are Text? It seems to me that that might be better performance than a generic balanced binary tree, worse than a hashmap, but not have the same collision problems. This could be one implementation for the opaque TextMap type.

      1. 1

        Do you know of a mature trie-map implementation for Haskell? Also, have you seen the following blog post linked in the right sidebar? He did run some benchmarks but not with a trie-map.

        1. 1

          https://hackage.haskell.org/package/TrieMap

          That package looks like a promising starting point. Though, this package looks very generic. I’d think that something that’s specific to Text would be best.