Rather than just unboxed we can base our vectors on storable too (assuming unboxed and storable are compatible) this will enable integration with e.g. hmatrix or roll our own c/llvm code. Since we are now running with dense word vectors even for bit vectors we might be able to get good performance. Repa would have been perfect but is now unmaintained, accelerate seems too burdensome having to port to a one off DSL and we have superfast code so we might as well use it. We can perhaps look at mmf again for sharing the vector space and creating the maps on heap.

The only blocker is grenade and the singleton changes that affect that. We could decouple by saving sparse vectors to disk for downstream model training.

So what does that imply for the type definition? I think the pairs are cool. Do we really need a
different constructor for the BVec? Complicates all the definitions but at least we have to think about what the algebra operations mean.

Converting to dense only makes sense for the bit vectors (or for GPGPU computation where dense arithmetic might win).