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.
- Most existing versions of `parameterize' evaluate the new parameter values in parallel (as in `let'). Is there a particular reason why this SRFI insists on doing the evaluation in `let*' fashion? - I'm not sure with this one, but (if I haven't overlooked something in the SRFI-18 specification), is the definition of `dynamic-bind' in the reference implementation reentrant? It might be possible that `current-thread' in the before thunk refers to a different thread than the one active in the after thunk. - Is it really desirable to separate parameters into two classes (i.e. mutable and (perhaps) non-mutable)? The whole specification is uncomfortably vague with respect to non-mutable parameters and I don't really see the advantage of having the non-thread-local kind. Or is this just an attempt to somehow cram some degree of portability in this SRFI? I propose a much simpler and more portable solution: (and you won't like it ;-) 1) Dump `make-mutable-parameter'. `make-parameter' returns a mutable parameter object. 2) `parameterize' changes the parameters by "swapping", as in the traditional implementation. 3) Make all parameters thread-local, child threads inherit the parameter-settings of their parents. cheers, felix