How many people are interested in designing the OS interface? Lassi Kortela 09 May 2019 08:35 UTC Re: How many people are interested in designing the OS interface? Marc Feeley 09 May 2019 12:13 UTC Re: How many people are interested in designing the OS interface? Lassi Kortela 09 May 2019 12:45 UTC Re: How many people are interested in designing the OS interface? Marc Feeley 09 May 2019 12:59 UTC Re: How many people are interested in designing the OS interface? Lassi Kortela 09 May 2019 13:22 UTC Re: How many people are interested in designing the OS interface? Per Bothner 09 May 2019 14:37 UTC Re: How many people are interested in designing the OS interface? Lassi Kortela 09 May 2019 16:58 UTC (missing) Re: How many people are interested in designing the OS interface? Lassi Kortela 10 May 2019 10:26 UTC Re: How many people are interested in designing the OS interface? John Cowan 10 May 2019 01:23 UTC Re: How many people are interested in designing the OS interface? Per Bothner 09 May 2019 15:04 UTC Re: How many people are interested in designing the OS interface? Lassi Kortela 09 May 2019 15:32 UTC Re: How many people are interested in designing the OS interface? Per Bothner 09 May 2019 15:49 UTC Re: How many people are interested in designing the OS interface? John Cowan 10 May 2019 01:46 UTC Re: How many people are interested in designing the OS interface? Lassi Kortela 10 May 2019 10:10 UTC

Re: How many people are interested in designing the OS interface? Marc Feeley 09 May 2019 12:59 UTC

I have limited time to contribute, but if you send me the list of OS features that are in scope I can give you a list of the Gambit procedures that are available for those features.  Beyond that I’ll try to stay tuned to the discussion.

BTW, it is sad that networking is out of scope… again… It is such an essential feature in modern apps, at least basic networking.  I think things get complex (politically) when the details of the socket interface are exposed, but there should be agreement on basic and portable features.

Is filesystem path syntax in scope?  i.e. /foo/bar vs C:\foo\bar

Marc

> On May 9, 2019, at 8:45 AM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> 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.
>