-specific extension that Guile provides. What
I'm after is making `textual-port?' and `binary-port?' establish a
partition on the set of possible ports; i.e.
(textual-port? X) = (not (binary-port? X))
for any port X (or at least for any port obtainable via R6RS-specified
procedures
On Mon 25 Apr 2011 16:08, l...@gnu.org (Ludovic Courtès) writes:
I wouldn’t want the “native” port type to be disjoint from the R6RS port
types, notably because there’s no “native” equivalent to the R6RS binary
I/O API, and also because it would hamper composition of R6RS and
non-R6RS code.
and textual I/O on any port, is, IMHO, a fine and
reasonable implementation-specific extension that Guile provides. What
I'm after is making `textual-port?' and `binary-port?' establish a
partition on the set of possible ports; i.e.
(textual-port? X) = (not (binary-port? X))
for any port X
? procedure returns #t if the
port supports the port-position operation, and #f
otherwise.
For a binary port, the port-position procedure returns
the index of the position at which the next byte would
be read from or written to the port as an exact
non
(guile) Random Access). It seems to be a valid implementation of R6
port positions, no?
[...]
IMHO this R6 statement:
(textual-port? port) procedure
(binary-port? port) procedure
The textual-port? procedure returns #t if port is
textual, and returns #f otherwise
Hi Andreas!
Andreas Rottmann a.rottm...@gmx.at writes:
l...@gnu.org (Ludovic Courtès) writes:
[...]
However, I’m wondering whether we should not just squarely do away with
the binary/textual distinction, and just write:
(define (binary-port? p) #t)
What do people with experience
Hello,
I just pushed 96128014bfaabe9e123c4f4928ce4c20427eaa53, which makes
‘binary-port?’ deterministic for ports intended to be binary.
However, I’m wondering whether we should not just squarely do away with
the binary/textual distinction, and just write:
(define (binary-port? p) #t)
What
