Hmm. How would parts of strings get interleaved -- are there
multi-threaded Scheme implementations that don't protect their port
objects with mutexes?
This comes up when multiple processes (as opposed to threads) write to a file.
Standard error (stderr) is traditionally unbuffered to ensure error
messages get written out if the program crashes unexpectedly, so an
unbuffered output mode is definitely useful. But it probably should not
be the default.
Agreed.
Port position on a textual port is notoriously hazardous. It's not clear
whether it should be the byte position or the character position. And
how do you implement an efficient and reliable set-port-position! using
character positions? What if it uses byte positions and the user jumps
into the middle of a multi-byte character?
Port position on a textual port, per R6RS, is an opaque implementation-dependent object that port-position generates and set-port-position! accepts. It can contain not only a byte position but other state.
How about this requirement for implementations:
- In a multi-threaded Scheme, the port object returned by file-open or
fdes->*port must be thread-safe so only one thread can read or write at
a time.
File-open returns a fd, so no issue there. Restrictions on ports created by fdes->*port should be implementation-specific, I think.
- For an output-capable port, any call to read or (set)-port-position
first causes the output buffer to be flushed. This implies that read and
(set-)port-position can raise any error that flush-output-port can raise.
Since these are port (not fd) operations, I think they belong in a different SRFI. When I get a chance I will scale down FilesAdvancedCowan appropriately.
If this goes into SRFI 170, character encoding and newline
considerations would complicate the SRFI a lot.
Yes.
If we had keyword arguments, 170 could allow implementations to add
arbitrary keyword arguments to the open-file and fdes->textual-port
procedures...
How about just taking an implementation-dependent config object? Eventually this object could be standardized by a later SRFI. A one-line note like "This object may specify any or all of the following: character conversion buffering, character encoding name, newline representation on output, encoding error handling, and other implementation-specific features" would probably suffice.