[e-lang] Yet Another Revision

[David Hopwood]

I still have some more substantive comments yet to post, but in the
meantime here are more nitpicks:


- To succeed, we must find ways of reducing the size of the resulting cases
- analysis.
+ To succeed, we must find ways of reducing the size of the resulting case
+ analysis.


- Even under sequential and benign conditions, the listener pattern in
- the statusHolder creates plan interference hazards programmers must
- beware of.
+ Even under sequential and benign conditions, the listener pattern in
+ the statusHolder creates plan interference hazards against which
+ programmers must defend.


   If the trade above succeeds promptly, the finance application deposits money
   into the account /during/ the update process. An update of the balance /after/
   the deposit is sent recursively, and then the update from /before/ the deposit
   completes. Thus notifications arrive /out of order/, so when the notification
   loop from before the deposit completes, it will inform subscribers of the wrong
   (pre-deposit) value.

Excessive use of italics. Suggest dropping the italics on at least "out of order",
and possibly "during".


   The nested publication hazard is especiallly striking because it reveals that
   problems typically associated with concurrency may arise even in a simple
   sequential example.

especially


   When the \abst{statusHolder}---or any agent---is executing plan \name{X},
   and discovers the need to engage in plan \name{Y}, in a sequential system,
   it has two simple choices of when to do \name{Y}:

X and Y are not object names. I suggest $X$ and $Y$.


- Execution proceeds by taking a pending-delivery from the queue, deliverying
- its message to its object, ...
+ Execution proceeds by taking a pending-delivery from the queue, delivering
+ its message to its object, ...


- We now consider the case where our account (including account manager, and
- its statusHolder) runs in \vat{A} on one machine, and our spreadsheet app
- (including it's listener) runs in \vat{S} on another machine.

+ We now consider the case where our \name{Account} (including its \name{Manager}
+ and \name{StatusHolder}) runs in \vat{A} on one machine, and our spreadsheet
+ application (including its listener, \name{Cell}) runs in \vat{S} on another
+ machine.


   Since each is granted the authority to corrupt the others via underlying
   components on which they all rely, they cannot useful protect against such
   “friendly fire”.

usefully


- 7.2 POLA
+ 7.2 Principle Of Least Authority


   If the finance application calls setStatus with a bogus balance, the spreadsheet
   will dutifully render it.

\meth{setStatus}


   The satusHolder, by bundling two kinds of authority into one object, encouraged
   patterns where both kinds of authority were provided to objects that only needed
   one.

statusHolder


   Now the account manager can make use of makeStatusPair as follows:

\code{makeStatusPair}


- \name{AM} has given X and \name{F} access to the statusGetter.
+ \name{Manager} has given \name{X} and \name{F} access to the \var{statusGetter}.


   If an immediate-call to \var{epimenides} would be considered of type ``promise
   for boolean'', then an eventual-send has the same type, since ``promise for
   promise for \name{T}'' is the same as ``promise for \name{T}''.

T is not an object name. Use $T$.


   Returning to our listener example, if a partition separates VatA from VatS,
   SH's reference to XL will eventually be broken with a partition-exception.

\name{StatusHolder}'s reference to \name{Cell}


- def epimenides() { return flag <- not() }
+ def epimenides() :vow[boolean] { return flag <- not() }
   [...]
+ ``\code{:vow[boolean]}'' is a \emph{return guard} declaring that
+ \code{epimenides} returns a promise that will resolve to a boolean in this vat.


- There is no one best strategy for maintaining consistency in the face of
- partitions and merges.
+ There is no single best strategy for maintaining consistency in the face of
+ partitions and merges.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>