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 g
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver 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 onl
Hi Mark,
Mark H Weaver 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.
>>
>> Convers
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 bin
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 advantag
l...@gnu.org (Ludovic Courtès) writes:
> Hi!
>
> Mark H Weaver 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. Thi
Hi!
Mark H Weaver 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 has caused t
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup 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 actuall
l...@gnu.org (Ludovic Courtès) writes:
> Hi,
>
> David Kastrup 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 ma
Hi,
David Kastrup 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 just ch
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
>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 c
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,
13 matches
Mail list logo
