This is a small library providing a type intended to be used instead of `‘a option array’.
It is written in a style you shouldn’t copy (whoever you are, well maybe except Xavier or Mark). There are far too many Obj for it to be considered sane. I wrote that to be as efficient as it is currently possible in OCaml. I intend to update it to future potential changes.
You could also consider that this is a good example of why you really shouldn’t use Obj.
I will probably publish quite soon some reasonably efficient vector (in the meaning of C++) and queue based on it.
Also, I used that library as an excuse to test jbuilder. Thanks @jeremiedimino, that makes releasing a breeze. And it also works out of the box on windows (according to Appveyor when he doesn’t randomly fail to download some file…)
nullable-array is a bit more complex and expensive to handles correctly combinations of marshaling/unmarshaling and polymorphic comparison (with and without the no-naked-pointers runtime).
I certainly agree that we could push something like that upstream, but it is always simpler to experiment and prove usefulness outside of the compiler before adding something to the stdlib. Pushing upstream would also allow for a slightly faster implementation.
In particular, to avoid problems with the no-naked-pointer runtime, I couldn’t represent None as the 0 pointer which loose 1 field per array. This could be lifted by not following null pointers in the no-naked-pointer variant, but at the cost of adding a test in the GC fast path (but probably well predicted by the CPU).
I’m not that excited about marshal and polymorphic compare, both of which I think of as warts on the language, but I can see why you’d want them for completeness. Certainly, having efficient data structures like Queues built on top of this makes sense, and we use it in various places in Core_kernel for just this reason.
Indeed, we’d like to get some of these faster data structures into Base, but have resisted doing so because of the concern about having too much Obj.magic in Base.
This could be lifted by not following null pointers in the no-naked-pointer variant, but at the cost of adding a test in the GC fast path (but probably well predicted by the CPU).
I was talking about this with Mark the other day. I think we should add this, as well as appropriate behaviours in marshalling and polymorphic compare, and then add an Obj.null value. This would make things like this much easier to implement.
As for Uniform_array, I really think that we should merge the array data types pull request, which would make that trivial to implement, and allow us to get rid of the float array hack.