Let me rephrase my comments to be clear.  There are really two needs here.

1) Controlling the posix working directory and umask (that apply to the OS process)
2) The mapping of these concepts to Scheme threads

So for the first there could be the procedures

(posix-current-directory [ <dir> ])                that calls getcwd() or chdir()
(posix-current-file-permission-mask [ <mask> ])    that calls umask()

And for the second there could be the SRFI 39 parameters

(current-directory [ <dir> ])                that reads or assigns the parameter
(current-file-permission-mask [ <mask> ])    that reads or assigns the parameter

Where current-directory would be initialized to (posix-current-directory) and current-file-permission-mask would be initialized to 0.

Then (open-XXX-file <path>) would use the current-directory parameter and the current-file-permission-mask and the posix-current-file-permission-mask (combined with bitwise or).

Marc

> On Apr 29, 2020, at 9:31 AM, Marc Feeley <xxxxxx@iro.umontreal.ca> wrote:
>
>>
>> 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