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.
>>>>> "Olin" == Olin Shivers <shivers@xxxxxxxxxxxxx> writes: Olin> I know Mike S & Kelsey prefer to reset dynamic bindings to fresh Olin> bindings with top-level values at thread-spawn boundaries. I think this Olin> is completely broken. Just for the record (not that I think this has any bearing on SRFI 39), let me point out a few things: - For at least one parameter (the current exception handler), we know that duplicating the old binding is the wrong thing. - Generally, this implicit copying of references to an object harbors the risk of creating space leaks. When you create a thread, you hang on to all to its parents' parameters---even those you don't know about. Olin> Spawning a thread, calling a function -- it's a dynamic nesting. - This sentence sounds nice on the surface, but you provide no arguments to support it. In fact, I'd say that spawning a thread is obviously *not* a dynamic nesting. In Scheme 48 and scsh, spawning a thread means handing a thunk to the scheduler. The *scheduler* calls that thunk, not the process parent. Most certainly, the continuation of the thunk of the spawned thread isn't the continuation of the spawning expression in the parent in any thread system that's like SRFI 18. This "dynamic nesting" aspect only appeals to our intuition because the visual structure of the program text suggests it---it's still wrong. (Maybe this suggests that the program text should look different, I don't know.) - Richard would point out that it's necessary to clarify the relationship of parameters with DELAY: if parameters get inherited for child threads, why don't they get inherited for the code wrapped in a DELAY? (Or do they?) - With this inheritance, you duplicate functionality provided by lexical scoping. This goes against the design spirit of Scheme. - It's easy implement inheritance on top of a non-inheriting implementation of parameters (which is what Scheme 48/scsh do), but harder and more awkward to do the reverse. (Note that I never said that there shouldn't *be* a parameter mechanism with inheritance---I only said that the *primitive* mechanism shouldn't have it.) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla