I see, if the goal of this srfi is for r6rs compatibility library, we certainly can't introduce incompatible changes.

The srfi-way is probably to submit an alternative srfi and let the users choose.

I do, however, want to promote the idea that string-as-buffer should fade out.  Would it be acceptable to suggest a backward-compatible enhancement, which allows to avoid string-as-buffer?  (I have vague ideas but I need to implement it to see how it goes).   Or do you want to stick to r6rs and nothing more?

--shiro

On Thu, Mar 5, 2020 at 6:46 AM John Cowan <xxxxxx@ccil.org> wrote:

 I agree in principle, but my response is the same as before: I don't want to have to implement this SRFI from scratch, and this change would break backward compatibility with R6RS.  (We added string->vector and vector->string to R7RS-small to encourage the use of a mutable vector to build up strings.)

On Thu, Mar 5, 2020 at 4:19 AM Shiro Kawai <xxxxxx@gmail.com> wrote:

Regarding make-custom-textual-input-port:  It uses a string as a buffer, which doesn't play well with the implementations that uses quasi-immutable strings; by which I mean, a string is a pointer to an immutable string body or a structure consists of immutable chunks, and mutating a part of it involves more than just filling an array of characters.

I forgot how I argued during r6rs process (I'm too lazy to dig mail archive) but I should've opposed to it unless I overlooked it.

The string passed to read! is actually just an intermediate buffer from which port's reader reads one character at a time.  A vector of characters is sufficient for that purpose, plus it is guaranteed to be O(1) reference and mutation, while strings are not.

Using a string as a mutable buffer is a terrible custom that should go away.

So I propose to make it a vector of characters.