Email list hosting service & mailing list manager

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