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.
> 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 agree that the API of parameters is not abstract, and that this could be improved with separate procedures (or syntax) for creation, mutation, reading and binding of dynamic variables. I did not propose this because of the convergence by many implementations to the "parameters" API and I wanted to place minimal burden on implementors/users of this API. Moreover, the main point of SRFI 39 is to propose the "right" semantics for dynamic binding in the presence of threads. > 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. I strongly believe that MzScheme's way (mutation without sharing) is wrong. It prevents a thread T1 from invoking a continuation C that was created in another thread T2, because T1 can't reinstate C's dynamic environment properly. The only way this can work in the presence of mutable dynamic variables is if it is possible for different threads to share the dynamic environment. This is what I'm proposing. Marc