On Thu, Apr 30, 2020 at 09:19:00AM +0200, Sebastien Marie wrote:
> On Thu, Apr 30, 2020 at 09:12:15AM +0300, Lassi Kortela wrote:
> >
> > We should probably change that to "MUST provide per-thread semantics". If
> > that's optional, won't it hamper the portability of multi-threaded Scheme
> > programs if they can't trust how the current directory is handled? In fact,
> > if some multi-threaded Schemes have a per-thread WD and others don't, how
> > will people write portable thread code changing the current directory?
>
> [...]
>
> For (1), as soon there is agreement, it could be per-thread or per-process. I am
> unsure about makes it implementation dependent. I would say that it depends how
> parameter are managed by the implementation (per thread or per process). Else,
> you could have, for example, a "standard" parameter per-process, and this
> particular parameter required to be per-thread, and it is inconsitent.
>
> Per srfi-39, a parameter seems to already being implementation dependent.
>
>         Given that there are semantic differences in the presence of threads and
>         that there are valid reasons for choosing each semantics, this SRFI does
>         not specify the semantics of parameter objects in the presence of
>         threads. It is left to the implementation and other SRFIs which extend
>         this SRFI to specify the interaction between parameter objects and
>         threads.
>

I just checked what R7RS said about parameters.

        If an implementation supports multiple threads of execution, then
        parameterize must not change the associated values of any parameters in
        any thread other than the current thread and threads created inside
        ⟨body⟩.

If I correctly understand, it means the use of `parameterize' implies a
per-thread value (the effect of passing arguments to the procedure returned by
`make-parameter', usually for "modification" isn't specified and is
implementation dependent).

So regarding (1), for consistency with parameter, the working-directory couldn't be
a per-process value.

And regarding (2), it is per-process value.

Thanks.
--
Sebastien Marie