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
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.
l...@gnu.org (Ludovic Courtès) writes:
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
Hi!
Mark H Weaver m...@netris.org skribis:
SRFI-6 (string ports) says nothing about port encodings, and yet
portable code written for SRFI-6 will fail on Guile 2.0 unless the
string is constrained to whatever the default port encoding happens to
be. This is not just a theoretical issue; it
l...@gnu.org (Ludovic Courtès) writes:
Hi!
Mark H Weaver m...@netris.org skribis:
SRFI-6 (string ports) says nothing about port encodings, and yet
portable code written for SRFI-6 will fail on Guile 2.0 unless the
string is constrained to whatever the default port encoding happens to
be.
Hi David,
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
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,
Hi,
David Kastrup d...@gnu.org skribis:
Shouldn't strings be in internal encoding anyway? The whole point of
a string is to be an array of characters. Not an array of arbitrarily
encoded bytes.
Yes, but I was referring to “string ports”, which may actually be fed
arbitrary binary data, not
l...@gnu.org (Ludovic Courtès) writes:
Hi,
David Kastrup d...@gnu.org skribis:
Shouldn't strings be in internal encoding anyway? The whole point of
a string is to be an array of characters. Not an array of arbitrarily
encoded bytes.
Yes, but I was referring to “string ports”, which may
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
Shouldn't strings be in internal encoding anyway? The whole point of
a string is to be an array of characters. Not an array of arbitrarily
encoded bytes.
Yes, but I was referring to “string ports”, which may
Hello!
Commit b22e94db7c91d7661204e33f3bc2bfead002c9b7 adds
‘%default-port-conversion-strategy’, a natural friend of
‘%default-port-encoding’.
First, I’m wondering whether ‘port’ should be part of the name, given
that it’s also referred to by ‘scm_stringn’ co. It’s good to have it
in the name,
Second, in commit 9f6e3f5a997f484548bd03e7e7573c38a95c8d09, I changed
string ports to honor it, like other port types, instead of forcing
'error. This seems like the right thing to me, for the sake of
consistency (in fact, I’d consider the previous behavior as a bug), but
it’s an observable
l...@gnu.org (Ludovic Courtès) writes:
Hello!
Commit b22e94db7c91d7661204e33f3bc2bfead002c9b7 adds
‘%default-port-conversion-strategy’, a natural friend of
‘%default-port-encoding’.
First, I’m wondering whether ‘port’ should be part of the name, given
that it’s also referred to by
13 matches
Mail list logo
