Lassi, you might want to look at what is available currently in Scheme implementations before reinventing the wheel.  Many Schemes have OS interfaces.  A set of design objectives might be good too before you commit to implementation, and your general principles are a good start.

You should look at Gambit’s OS interface which has similar design principles, in particular being portable to unix/linux/macOS and Windows.  Things like filesystem procedures, process ports, shell commands, TCP/UDP I/O, etc. work on all platforms.

Marc

> On May 9, 2019, at 4:35 AM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> Thanks to John for editing our sprawling conversation :)
>
> Before starting detailed technical discussions, could we get a head count on how many people are here, and whether they are interested in shaping the overall design or having particular interests taken into account? This would give us a better idea what kinds of goals to pursue within the 60-90 day SRFI time frame.
>
> I have lots of general and specific suggestions, but I will curtail them if they turn out not to be a good fit for the group's goals. My approach would be based on three general principles:
>
> 1) Wide cross-OS portability, not limited to Unix/Posix. This means we should choose more general abstractions where possible. Unix-only stuff should be clearly labeled as such.
>
> 2) Successful portability is achieved by having tested support for a large set of particular operating systems. An OS interface is all about environmental dependencies and those are devilishly difficult to standardize for a variety of subtle reasons. The only way to prove we have a good design is to compile and run actual code on as many OSes as we can find. Taking a shortcut by relying only on standards usually does not work well. I have a long-standing interest in this kind of work and willing to go out of my way to ensure we get a good outcome.
>
> 3) Details matter. We should try to be as comprehensive as possible in covering the interfaces that we do cover. We should not support broken-as-designed facilities (like some file-locking, terminal and date/time stuff) or things that are so complex/unstable they are likely to break, but with everything that we include we should aspire to do a thorough job. When in doubt, I would rather leave out a particular interface than specify something incomplete that may be problematic to extend later. If we leave things out now we can always follow up with another SRFI when we are wiser.
>
> Eager to hear all comments.
>