bug#18520: string ports should not have an encoding

[Ludovic Courtès]

I see my reply failed to address some of the points raised.

David Kastrup <address@hidden> skribis:

> Guile-2.2 does not consult %default-port-encoding but uses UTF-8
> consistently (I guess, overriding set-port-encoding! will again change
> that).
>
> That still is not satisfactory.  For example, using ftell on the input
> port will not report the string index of the string connected to the
> string port but rather a byte index into a UTF-8 encoded version of the
> string.  This is a number that has nothing to do with the original
> string and cannot be used for correlating string and port.

Right.

> Ports fundamentally deliver characters, and so reading and writing from
> a string source/sink should not involve _any_ coding system.
>
> Files fundamentally deliver bytes, a conversion is required.  The same
> would be the case when opening a port on a _bytevector_.  Here an
> encoding would make equally make sense, and ftell/fseek offsets would
> naturally be in bytes.  But a port on a string delivers and consumes
> characters.  Any conversion, even a fixed UTF-8 conversion, will destroy
> the predictable nature of with-output-to-string and
> with-input-from-string and the respective uses of string ports.

Guile ports can be mixed textual/binary (unlike R6 ports, which are
either textual or binary.)  Thus, they fundamentally deliver bytes,
possibly with a textual conversion.

Although the manual isn’t clear about it, ‘ftell’, when available,
returns a position in bytes.  The situation for string ports here is
comparable to that of other ports used for textual I/O.

Do you have a situation where you were relying on 1.8’s behavior in that
regard?  Could we see whether this can be solved differently?

Thanks,
Ludo’.