Hi Mark, Mark H Weaver <m...@netris.org> skribis:
> l...@gnu.org (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’.