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

Some comments

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.