Capabilities and RPC calls...
Mark S. Miller
Wed, 27 Oct 1999 16:36:35 -0700
(Warning on replying: I'm send this to two groups. If you don't want your reply to go to both groups, check your addressing.)
At 11:53 AM 10/26/99 , Gavin Thomas Nicol wrote:
>Sorry, it was the reference to "state" that threw me
>off. I always use the term "environment" to describe what
>you mean by "state".
Yes, that's about right. The difference in that I define "state" as the subset of the environment corresponding to variables used freely by the closure. In doing so, I believe I'm paralleling Hewitt's notion of "acquaintances". By most criteria it should be semantically equivalent for a closure to hold on to its entire spawning environment vs only the subset I'm calling state. Two meta-issue cause me to be picky about the difference in E: 1) Defining a portable debugger's eye view, and 2) defining "correctness" for a garbage collector.
Portable Debugger's Eye View
There is a natural and unavoidable tradeoff/conflict between fancy compiler optimizations and presenting a standard intuitive view of computation-in-progress through a debugger. Fortunately, if good choices are made about what the standard portable debugger's view is, this view can be often be maintained in the face of amazing compiler optimizations by having the compiler also provide the debugger enough information to reverse engineer (so to speak) the optimizations. But not always, since some transformations cause loss of dynamic information that would have been necessary to reconstruct the naive view.
Like Smalltalk, E sides with the debugger over runtime efficiency. Among E's "good choices", that allows this to be done without too great a penalty, is to say that a closure only holds on to state rather than a whole environment. I believe this is again like Smalltalk.
For E's garbage collector to be correct, we must define what is and is not reachable in terms of the language semantics, rather than the implementation. How can this be semantically visible? E will have local weak pointers & post-mortem finalization (along the lines of ParcPlace Smalltalk). If you don't know what this is, the important point is that it enables a program to tell if a particular object has been gc'ed. This makes the definition of the gc contract semantically significant.
In E, an object points only at the objects in its state, not all the objects in its environment. If an object is only reachable from the environments of reachable objects, but not from the state of any reachable object, then it is not considered reachable. A conservative GC is allowed to collect it, and a non-conservative GC is obligated to eventually collect it.
>I'm just re-reading you paper, and would like to pick up
>on the discussion after I've done so. As I said before,
>I wrote a distributed scheme a number of years ago. Many
>of the concepts *appear* familiar, and I'm kind of in the
>process of coalescing concepts...
I look forward to it. Also, if there's anything I can read about your distributed scheme, I'd appreciate it.