Re: How many people are interested in designing the OS interface? Lassi Kortela 09 May 2019 12:45 UTC

Thank you for chiming in.

> 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.

Duly noted. I have cursorily used several of them. John wrote the first
draft of the SRFI based on Scsh and the specific comments so far are
based largely on that. Gambit's interface seems nice and featureful.

In fact, now that we are working on this, let's do a comprehensive
survey of the OS interfaces all of the ten or so most popular/active
Scheme implementations. This is not an inordinate amount of work -- a
Unix interface is not _that_ big, and there is naturally a lot of
overlap. It is both respectful to implementors and technically sound to
make sure we are not missing any corner cases that are already taken
into account by an implementation.

Outside Scheme and based on my personal experiences the interfaces in Go
and Python are particularly good (not necessarily in naming the
functions and structures, but in how faithfully they match the OS while
still providing a little abstraction so it doesn't feel like using C).

> 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.

This is very good to hear! We'll thoroughly consider everything in it.
Do you have the time/interest to join us in working out the details?

John's working from the assumption that networking is out of scope for
this SRFI. I think this is wise as it's a very complex topic and SRFI
106 (Basic socket interface) already covers some of that ground. The
other things you listed would all be in scope.

The interface should also translate well to JVM and CLR so it would be
good to look at Kawa and IronScheme too. Luckily JVM and CLR both allow
calls to native code in case there's something really tricky.