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.
> > 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. > > Yes. I was thinking completely backward. > > A programmer could also put a mutable value inside a `make-parameter' > to get the same expressiveness, right? Yes. > I find this line of reasoning so compelling that I now advocate the > elimination of `make-mutable-parameter'. You mean: parameters should be mutable according to the specified semantics and "make-parameter" should create mutable parameter objects, consequently "make-mutable-parameter" can be removed. Since this was my original specification I'll gladly switch back to it, unless there are strong objections. > FWIW, I found your arguments in favor of `make-mutable-parameter' > uncompelling: no particular use for it, but seems on the surface to be > easier to implement, etc. These sort of arguments seem suspiciously > like the ones that support dynamic scope over lexical scope. No the "efficiency of implementation" (of thread creation and continuation transfer) is only a secondary reason. The primary reason is that the semantics of parameter objects is closer to lexical variables (the only difference is dynamic vs. lexical scope). This makes them easier to understand. It is nice however that the semantically "right thing" does not cause thread creation and continuation transfer to be slow (maybe this is not a coincidence, but I don't want to start philosophizing about programming language design...). Marc