vector-for-each is a R7RS standard function, and SRFI-43 was replaced with SRFI-133 due to the standard breaking compliance with SRFI-43
Right, you're using R7RS. I'm still living in the R5RS world. Thanks for the correction.
Some preliminary observations:
- The focus system seems designed to accelerate near-sequential lookups or iteration. Is this your trick? How was it chosen over, say, a doubly linked list running through the leaf vectors?
- The rationale behind the new-start computation of the let* of focus-set! is not immediately obvious to me. Could you explain a bit? Why is the multiplication factor 32 rather than node-size?
- I think a note would be appropriate somewhere around focus-set! that you are choosing to compute focus-start and focus-end as the maximum possible range of positions that the focus could cover, but those positions are not all guaranteed to actually exist in the current radix.
- Naive-append-vector! looks much more manageable now. I do have to wonder though about the make-radix call in the proc call of the else branch, when the let* has new-radix.
- As explained in >>20 about radix-copy-path, radix-ref-height must also not be called with a position that is not 32-aligned at the end of the radix. Radix->list-iter does not respect this, and in >>19 this was almost harmless because the radix was stateless and the vector-copy handled the empty slice. But now the radix is stateful so the modulo piece should become the empty list immediately when the modulo is 0, without a call to (radix-ref-height radix-struct length 1).
- The final-vector-remainder of radix-append regressed from >>21.