[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on SRFI-39

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