Purpose of SRFI 39
sperber@xxxxxx
(13 Jan 2003 10:58 UTC)
|
Re: Purpose of SRFI 39
Marc Feeley
(13 Jan 2003 14:21 UTC)
|
Re: Purpose of SRFI 39 sperber@xxxxxx (13 Jan 2003 14:32 UTC)
|
Re: Purpose of SRFI 39
felix
(13 Jan 2003 22:01 UTC)
|
Re: Purpose of SRFI 39 sperber@xxxxxx 13 Jan 2003 14:32 UTC
>>>>> "Marc" == Marc Feeley <xxxxxx@IRO.UMontreal.CA> writes: Marc> I agree that the API of parameters is not abstract, and that this Marc> could be improved with separate procedures (or syntax) for creation, Marc> mutation, reading and binding of dynamic variables. I did not propose Marc> this because of the convergence by many implementations to the Marc> "parameters" API and I wanted to place minimal burden on Marc> implementors/users of this API. Moreover, the main point of SRFI 39 Marc> is to propose the "right" semantics for dynamic binding in the Marc> presence of threads. But it seems you can't have both at the same time: you think that the "right" semantics is precisely not the semantics the implementations are converging on. You're therefore creating a confusing situation: the API (and the sheer presence) suggests that the parameter APIs are the same when they're not. Marc> I strongly believe that MzScheme's way (mutation without sharing) is Marc> wrong. It prevents a thread T1 from invoking a continuation C that Marc> was created in another thread T2, because T1 can't reinstate C's Marc> dynamic environment properly. The only way this can work in the Marc> presence of mutable dynamic variables is if it is possible for Marc> different threads to share the dynamic environment. This is what Marc> I'm proposing. That's fine with me. However, if you're departing from prior practice in this way (and distinguishing MAKE-MUTABLE-PARAMETER from MAKE-PARAMETER doesn't really affect the issue) and thus changing the previously established API, why not make this clear by introducing a new API with the proper abstractions? This way, there can be no confusion. Moreover, I doubt that this is a significant burden on the implementors (at least not if the current draft is not already a significant burden). If anything, the burden is with the *users* with code using the old API. But for them, it's easy enough to create a parameter library with the right semantics for their programs. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla