This page is part of the web mail archives of SRFI 39 from before July 7th, 2015. The new archives for SRFI 39 contain all messages, not just those from before July 7th, 2015.
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