Separate high-level and low-level APIs Lassi Kortela 23 Apr 2020 15:38 UTC
> What about thinking of SRFI 170 as the low-level bare-metal interface > mimicking C/POSIX as much as possible? On top of that, a more > Schemely-SRFI could be layered, in which the current working directory > is a parameter object. I agree that the per-thread semantics are more > sound. I would tentatively advise against this since there would seem to be very little difference between those low-level and high-level APIs. The low level is: - Convert Scheme strings and fixnums to C strings and integers - Make the syscall - C strings and integers back to Scheme strings and integers - On error, either return errno as as fixnum or raise exception High level: - Same as low level - Definitely raise exception on errno - Definitely translate per-thread umasks and pathnames - Not that many other differences? So they sound almost the same. The GNOME API stack is a cautionary example of layering too-similar APIs on top of each other. The GDK API is basically XLib with some naming conventions spuriously changed. GObject is a custom object system, etc. It's quite confusing to use and it seems done just for the sake of extremely minor wins in consistency and convenience (everything starts with "G" or something). 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.