[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %default-port-conversion-strategy and string ports
From: |
Ludovic Courtès |
Subject: |
Re: %default-port-conversion-strategy and string ports |
Date: |
Sat, 02 Jun 2012 14:52:04 +0200 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux) |
Hi Mark,
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.
> and whose only utility AFAIK is to (partially) make up for our lack
> of a proper 'iconv' interface from Scheme.
Well, ‘string->pointer’ and ‘scm_to_stringn’ can be thought of as an
iconv interface, no?
I understand you’re in favor of separate textual/binary ports. It
may have its advantages; yet, it’s not clear to me that mixed
binary/textual ports are a kludge either.
We’d have to dig r6rs-discuss, but my recollection is that there were
arguments both in favor and against separate binary/textual ports.
Last but not least, mixed ports were decided a couple of years ago as a
reasonable option to allow a smooth transition from 1.8 where the API
was already mixed (think ‘write’, vs. ‘uniform-vector-write’,
vs. ‘scm_c_write’, etc.) It may not be ideal, but I’m convinced it’s a
good compromise. It’s not all black and white.
[...]
> I guess that your proposed solution (to make
> SRFI-6 export alternative versions of 'open-input-string' and
> 'open-output-string' that always use UTF-8 for the port encoding) is the
> best we can do now.
OK, I’ll do that.
> I have concerns about this solution, but I can't think of a better one,
> given the unfortunate fact that our current semantics have been widely
> deployed (and worse, that the above hack has been advertised on
> guile-user as a way to work around our lack of 'iconv' from Scheme).
Again, I’ve advertised it because I find it useful, and because I don’t
consider it such an ugly kludge.
Thanks,
Ludo’.
- Re: %default-port-conversion-strategy and string ports, Ludovic Courtès, 2012/06/01
- Re: %default-port-conversion-strategy and string ports, David Kastrup, 2012/06/01
- Re: %default-port-conversion-strategy and string ports, Ludovic Courtès, 2012/06/01
- Re: %default-port-conversion-strategy and string ports, Mark H Weaver, 2012/06/01
- Re: %default-port-conversion-strategy and string ports,
Ludovic Courtès <=
- Re: %default-port-conversion-strategy and string ports, David Kastrup, 2012/06/02
- Re: %default-port-conversion-strategy and string ports, Daniel Krueger, 2012/06/03
- Separate textual/binary ports vs. mixed ports, Ludovic Courtès, 2012/06/03
- Re: Separate textual/binary ports vs. mixed ports, Daniel Krueger, 2012/06/05
- Re: Separate textual/binary ports vs. mixed ports, Noah Lavine, 2012/06/05
- Re: Separate textual/binary ports vs. mixed ports, Ludovic Courtès, 2012/06/05
- Re: Separate textual/binary ports vs. mixed ports, Ludovic Courtès, 2012/06/05