[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Some comments

- 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.