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