[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- 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.