> On Apr 29, 2020, at 9:25 AM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>>> * current-directory (per-thread parameter)
>>> * os-current-directory (procedure - 0 args = getter, 1 arg = setter)
>>>
>>> * current-umask (per-thread parameter)
>>> * os-[current-]umask (procedure - 0 args = getter, 1 arg = setter)
>> This works for me, but while using argument count would keep the
>> number of procedures the same, we're already using "set-*" as a convention
>> for changing state.
>
> It's true that set-* is more obvious, but parameter objects (SRFI 39) work such that the setter is the same as the getter. Since there seems to be agreement that the current directory should be implementable as a thread-local parameter, using a unified getter/setter procedure would be consistent with that.

+1

>> I don't see see any need to include "current" in the umask procedure
>> names, current is implied, pretty much implied for all procedures like
>> this.
>
> Yeah, current-umask is a bit wordy. It would just be consistent with the others. Perhaps the "current" is superfluous.

I think current is good… it is umask that is strange.  Using current-file-permission-mask is much clearer, more “portable” to other OSes, and the length of the name is not an issue because it will seldom be called.

>
>> I'm not sure about changing working-directory to
>> current-directory, the underlying POSIX procedure wide call getcwd
>> uses both....  Using both could be better, but if not that, I'd prefer
>> keeping working-directory.
>
> My argument is that all the other process/thread state stuff is called "current". The working directory is the only one that is called a "working" anything. (Does this imply everything else is "lazy"? :)
>
> Current-working would be two words for the same thing. "Working" in Unix doesn't refer to any other concept and is just a synonym for "current" AFAIK. The only other thing I can think of is "working set" and that's about CPU caches IIRC.

+1

Marc