John Cowan <cowan_at_ccil.org> writes:
> Michael Sperber scripsit:
>
>> OK, thanks. Now, this is different from SRFI 39, where a parameter is
>> bound to a single storage cell. Presumably, the spec could be twisted
>> to allow thread creation to create new storage cells, but I believe
>> this was specifically not the intent of SRFI 39.
>
> Diffidently I suggest that perhaps you remember the history too well
> and the final spec not well enough. As written SRFI 39 makes no
> references (and deliberately so) to threads. It defines the behavior
> for single-threaded Schemes only, and is consistent with any of these
> multi-threaded behaviors:
>
> 1) share dynamic state among all threads
> 2) clone dynamic state when a new thread is made
> 3) give each new thread a fresh dynamic state
The problem is that bad interaction with threads is inevitable, no
matter which specific decision you make. The degree of badness
varies, but not the presence of it in principle.
Having said that, the spec of SRFI 39 says that the procedure returned
by `make-parameter'
>> When it is called with no argument, the content of the cell bound to
>> this parameter object in the current dynamic environment is
>> returned.
Now, I don't see how this could be interpreted in different ways in
the presence of threads, at least if a parameter is created in thread
B after a thread A has been created, and then thread A references the
parameter---note how the spec says "global dynamic environment". (If
it's the other way around, as I said, thread creation might clone the
cell.)
However, as I said, I don't think it matters much: The consequences
are bad either way: Conflating dynamic binding with mutable state is a
bad idea, especially as cleanly separating them is possible and easy.
It's also "piling feature upon feature", which Scheme isn't about.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Sun Feb 11 2007 - 03:56:04 UTC