> Requiring checks for return values is one of the things I most
> dislike about POSIX style APIs.

Definitely. Verbose, and a recipe for bugs.

> We avoid some footguns, one you strongly advocated was having
> directory listing procedures never return "." and "..", even the
> lowest level open-/read-/close-directory wrappers.  John is planning
> to go much further with the processes SRFI which was punted for 170.
>
> And we provide some helper functions on top of the POSIX API, for
> things people are likely to want, like directory-files which returns
> all the files in a directory, and make-directory-files-generator for
> when you don't want them all in a list in one go.

This is all fine with me. I don't care that much which procedures go in
what SRFI, as long as there is not undue duplication of similar APIs.

>> By contrast, OS operations that clearly compose several syscalls are
>> clearly at a higher level of abstraction and could benefit from
>> being in a separate SRFI.
>
> As of now, directory-files and make-directory-files-generator are
> examples that are in the SRFI.  The terminal control procedures like
> with-raw-mode are an example of all of the above, they both provide
> safety as previously mentioned, and also make a number of system calls
> to for example get, set, and reset both an input and an output port.

Also fine.