> On Apr 23, 2020, at 1:26 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Do., 23. Apr. 2020 um 18:25 Uhr schrieb Marc Feeley
> <xxxxxx@iro.umontreal.ca>:
>
> [...]
>
>>> b) get a per-thread CWD that is a copy of foo's per-thread CWD, or
>>>
>>> c) get a per-thread CWD that *is* foo's per-thread CWD, such that mutations done in foo are visible in bar and vice versa?
>>
>> c of course… :-)  Copying the parameter (option b) would introduce a restriction (not being able to mutate) that is an arbitrary choice by the spec designer.  If the programmer wants a copy they can add a (parameterize ((current-directory (current-directory))) …) around their code.  I think it is a bad design in general to do something automatically that can’t be undone.  Also, if you argue that copying parameters is “the right thing” you may introduce performance issues when the dynamic environment contains lots of bindings.
>
> I would argue instead that option (b) is the more general.  If you
> want mutability across threads, just put the value in a box and don't
> modify the parameter directly but just what's in the box. With (c), on
> the other hand, you cannot get true thread local parameters, can you?
> The reparameterization trick you mention does not work if the code
> spawning the thread does not know about all thread-local parameters.

You could simply add a (dynamic-env-copy thunk) procedure that runs thunk with all the dynamic environment bindings copied, which could be useful anyway as a general purpose operation.

Your argument is similar to saying that we could get rid of “set!” altogether by just doing (define var (box val)) whenever we want a mutable variable.  Then get rid of set-car! similarly… to just have box and set-box!.  Very MLish!  I view that as taking something away from my language, not the other way around!

In any case, mutation of parameter objects should not be viewed as good style, similarly to the use of “set!”.  But this does not mean I want to remove it from the language because in some cases it is the right thing to use.

If parameter bindings are automatically copied when a thread is started it prevents that new thread from changing the parent’s parameter bindings easily, but it is still possible to do so with continuations in a contrived way…  by having the child call a continuation created in the parent (because the dynamic environment is captured by the continuation) and arranging for control to come back to the child (with another continuation).  So this means copying the dynamic bindings on thread creation makes a simple thing (parameter object mutation) very complex to achieve, but not impossible… so you don’t get a “reliable parameter independence” property.

If the parent thread wants the child to have a copy of the dynamic bindings, I prefer that this be stated explicitly with:

  (thread-start! (dynamic-env-copy (lambda () (make-thread (lambda () …)))))

but I would probably never use that in my own code because I rarely find the need to mutate parameter objects.

>
> With respect to the performance issues, I have no simple answer yet.
> It would suffice to spawn parameters on demand, which would just make
> the mutation more costly, I think.

I’m not sure I follow.  You mean a kind of “copy-on-write”?  I’d like to see the implementation of that and compare the performance to the case where there is no copy involved.

Marc