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.
> > When writing code, you really have to think of the parameters created > > by make-parameter as read-only, and those created by > > make-mutable-parameter as read-write. It is only to simplify the > > migration of legacy code that the parameters created by make-parameter > > are possibly mutable (with an implementation dependent semantics). > > This is unfortunate, since this SRFI really moves all that "legacy" > code into non-specifiedness... Since SRFI 39 did not exist when the legacy code was written the code never conformed to it. So SRFI 39 does not "move" the code into non-specifiedness. The other choice (of having "make-parameter" create the mutable parameters as specified in SRFI 39) is even less appealing because in that case PLT legacy code would no longer work if PLT adopted that semantics. The existence of two kinds of parameters is mainly motivated by compatibility with PLT (so that there is very little work needed to implement it in PLT). > I think parameters (as used in Chez, PLT or (say) Chicken) are > (IMHO) well understood and heavily used. For these systems and Gambit-C, "make-mutable-parameter" and "make-parameter" can be defined as the native "make-parameter" when multithreading is not used. The semantic differences only matter with PLT when threads are being used and the parameters are mutated (indeed only PLT and Chicken implement threads and the Chicken manual does not explain the interaction between parameters and threads). I view SRFI 39's main contribution as a specification of how mutation of parameters should work in the presence of threads. > >>2) `parameterize' changes the parameters by "swapping", as > >> in the traditional implementation. > > > > > > What do you mean by "swapping"? Do you mean that parameterize does > > not create a new cell and simply saves the content of the cell, > > changes the content of the cell for the duration of the body, and then > > restores the cell? > > Right. > > > This would be unbelievably difficult to use in a > > multithreaded system, unless of course thread creation copies the > > dynamic environment of the parent (which I guess is why you want point > > 3). Moreover, this implementation is expensive when using > > continuations to jump between different dynamic scopes (you have to > > undo a bunch of parameter mutations, and then redo a bunch of other > > mutations). > > I don't think so. You could use a "copy-on-write" strategy that > copies the dynamic (parameter) environment only if a thread actually > mutates the parameter: say you have a global parameter environment, > and `make-parameter' puts the value into this. Every thread gets its > own parameter-environment (initially a copy of the parent thread's env [*]). > Then, when the parameter is referenced, you check wether the thread's > parameter-environment contains a value, and, if not, take the > global one. Mutating a parameter does the copying (if needed). > This should result in a negligible overhead for thread-creation, > and a not-too-expensive overhead in the worst case (a shallow vector > copy is used in Chicken, for example). No "copy-on-write" is not a valid implementation. The reason is that the "swapping" semantics requires the child thread to have an independent copy of the parent's thread. So the child must get a snapshot of the parent's dynamic environment which will make the child's mutations invisible to the parent ***AND*** the parent's mutations invisible to the child. The copy-on-write approach you suggest only makes the child's mutations invisible to the parent. > >>3) Make all parameters thread-local, child threads inherit > >> the parameter-settings of their parents. > > > > > > By thread-local you mean copy the dynamic environment (including the > > cells)? Then see my previous response to a comment by Matthew Flatt > > (to summarize: it isn't clean and it is expensive when you create a > > thread). > > > > Clean? Well, that's a matter of taste. Expensive? Not necessarily > (see above). When I say "clean" I don't mean it so subjectively. A strong argument can be made that the semantics I propose in SRFI 39 for dynamic binding are closer to the lexical binding semantics. What does this mean? Well, if you look at how environments are manipulated in the denotational semantics (section 7.2 of R5RS) you will see that there are only two operations on environments "lookup" and "extends". "lookup" returns the location in the store that is bound to an identifier. The value associated to a location in the store is obtained with "hold" and "assign" changes the value associated with the location. Dynamic binding as I propose it uses exactly the same operations (with the minor point that the domain of "lookup" and "extends" must be changed to accept parameter objects). In addition to the lexical environment, the semantic functions also need an extra environment: the dynamic environment. The dynamic binding semantics is simply obtained by having procedure call pass this dynamic environment to the called procedure (and this is the only thing that distinguished it from lexical binding). Similarly (but obviously outside the scope of R5RS), the creation of a new thread would capture the dynamic environment of the parent thread. That's it. There is no need for an additional semantic operation for copying dynamic environments (which is non trivial because it must allocate store). Dynamic binding is a simple and natural extension of the R5RS semantics. This is what I mean by "clean". Marc