I'd like to ask a question about the fundamental purpose of SRFI 39.

Is it there primarily to a) codify existing practice (which seems
reasonable given that many Scheme implementations already have a
parameter-like API) or b) to present a decent API for putting stuff into
the dynamic environment?

Of course, it could be both, but I'd like to argue that it's far from
a good API for what it's trying to do.  My two main objections are:

- The representation for parameters isn't abstract.  Of course, we
  don't know that we'll want to do things not easily doable with the
  procedural representation in the future, but it's possible.
  (Similar to the case Marc argued for CALL/CC.)

- The procedure representing a parameter does two completely different
  things depending on its number of arguments.  It may be just me, but
  I don't think that's a particularly good design.

I'd also like to point out that automatic parameter inheritance is not
necessarily a natural choice.  In particular, it duplicates
functionality already available via lexical scoping.  (I've seen
arguments on this list saying that this is a good thing.  I disagree.)
Moreover, it harbors the potential for space leaks because you create
implicit references to objects by spawning threads.

Of course, this is a plug for our paper

Martin Gasbichler, Michael Sperber: Processes vs. User-Level Threads
in Scsh, In The 2002 Scheme Workshop, Pittsburgh, Pa., October 2002.

available off

http://www-pu.informatik.uni-tuebingen.de/users/sperber/papers/

which discusses design choices for parameter-like facilities.

That leaves (if you agree with me) purpose a) for SRFI 39.
I'm not sure how many systems implement parameters and threads.
MzScheme does and (as has been pointed out) doesn't do sharing for
mutable parameter storage.  I think that's a good argument for having
SRFI 39 agree with MzScheme's way of doing things, or eliding mutable
parameters (as has been suggested) entirely.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla