Hi Adam,

Thanks for this new SRFI.  I haven't had time for an in-depth read
yet, but I wanted to raise a few points which I immediately noticed.

(1) The running-time requirements seem too strict.  O(1) random access
and head/tail insertion may not even make sense in standard Scheme,
given that (as Marc notes) our vectors don't have guaranteed O(1) ref
or set!.  If there is a structure that achieves this behavior in
standard Scheme, I think it would be extremely helpful to include a
brief "implementation" section explaining it.

(2) The destructive procedures could be given linear update semantics
(see SRFI 1), allowing a wider range of implementations.  Most of the
"mutators" already return their flexvector arguments, so it need only
be added that these procedures can be implemented non-destructively.
The iterators (flexvector-map!, etc.) would take slightly more work.

(3) It is very strange to me that flexvectors have both (general)
recursive and "iterative" (primitive recursive) unfolds
(flexvector-unfold and -unfold-right are the former, flexvector-unfold!
and -unfold-right!, the latter).  I agree with the SRFI's rationale
here--we want to be able to unfold a flexvector without knowing its
size in advance, so general recursive unfolds are the Right Thing.
(Here again, as Marc notes, flexvectors behave more like lists than
vectors.)  Given this rationale, it's weird that the unfold!
procedures use a fixed length, even while allowing the destination
structure to be resized.  All flexvector unfolds should express the
same general process, I think; if this isn't possible with the unfold!
procedures, it might be better to remove them.  (I have to say that I
find "destructive unfold" to be a weird idea.)

Regards,

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"I started out as a BASIC programmer.  Some people would say that I'm
permanently damaged.  Some people are undoubtedly right." --Larry Wall