{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihg3oh5mrhaki5w6uzlbwspv2wvbxm3ldce5lpxv645xs34aeqbta",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mknoidzkhlo2"
  },
  "path": "/t/botan-bindings-devlog/6855?page=11#post_210",
  "publishedAt": "2026-04-29T16:27:44.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "Whew! I needed a few days respite after last week’s writing and editing, to keep my health up.\n\narybczak:\n\n> Thanks for continual improvement of Haskell cryptography story\n\nVlix:\n\n> Also, thanks for still going at it and writing these lovely reports. It’s always a pleasure to read.\n\narybczak:\n\n> I suggest unconditionally including boot dependencies of GHC (i.e. ones that always get installed alongside it) to not make the work harder than it needs to be for yourself\n\nI guess this is less important for botan than it is for memalloc. My rationale here is mostly consistency - it makes sense for `memalloc` because ideally _it shouldn’t depend on eg ghc or bytestring_ , but rather they should depend on it - perhaps one day\n\nThe dependency control flags are all true by default and require turning off manually, so they aren’t unsafe, plus:\n\n  * It helps me to organize the code\n  * I can turn things on and off during feature development\n  * It helps locate / localize problems\n  * Better support for non-GHC compilers\n\n\n\nBut botan does not follow this, it is a genuine downstream dependent, so I suppose it does not have the same needs. Right now I’m just seeing how they feel, but I shall ponder this. The flags do provide value in a holistic context, eg considering it as part of a set of interacting libraries, and they make it easy to control the set consistently.\n\nVlix:\n\n> I would also love to see the `memalloc` library.\n>  Does it have an extensive test suite? It feels like such a fundamental library that it should _really_ be as robust as can be.\n\nYou’ve sort of hit it dead on - it needs more tests before I’m comfortable declaring ‘release’ or putting it up on ‘hackage’, but I’ll be getting the `memalloc` repo and the `botan-low-refactor` branch up soon so everyone can clone, use a `cabal.project.local` for the local repo, and build it themselves.\n\nVlix:\n\n> And another question: do you think a higher level `botan` package would even be needed if `botan-low` will get higher level concept types and convenience functions?\n\nActually, yes! I was wondering myself if I would need to rename `botan-low` to `botan` if I’m consolidating / moving all the high-level stuff down to it, but it turns out that it still makes sense to have a high-level `botan`, because it is an optimal place for per-algorithm data types and cryptographic typeclasses.\n\nThis lets `botan-low` continue to get away with using a simple single eg `HashType` data type of which eg `SHA3` is a constructor, while `botan` will have a `Hash(Algorithm)` class, of which eg, `SHA3` is a data type that is an instance of `Hash(Algorithm)`.\n\nThe cryptographic typeclasses themselves will probably be in a separate `cryptographic` library explicitly for cryptographic abstractions, of which `botan` will implement instances - similar to how I pulled out the memory abstractions in `memalloc`",
  "title": "Botan bindings devlog"
}