> The working set can also refer to the set of pages that need to be
> kept in main memory, or in the bad old days you'd thrash your hard
> disk(s), for UNIX your swap partition(s).  Back when memory was dear,
> drawing horizontal lines at the bottom of your screen to signal if
> your process was running, paging, or for Lisp Machines, GCing was
> comforting and/or annoying feedback.

Huh, that must have been fun! Of course, in 2020 we still don't have
enough free RAM since extra browser tabs tend to gobble it up :)

> I agree with dropping "working" from the SFRI.

Thanks!

> Still, I continue to quibble about removing the "set-" uniformity of
> the API.  Am I correct in understanding the motivation to do this is a
> Scheme implementation performance hack of using parameter objects...??

Yes, it's due to the parameter objects. But they are not so much a
performance hack as a way to clarify semantics in multi-threaded
programs. If the current directory is process-wide, any thread can in
principle change it from underneath the other threads at any time,
invalidating their assumptions about what the cwd is.

By contrast, a particular thread can bind the parameter so that the
binding is only visible in that thread. Other threads can (and should)
have their own independent bindings. If you're familiar with Common
Lisp, it's like using dynamic variables (aka special variables), i.e.
the *variables-with-the-stars-around-their-name* over there.

> Another option is removing "set-" as much as possible from the API,
> but there's no obvious way to do that for set-file-mode/-owner/-group,
> because you *get* those values using a single call to file-info, which
> calls POSIX stat and returns a record mirroring stat's struct.

Good point. Hmm, it's a difficult choice. At least since those modes
have to do with files instead of the running process, parameter objects
would make no sense. So there are no parameters with which to be
symmetrical (unless we count the parameters for the process state... "a
foolish consistency is the hobgoblin", etc.)

>> the process umask is the law and the per-thread umask is just something extra
>
> Not the law if the thread changes the per process umask, rather, a
> hierarchy.

Well put.

> We could "make it the law" as I previously proposed by not
> letting it be widened, or maybe that would be better put in a security
> SRFI, to possibly include things like OpenBSD's pledge, as in "I pledge
> not to do X, Y, and Z in the future".

That's not really possible in implementations that have a FFI. In
general, leaving all security stuff to the OS is safest. (And trying to
fix an insecure OS in a language is generally hopeless, save for
techniques that reduce bugs like GC.)

>> Initializing the Scheme umask to 0 as you suggest would make it so that
>> only the process umask is in effect by default. That seems reasonable.
>
> That works, but makes accidents more likely in the per thread code.

That's remedied if new threads initially inherit the umask (and cwd) of
the thread that spawned them.