From: John Cowan <xxxxxx@ccil.org>
Date: Friday, November 01, 2019 6:01 PM

I have a pre-SRFI at <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/FilesAdvancedCowan.md>.   I think the SRFI 170 list is currently the best place to review and discuss this.

1) There are flags applicable to any procedure (R7RS-small or SRFI 170) that returns a port.  These are currently specified as a plist, but would work very well using keyword arguments, which is why SRFI 177 is copied here.  The current set:  

a) append (not in R6RS, but really important IMO)

Agreed, essential for efficient logging of most types (you could in theory rename and copy the old file first, but...).

b) bidirectional (allows both input and output on the same port, but a bidirectional input port is not necessarily the same as a bidirectional output port; different things may happen at open time)

Essential for e.g. databases unless you can direct your ports to not buffer inside the Scheme implementation.  See below.

Although, what about databases where multiple processes access a file?

c) create (Posix: create the file if it doesn't exist)

d) truncate (Posix: truncate the file to zero length if it does exist)

e) exclusive (Posix: fail if the file exists)

None of these strike me as "essential", but all are nice to have.  If on top of a POSIX system, not much extra work if you include append, but what about Windows??

f) buffer (size of buffer if any)

An efficiency thing, modulo the above mentioned option to set it to zero size.

g) char-buffer (size of buffer for conversion between characters and bytes)

h) encoding (name)

i) newline (what the `newline` function outputs)

j) encoding-error (what to do if bytes can't be decoded to characters properly)

Pass, no informed opinion.

k) posix-permissions (when a file is created, what permissions to use; this is _not_ equivalent to creating with one set of permissions and then changing them).

How essential for security??

2) The R6RS port positioning package: determine if a port's position can be accessed or modified, and then accessing or modifying it

Obviously absolutely essential to create files with holes, which is essential for restoring files in POSIX systems.  Which as I previously commented are less rare than one might think.

3) From scsh, select at the level of ports, with timeout.  There are two versions, one that ignores any buffers and one that respects them.

I was going to say, "should this be in the domain of networking?", but reading my Linux's select(2) man page, and then POSIX, https://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html:

The pselect() and select() functions shall support regular files, terminal and pseudo-terminal devices, [OB XSR] [Option Start]  STREAMS-based files, [Option End] FIFOs, pipes, and sockets. The behavior of pselect() and select() on file descriptors that refer to other types of file is unspecified.

Being able to do select on regular files is something I really missed when moving between Win32 and UNIX in the 1990s.  Maybe not *quite* essential, but very very very nice to have.

Still not sure if it conceptually belongs here for the user, but there should be as few SRFIs as possible that demand significant work on a Scheme implementation's ports implementation.

Which of these, if any, are necessary, merely convenient, or downright dispensable?   Please comment.

There are also convenience procedures and macros that don't urgently need discussion.

See above.

- Harold