Re: Separate high-level and low-level APIs Lassi Kortela 23 Apr 2020 16:42 UTC
> 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.