[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %default-port-conversion-strategy and string ports
From: |
Mark H Weaver |
Subject: |
Re: %default-port-conversion-strategy and string ports |
Date: |
Fri, 01 Jun 2012 18:40:12 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
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, and whose only utility AFAIK is to
(partially) make up for our lack of a proper 'iconv' interface from
Scheme. If we could enable this hack without compromising the
robustness of the _primary_ use case for string ports, then I would
merely frown at this leak of internal implementation details.
Unfortunately, it's worse than that.
Anyway, I suppose that we are now locked into this broken behavior, at
least for Guile 2.0. 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.
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).
Mark
- 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 <=
- Re: %default-port-conversion-strategy and string ports, Ludovic Courtès, 2012/06/02
- 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