Following up on this just to close out all of the remaining discussions
on this SRFI...

I understand the advantages of linear-update semantics, but I don't
think they're relevant to this SRFI. Flexvector is a datatype that
exists only for its performance characteristics; otherwise, it is the
same as a list. The predictable mutation performance is the point. I
don't believe there is enough to be gained by allowing flexvectors to be
immutable, at the cost of less-reliable performance and mutation
functions that aren't guaranteed to actually mutate.

On 10/8/20 4:29 PM, Wolfgang Corcoran-Mathe wrote:
> On 2020-10-08 22:06 +0200, Marc Nieper-Wißkirchen wrote:
>> Am Do., 8. Okt. 2020 um 21:59 Uhr schrieb Wolfgang Corcoran-Mathe
>> <xxxxxx@sigwinch.xyz>:
>>
>>> On 2020-10-08 21:52 +0200, Marc Nieper-Wißkirchen wrote:
>>>> Am Do., 8. Okt. 2020 um 21:45 Uhr schrieb Wolfgang Corcoran-Mathe
>>>> <xxxxxx@sigwinch.xyz>:
>>>>
>>>>> Yes.  This is one reason why I'm rather sad that vector-set! can't be
>>>>> linear update--there are plenty of immutable implementations of vectors
>>>>> which can guarantee O(log n) access.
>>>> What do you mean by linear-update here?
>>>>
>>>> Do you mean a non-destructive update instead?
>>> Yes, of course.  I meant "linear update" in the sense of SRFI 1's
>>> use of the term:
>>>
>>>> A "linear update" procedure is allowed -- but not required -- to
>>>> side-effect its arguments in order to construct its result.
>> But Scheme's vector-set! is already linear-update in this sense, more
>> precisely, the following procedure is:
>>
>> (define (vector-amend! vec i obj)
>>    (vector-set! vec i obj)
>>    vec)
>>
>> Or do you complain about the existence of vector-set!, which means
>> that Scheme vectors cannot be truly immutable?
> Yes, that's a bit limiting, in my humble opinion.  And I do tend
> to use vector-amend! in my own work, since it allows procedures
> written in functional style to be easily adapted to vectors.
>
> But this is tangential.  I do appreciate the implementation
> freedom that linear update semantics provide.
>