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.
> The distinction between `make-parameter' and `make-mutable-parameter' > is a reasonable compromise. > > MzScheme can't currently support `make-mutable-parameter'. I imagine a > revision in the near future that will allow it, Can't you simply use the reference implementation? You can implement make-mutable-parameter rather easily if you have a working make-parameter. You need to define a parameter that corresponds to the dynamic environment, and then use that instead of the global variable dynamic-env-local. > but I wonder what kinds > of tasks make mutable parameters useful. (No doubt I've asked before, > but the answer didn't stick. In the future, I can consult the archive > of this list. :) I don't really think of it in those terms. For one thing I tend to avoid mutation when possible, so it is hard for me to make a convincing case that you need mutable parameters. But just like some people find it is easier to express a computation using a mutable lexical variable, or a mutable data-structure, I think some people will find it is easier to express a computation using mutable parameters. It's a question of "freedom of speech". Let me also explain what motivated the semantics. There are two reasons. 1) The non-copying semantics specified in the SRFI is closer to the semantics of lexical variables. New threads don't get a fresh copy of the lexical variables, so I don't see why parameter objects (which are just dynamic variables) should be any different. If threads did copy their lexical environment (as is the case with UNIX processes created with fork), then I think the dynamic environment should also be copied. But I don't think this is the model of threads people want for Scheme (at least it is not the model of SRFI 18 which is the only specification for Scheme threads we have at this point). From a pragmatic point of view, it seems futile to copy the cells of the dynamic environment (hoping to make the child and parent independant) if the objects that are contained in those cells are mutable. 2) Copying the dynamic environment slows down thread creation. A simple implementation will take time proportional to the number of parameter objects. > The body of a `parameterize' is not in tail position, right? Correct. This is implementation dependent. > Typo in `make-parameter' example: it uses `make-mutable-parameter'. Fixed. Thanks. Marc