parameterized working-directory and changing it relatively Shiro Kawai 30 Apr 2020 08:08 UTC
Re: parameterized working-directory and changing it relatively Lassi Kortela 30 Apr 2020 10:16 UTC
Re: parameterized working-directory and changing it relatively John Cowan 30 Apr 2020 15:19 UTC
Re: parameterized working-directory and changing it relatively Marc Nieper-Wißkirchen 30 Apr 2020 15:38 UTC
Re: parameterized working-directory and changing it relatively John Cowan 30 Apr 2020 15:42 UTC
Re: parameterized working-directory and changing it relatively Marc Nieper-Wißkirchen 30 Apr 2020 15:47 UTC
Re: parameterized working-directory and changing it relatively John Cowan 30 Apr 2020 15:49 UTC
Re: parameterized working-directory and changing it relatively Lassi Kortela 30 Apr 2020 16:00 UTC
Re: parameterized working-directory and changing it relatively Faré 30 Apr 2020 16:01 UTC
Re: parameterized working-directory and changing it relatively Lassi Kortela 30 Apr 2020 18:25 UTC
Re: parameterized working-directory and changing it relatively Shiro Kawai 30 Apr 2020 19:27 UTC
Re: parameterized working-directory and changing it relatively Faré 01 May 2020 01:19 UTC
Re: parameterized working-directory and changing it relatively Marc Nieper-Wißkirchen 01 May 2020 07:43 UTC
Re: parameterized working-directory and changing it relatively John Cowan 01 May 2020 13:15 UTC
Re: parameterized working-directory and changing it relatively Faré 03 May 2020 10:23 UTC
Re: parameterized working-directory and changing it relatively Shiro Kawai 30 Apr 2020 17:39 UTC

Re: parameterized working-directory and changing it relatively Faré 03 May 2020 10:23 UTC

On Fri, May 1, 2020 at 9:15 AM John Cowan <xxxxxx@ccil.org> wrote:
> What is a "thin layer" (does it mean C structs are exposed to Scheme as bytevectors?) and what is "the operating system"?  Just syscalls?  Posix has 1192 APIs and no distinctions between part 2 and part 3 of the man pages.   And that doesn't begin to cover the function of the 338 LInux system calls.  Plenty of room for arguments there.  In short, what "makes sense"?
>
There is some wiggle room, but not much.
- Yes, you might want to standardize a couple of layers of
abstractions for your low-level APIs: bytes vs something more
structured at the C level vs something integrated with some heap
abstraction, etc. That's still a handful number of abstraction layers,
compared to 6.022e23 different present and futures Scheme
implementations.
- You don't have to define "the operating system" — you just have to
agree that you'll track the foreign APIs.
- It's totally OK to be lazy about standardizing the wrappers for
those APIs. You can have a 1192-color rainbow of intermediate levels
of "standards" on the way of supporting Posix. Do the work in
whichever order. The important part is: by doing the work this way,
you only have to do it once, instead of umpteen times, with MUCH less
room argument, by fewer people at once.

> In fact, there is only one non-Posix OS still standing, on which much (though not all) of SRFI 170 can be implemented anyway.
Which are you thinking of? Between real-time embedded systems, mobile
systems and server "unikernels", there are plenty of non-POSIX
options. Whether it makes sense to design Scheme for them is another
question.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
When my time on earth is completed, I want to go quietly in my sleep,
like my grandfather ... not screaming in terror, like his passengers.