[e-lang] Quick comments needed on tgc draft

Mark Miller markm at cs.jhu.edu
Fri Jun 17 21:17:35 EDT 2005

Thanks to everyone for their comments, and for their help with LaTeX. All the
text has now been converted to LaTeX, I think, even, perhaps, correctly.
The new draft is at


with the source at


to compile it, you still need the files from Springer at


There are not yet any figures, and the remaining unwritten sections remain
unwritten. If you've already sent in comments on the earlier draft, I do not
suggest spending time on this draft -- wait for one with the new sections. If
you haven't started yet, please read this draft rather than the earlier one.

All notes to myself of changes I still need to make are marked with a "**".

Due to a suggestion by MarcS, I radically trimmed the explanation of promise
pipelining, in order to keep the paper focused on correctness issues rather
than performance.

Piotr, having truncated the pipelining explanation, I am no longer explaining 
the tracer message. However, I am still thinking about your suggestion for an 
improved resolution protocol -- I think it would indeed be an improvement over 
what we've got.

Kevin & David, I completely dropped all guards from all examples, adopting the 
new easy-return style, and so no longer need to explain "any", "void", or soft 
types -- a big improvement!

Kevin, in light of the responses I got, I dropped the bold & italics on "E". 
I'm happily surprised to find that the result reads fine to my eyes as well.

Some responses not reflected in the new draft:

MarcS, I am still pondering your suggestions for the abstract.

Alan, the [Karp**] is intended to be a Polaris citation. I thought about 
dropping the Hayek paragraph, but decided to keep it, as I can't figure out 
any better way to make the transition from human plan coordination to 
programmatic plan coordination.

Alan & David, I am still thinking about "turn" vs "event".

Bill, I decided to stick with "plan" to keep the reader in this way of viewing 
the problem.

Darius, I haven't yet figured out a *short* way to mention that the observer 
pattern of [Gamma**], although similar to the listener, would require quite a 
different analysis and presents a different set of problems. (Intermediate 
states are missed, and, under concurrency, if getStatus isn't synchronized, 
you're sampling the status at an arbitrary time during someone else's plan, 
when it may not be meaningful.)

Ian, I think "interleavings needed for progress" is correct. By using locking 
to outlaw certain interleavings, it is certain *plans* which can no longer 
progress, not interleavings. The interleavings in question simply cannot occur.

Steve, I dropped the text about immediate-calling a broken reference, as I 
realized I didn't need it. But remind me to explain the issue to you sometime.

David, what do you mean by "E doesn't rely on other vats to implement the E 

Everyone, thanks again! If you've contributed and aren't in the 
acknowledgments, please let me know.

Text by me above is hereby placed in the public domain


More information about the e-lang mailing list