[e-lang] Paper Comments

[Dan Bornstein]

Here are my comments based on a single reading of the draft posted as of 
about 4pm today. As Ping(? I think) said, my terseness is meant merely 
as an expedience. Overall, I think the paper is excellent; most of my 
comments are minor nitpicks. Also, apologies if any (all?) of this is 
stale; I wish I had time to keep up with it all!

-dan

##########

PAGE 2

> The Sequential StatusHolder introduces the statusHolder, and examines 
> its
> hazards in a sequential environment.

I wouldn't use a comma there, since the thing after the comma isn't a 
full sentence, nor is it part of a list of 3 or more clauses. You do the 
same thing in the rest of the list of sections as well.

footnote 3
> Hayek’s explanation of how property rights protects humans plans from
> interference

Some syntactic issues there.

PAGE 7

Fig.1: I don't get what the double-headed arrow in the middle of the 
figure is supposed to represent.

PAGE 11

Fig.2: I just want to cast my vote in favor of the line drawing over the 
shaded version.

PAGE 12

If the suggested replacement "A vat runs an event loop..." is taken, 
then the definition of "vat" two paragraphs hence should be moved 
earlier or integrated into that replacement.

PAGE 19

> (**unclear**) AM has given X and F access to the statusGetter.

"statusGetter" isn't in the code font (a second time in the paragraph as 
well).

> Ask Hopwood what he means by “E doesn’t rely on other vats to 
> implement the E
> language”.

I know I'm not Hopwood, but I bet the idea is that an E vat doesn't rely 
on anything it communicates with being a well-behaved E vat. It *could* 
be, but if not, there's nothing that the miscreant alleged-vat could do 
to corrupt the well-behaved vat it is communicating with. It's another 
riff on "Don't let the protocol be capable of expressing lies."


PAGE 22

> Promise chaining provides a way to allow some plans...

How about "Promise chaining allows some plans..." ?

PAGE 24

> There is no one best strategy...

How about "There is no single best strategy..." or "...unique..." to 
avoid a confusing misparse of "no one" (which caused me to reread it a 
couple times before realizing my mistake)?

PAGE 28

> If it does reconnect, it knows it may have missed updates in the 
> meantime, so
> it should first send a new getStatus query to refresh its own state 
> before >resubscribing.

That's fine for a simple system like the statusHolder, but I think it's 
worth at least addressing how a more complicated system would work, 
where effectively-lost update messages between a non-atomic sequence of 
getStatus() and addListener() might lead the client to an incomplete 
view of the object.

FWIW, I regularly run into the equivalent of this problem, and usually 
solve it by having addListener(), in addition to adding the designated 
listener, also send the object's current full state to the listener in a 
series of messages. (I know that's not necessarily the ideal solution.)

PAGE 31

> Thus its semantics are a bit like having thousands and thousands of 
> computer
> all hooked together

Is that a (minor) misquote? "computers"?

PAGE 35

The title of the paper is "Concurrency Among Strangers: Programming in E 
as Plan Coordination" but the Discussions and Conclusions section 
doesn't make an explicit tie-in either to "strangers" or "plan 
coordination."