[e-lang] Yet Another Revision

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Thu Jun 30 22:11:02 EDT 2005

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
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}

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>