Marc Feeley wrote:
>
> It is the "fully" that I don't like.  With the semantics I propose
> a user can decide what is shared and what is not shared (i.e. fully
> thread-local).  For example, if I want to create a thread that has
> a fully thread-local binding for the parameter current-input-port
> then you can simply say:
> [...]
>
> This way the user can choose what is shared and not on a
> per thread basis.
>

Right. But there are other ways to have non thread-local storage
(simple toplevel variables for example).

>>
>>That's not true. I'm probably expressing myself not clearly enough.
>>`make-parameter' creates a parameter in a global environment (not attached)
>>to any thread. Thread-creation copies the parent's parameter-env,
>>*but* this env will be empty if the parent has not yet changed it's
>>parameter-env (i.e. it is equivalent to the global env).
>
>
> But can the global env be mutated by the main thread?  In other words
> if the main thread does (current-output-port stderr) and (parameterize
> ((current-output-port stderr)) ...) does it mutate the global env?  My
> understanding was that it did (thus thread creation would have to copy
> the global env to get a consistent "snapshot" of the dynamic
> environment).  If the global env is immutable, then parameter-env
> could be as big (or bigger depending on your implementation) as the
> global env.  So scalability is an issue.

The global env is never mutated by any thread besides that the values
of parameters introduced freshly are put into it (the default or
initial value).
Scalability is definitely an issue, but I don't think that it is too expensive to prevent
it from being adapted as the default behaviour, which I find more useful.

>
> The "swapping semantics" hides a (potentially expensive) copying
> operation from the user.  I prefer when expensive operations are
> explicit so the user has some control over them.
>

Understood.

>
> I don't believe it would confuse users... there are few users that
> combine threads and parameters and mutation, and those that do can
> easily understand the semantics I propose (or indeed they are perhaps
> incorrectly assuming the semantics I propose which is simpler and more
> in line with the R5RS semantics!).  I am not changing the semantics of
> a well-established construct...

Well, I think you are. I assume many PLT users are using threads and
parameters, but I may be wrong, of course...

>
>>(BTW, there is a simple way out of this dilemma: use different
>>names - `make-dynamic' and `let-dynamic' come to mind, for example...)
>
>
> This is why I added "make-mutable-parameter".  Once again:
> make-parameter is compatible with existing systems that support
> parameters, even those supporting threads.

By heavily restricting the usefulness of `make-parameter'.

>
> Alternatively, someone (perhaps you?) could propose a SRFI giving a
> different semantics for "make-parameter" and mutation in the presence
> of threads.  I think my proposal is the "right" way, but I don't have
> a monopoly on "rightfulness"!
>

I already proposed what I think is the better solution (which of course
is not necessarily "righter" - yet more practical).

cheers,
felix