We've already discussed open/append. In the scenario where it makes the most sense to use, where multiple threads and/or processes might be writing to the file, it ensures that any call to write(2) is atomically added to the current end of the file, very handy for logging. This means any port using a file descriptor opened with it must not have output buffering, so that a single port output procedure call results in only one call to write(2), otherwise parts of strings could get interleaved with others. Skimming the relevant Chibi Scheme code, it looks like doing this will be trivial, as would changing the size of the output buffer from its default.
I don't think that should be enforced: I often open files for append even when I expect to be the only writer, in which case not buffering is very inefficient.
open/read and open/write by themselves, without using any of the above flags, don't make sense
Agreed; it's a degenerate case.
compared to using the normal Scheme port procedures, unless you add set-port-position! AKA POSIX lseek to this or another SRFI.
However, if the textual conversion is specified in fdes->textual-port, then you do need plain open.
(At the same time, you'd naturally also add port-position to find out the current position (just another call to lseek with special arguments), and perhaps can-set-port-position?.)
I certainly do expect to have the R6RS port-position functions, but I don't think they belong in SRFI 170.
That could be ignored, but not open/read+write, which doesn't make any sense without set-port-position! FilesAdvanceCowan specifies that switching between reading and writing first requires calling set-port-position!, which I assume is to invoke its buffer manipulating functionality.
That requirement comes from R6RS, which comes from stdio. See fseek().
Of course open/read+write opens an even bigger cans of worms, because you'll have to implement bi-directional ports. FilesAdvancedCowan lays out the minimum required behavior from the API, but obviously a noticeable amount of new work will be required to support them when starting from a Scheme implementation that sticks to the standards and only does unidirectional ports.
Yes, I'm good with making that behavior optional or leaving it out altogether.
And then there's complexities with textual ports, which I will leave for the future depending on how much of the above extra functionality we decide is proper to demand from implementors of SRFI-170. Which is my closing question, where should we draw the line?
I think we need to be able to convert a fd to a textual input or output port, as we have now. The question is whether we need to have the detailed control, or just leave it to the Scheme implementation (which would presumably choose it based on things like $LANG and the OS name).