Re: %default-port-conversion-strategy and string ports

[Daniel Krueger]

Hey,

I don't want to comment on what guile should choose to do in the
future but just wanted to say which interface would be clear to me.

In the first place I agree that ports should be seperated and not
mixed textual/binary (mind, I know it may be that this can't be just
changed that easily in guile). There you either work with characters
and don't mind how they are encoded, or you work on binary data, which
has some encoding, if it is for letters or something else like rgb
data etc.
Then there is are procedures which explicitly convert numbers<->chars
and bytevectors<->strings, which are partly there (number->char and
char->number afaik), but which lack the ability to specify which
encoding they should use (I don't know if they have to use a specific
encoding in rnrs).
And the last is, you have to have open-string-input/output-port, which
opens a textual port and open-bytevector-input/output-port, which
opens a binary port. So if you want to work with the encoded
characters of a string you say `(open-bytevector-input-port
(string->bytevector "my string" (character-encoding UTF-8)))`.

WDYT?

- Daniel

On Sat, Jun 2, 2012 at 4:55 PM, David Kastrup <address@hidden> wrote:
> address@hidden (Ludovic Courtès) writes:
>
>> Mark H Weaver <address@hidden> skribis:
>>
>>> address@hidden (Ludovic Courtès) writes:
>>>> Ports in Guile can be used to write characters, or bytes, or both.  In
>>>> particular, every port (including string ports, void ports, etc.) has an
>>>> “encoding”, which is actually only used for textual I/O.
>>>>
>>>> Conversely, an R6RS port is either textual or binary, but not both.
>>>>
>>>> IMO, one advantage of mixed text/binary ports is to allow things like this:
>>>>
>>>>   scheme@(guile-user)> (define (string->utf16 s)
>>>>                          (let ((p (with-fluids ((%default-port-encoding 
>>>> "UTF-16BE"))
>>>>                                     (open-input-string s))))
>>>>                            (get-bytevector-all p)))
>>>>   scheme@(guile-user)> (string->utf16 "hello")
>>>>   $4 = #vu8(0 104 0 101 0 108 0 108 0 111)
>>>>   scheme@(guile-user)> (use-modules(rnrs bytevectors))
>>>>   scheme@(guile-user)> (utf16->string $4)
>>>>   $5 = "hello"
>>>
>>> IMHO, this is a bad hack that exposes internal details of our
>>> implementation of string ports
>>
>> Which details?
>>
>> It exposes the fact that ports in general are mixed textual/binary, but
>> nothing specific to string ports AFAICS.
>
> If I can't rely on
>
> (string= (with-output-to-string (display x)) x)
>
> then the interface is seriously rotten.  There is lots of code around
> that depends on the ability to bounce material between strings and the
> default output port.
>
>> We’d have to dig r6rs-discuss, but my recollection is that there were
>> arguments both in favor and against separate binary/textual ports.
>
> The question binary/textual concerns ports connected to a file.  String
> ports and Scheme ports should be _transparent_: input and output
> identical.  They are used for connecting character streams within Scheme
> and should not tamper with them.
>
> --
> David Kastrup
>
>