Use a nullable array implementation internally#2
Use a nullable array implementation internally#2craigfe wants to merge 3 commits intobacktracking:mainfrom
Conversation
| let n = Narray.length a.data in | ||
| (* grow *) | ||
| if s > n then begin (* reallocate into a larger array *) | ||
| if s > Sys.max_array_length then invalid_arg "Vector.resize: cannot grow"; | ||
| let n' = min (max (2 * n) s) Sys.max_array_length in | ||
| let a' = Array.make n' a.dummy in | ||
| Array.blit a.data 0 a' 0 a.size; | ||
| if s > Narray.max_length then invalid_arg "Vector.resize: cannot grow"; | ||
| let n' = min (max (2 * n) s) Narray.max_length in | ||
| let a' = Narray.make_some n' v in | ||
| Narray.blit a.data 0 a' 0 a.size; | ||
| a.data <- a' | ||
| end | ||
| end; | ||
| a.size <- s | ||
| end; | ||
| a.size <- s | ||
| end |
There was a problem hiding this comment.
Differs from unsafe_expand above only in the use of make_some n' v rather than make n'. Not sure if there's an elegant factorisation that doesn't also allocate an option. Opinions much appreciated.
| Raise [Invalid_argument] if [n < 0] or [n > Sys.max_array_length]. | ||
| If the value of [dummy] is a floating-point number, then the maximum | ||
| size is only [Sys.max_array_length / 2].*) | ||
| Raise [Invalid_argument] if [n < 0] or [n >= Sys.max_array_length]. *) |
There was a problem hiding this comment.
We could also provide Vector.max_length to correspond with Nullable_array.max_length.
| val shrink: 'a t -> int -> unit | ||
| (** [Vector.shrink a n] sets the length of vector [a] to be at most [n]. | ||
|
|
||
| If [n >= Vector.length a], this operation has no effect. |
There was a problem hiding this comment.
I'm unsure if this is the ideal semantics for shrink (or if the name is confusing given those semantics). Perhaps the user will expect "shrink a n ensures length a = n", in which case perhaps we should raise when n > length a.
There was a problem hiding this comment.
Yes, I have mixed feelings about this one.
- If
shrinkis exposed in the API, I would prefer it to fail whenn > Vector.length a - A simpler solution is not to expose it, since users can always use
resizeto implement their ownshrinkon top of it.
... by using a third-party nullable array implementation internally. Full list of changes: - remove all `~dummy` arguments; - change `resize` to require an initialisation element for the new suffix that it may create; - add `shrink`, a variant of `resize` that can only reduce the size of the vector and so doesn't need an initialisation element; - add a dependency on the `nullable-array` library.
|
Looks fine to me. Many thanks for this PR! |
This PR contains the patch described in #1. It's not mergeable yet as it relies on extensions to
nullable-array(PRed here), but I thought I'd create the PR now in case there are any initial comments (which will perhaps create new requirements for my other patch).The changes are as follows:
~dummyarguments;resizeto require an initialisation element for the new suffix that it may create;shrink, a variant ofresizethat can only reduce the size of the vector and so doesn't need an initialisation element;nullable-arraylibrary.I haven't added any new test cases, but I'm very happy to do so. The existing ones are passing in the CI system on my own fork (here), which has decent platform coverage.