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? Actually this is a choice that is motivated by my implementation in Gambit-C. I'll admit however that it makes more sense to do the evaluation like `let' (I can't even make an argument that it is faster to do it `let*' style). So unless there are strong objections I will change this aspect. > - 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. I'm not sure what you mean by reentrant in this particular case. But yes it is possible that the before and after thunks (of a particular call to dynamic-wind) are called by different threads. This is consistent with SRFI 18, specifically with the concept that dynamic environments are attached to continuations (i.e. when a continuation is created the current dynamic environment is attached to it, when the continuation is resumed, possibly by another thread than the one that created the continuation, the dynamic environment will be restored). > - 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 During the preparation of this SRFI I first had only one kind of parameter object, that was mutable and was created with make-parameter. However the semantics were not compatible with MzScheme's so I added the other kind of parameter to improve compatibility. When writing code, you really have to think of the parameters created by make-parameter as read-only, and those created by make-mutable-parameter as read-write. It is only to simplify the migration of legacy code that the parameters created by make-parameter are possibly mutable (with an implementation dependent semantics). > 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? See my previous response to a comment by Matthew Flatt. > 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. I'm with you so far... > 2) `parameterize' changes the parameters by "swapping", as > in the traditional implementation. What do you mean by "swapping"? Do you mean that parameterize does not create a new cell and simply saves the content of the cell, changes the content of the cell for the duration of the body, and then restores the cell? This would be unbelievably difficult to use in a multithreaded system, unless of course thread creation copies the dynamic environment of the parent (which I guess is why you want point 3). Moreover, this implementation is expensive when using continuations to jump between different dynamic scopes (you have to undo a bunch of parameter mutations, and then redo a bunch of other mutations). > 3) Make all parameters thread-local, child threads inherit > the parameter-settings of their parents. By thread-local you mean copy the dynamic environment (including the cells)? Then see my previous response to a comment by Matthew Flatt (to summarize: it isn't clean and it is expensive when you create a thread). Marc