[e-lang] Quick comments needed on tgc draft
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
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
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