[e-cvs] cvs commit: e/doc/elib/equality after-both.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Wed, 7 Nov 2001 00:21:12 -0500
markm 01/11/07 00:21:12
Modified: doc index.html
doc/download/0-8-10beta index.html
doc/elang/kernel SendExpr.html
doc/elib/concurrency partial-order.html
doc/elib/equality after-both.html
Log:
link to new release on home page. Explanation of with=. Fixed partial-order pages
Revision Changes Path
1.84 +8 -5 e/doc/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/index.html,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -r1.83 -r1.84
--- index.html 2001/09/30 23:43:15 1.83
+++ index.html 2001/11/07 05:21:11 1.84
@@ -48,8 +48,8 @@
</td>
</tr>
<tr valign="TOP">
- <td><a href="download/0-8-10alpha/index.html"><font size="+1"><b>Download</b></font>
- <b><i>E</i> 0.8.10alpha1</b></a></td>
+ <td><a href="download/0-8-10beta/index.html"><font size="+1"><b>Download</b></font>
+ <b><i>E</i> 0.8.10beta1</b></a></td>
<td>After reading the <a href="download/licenses.html">licenses</a>,
get your own copy of <i><b><font color="#009000">E</font></b></i>.
(All licenses are Mozilla or Mozilla compatible open source licenses.)</td>
@@ -71,7 +71,7 @@
<td><a href="elang/quick-ref.html">Quick Reference Card</a></td>
<td>Reminders of some useful patterns you've learned.</td>
</tr>
- <tr>
+ <tr>
<td><a href="http://rosebud.mumble.net:8888/jar/e/faq.html"> FAQ</a>
</td>
<td>Jonathan Ress maintains the list of Frequently Asked Questions about
@@ -95,8 +95,11 @@
</td>
</tr>
<tr valign="TOP">
- <td><a href="download/0-8-10alpha/index.html">0.8.10alpha1</a>: A brave
- new CapTP (our cryptographic capability protocol)</td>
+ <td>
+ <p><a href="download/0-8-10alpha/index.html">0.8.10alpha1</a>: A brave
+ new CapTP (our cryptographic capability protocol).</p>
+ <p>(Note that the current release is <a href="download/0-8-10beta/index.html">0.8.10beta1</a>.)</p>
+ </td>
<td>This is the first release of E to be distributed (with full pipelining
support, but no 3vat introductions yet), persistent (sort-of), and
to support and confine locally untrusted code. The is the new current
1.3 +39 -0 e/doc/download/0-8-10beta/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/download/0-8-10beta/index.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- index.html 2001/11/07 03:10:08 1.2
+++ index.html 2001/11/07 05:21:11 1.3
@@ -144,6 +144,45 @@
<p>At first, we tried to be politically correct, and use a standard compatible
subset of XML as a basis, as documented <a href="../../elang/grammar/quasi-xml.html">here</a>.
</p>
+ <h3>Added Syntactic Support for Collection Derivation</h3>
+ <p>*** Move this explanation somewhere else, and link to it from here.</p>
+ <p>We have long planned to retire FlexMap and FlexList as abstractions for
+ normal programming, instead planning to depend solely on immutable collections,
+ probably based on <a href="http://www.waterken.com">Hydro</a>. This requires
+ one to make "changes" to a collection by derivation of a new
+ collection from an old one, rather than modifying the collection in place.
+ Whereas with a FlexMap, one might say</p>
+ <blockquote>
+ <pre>def map := #... a FlexMap
+...
+map[key] := value</pre>
+ </blockquote>
+ <p>Using only ConstMaps, one would instead say</p>
+ <blockquote>
+ <pre>var map := #... a ConstMap
+...
+map := map with(key, value)</pre>
+ </blockquote>
+ <p>Instead of modifying the collection, we modify the variable to hold a
+ new collection derived from the old by the '<a href="../../javadoc/org/erights/e/elib/tables/EMap.html#with(java.lang.Object,%20java.lang.Object)">with</a>'
+ message. Unfortunately, for an operation this ubiquitous, the latter notation
+ is a bit too awkward. On the e-lang list, we've had a long discussion
+ about various alternatives, all of which could be said to have been disqualified
+ in one way or another (*** need link). At the end of the day, I had to
+ chose one, so I have. As of this release, one can express the last line
+ of latter example with the following syntax:</p>
+ <blockquote>
+ <pre>map with= (key, value)</pre>
+ </blockquote>
+ <p>In fact, one can append an '=' to any message name to get this effect,
+ by analogy to how</p>
+ <blockquote>
+ <pre>x += 1</pre>
+ </blockquote>
+ <p>is equivalent to</p>
+ <blockquote>
+ <pre>x := x + 1</pre>
+ </blockquote>
<h3>Many bug fixes</h3>
<ul>
<li>xx</li>
1.14 +25 -19 e/doc/elang/kernel/SendExpr.html
Index: SendExpr.html
===================================================================
RCS file: /cvs/e/doc/elang/kernel/SendExpr.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- SendExpr.html 2001/09/30 23:43:19 1.13
+++ SendExpr.html 2001/11/07 05:21:11 1.14
@@ -147,7 +147,9 @@
up to the first failure to deliver, and it must never deliver any more
messages. Therefore, a successful delivery demonstrates that earlier messages
sent on the same reference must have been delivered. A failed reference
- must eventually become BROKEN.
+ must eventually become BROKEN. <br>
+ <i> See also <a href="../../elib/concurrency/partial-order.html#full-order">Two
+ Party Full Order</a>.</i>
<p>When a reference is included within an argument of a send, we say the
reference has been <i>forked</i>, and that what is received is not the
sent reference but a <i>fork</i> of the sent reference. Messages sent
@@ -156,14 +158,18 @@
prior to messages sent on that fork of the reference. Messages sent on
the original reference after the fork, and messages sent of the fork,
represent two separate full orders. These messages may be delivered in
- any interleaving of these orders.
- <p>Given two references, x and y, that designate the same recipient, "E
- join(x, y)" returns a new reference that also designates that recipient.
- Messages sent on either x or y prior to the join must be delivered prior
- to messages sent on the joined reference. The joined reference itself
- is simultaneously a fork of x and y -- is messages are sent on all following
+ any interleaving of these orders. <br>
+ <i>See also <a href="../../elib/concurrency/partial-order.html#tree-order">Three
+ Party Tree Order</a>.</i>
+ <p>Given two references, x and y, that designate the same recipient, "<code>E
+ join(x, y)</code>" returns a new reference that also designates that
+ recipient. Messages sent on either x or y prior to the join must be delivered
+ prior to messages sent on the joined reference. The joined reference itself
+ is simultaneously a fork of x and y -- if messages are sent on all following
the join, these messages may be delivered in any interleaving of their
- respective orders.
+ respective orders. <br>
+ <i>See also <a href="../../elib/equality/after-both.html">Four Party Partial
+ Order</a>.</i>
<p>Of course, if a reference should fail prior to a fork or join, the fork
or join of the reference is born failed, it may not deliver any messages,
and it must eventually become BROKEN.
@@ -238,17 +244,17 @@
on this reference, which may recursively be any of these cases. It
is equivalent for a promise to become broken and for it to resolve
to a broken reference. Promises come in two flavors: </p>
- <p>
- <ol>
- <li>
- <p>A LocalPromise has both the Vow end (the tail of the arrow)
- and the Resolver end (the head of the arror) in the same vat,
- so it is reliable up to crash/revive.</p>
- </li>
- <li>
- <p>A FarPromise spans vats, and so is reliable only up to partition.</p>
- </li>
- </ol>
+ <p>
+ <ol>
+ <li>
+ <p>A LocalPromise has both the Vow end (the tail of the arrow) and
+ the Resolver end (the head of the arror) in the same vat, so it
+ is reliable up to crash/revive.</p>
+ </li>
+ <li>
+ <p>A FarPromise spans vats, and so is reliable only up to partition.</p>
+ </li>
+ </ol>
<p></p>
</li>
</ul>
1.15 +1 -1 e/doc/elib/concurrency/partial-order.html
Index: partial-order.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/partial-order.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- partial-order.html 2001/09/30 23:43:22 1.14
+++ partial-order.html 2001/11/07 05:21:11 1.15
@@ -47,7 +47,7 @@
</TABLE>
<hr>
<!-- #BeginEditable "LongBody" -->
- <h1 align="center">Two Party On-a-Reference:<br>
+ <h1 align="center"><a name="full-order"></a>Two Party On-a-Reference:<br>
Full Order</h1>
<p>Among messages successively <i>sent</i> on a single reference (ie, using
the <i>eventual send</i> operator "<code><-</code>"), E guarantees
1.6 +59 -25 e/doc/elib/equality/after-both.html
Index: after-both.html
===================================================================
RCS file: /cvs/e/doc/elib/equality/after-both.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- after-both.html 2001/09/30 23:43:24 1.5
+++ after-both.html 2001/11/07 05:21:12 1.6
@@ -45,20 +45,20 @@
</TR>
</TABLE>
<hr>
- <!-- #BeginEditable "LongBody" -->
- <p>This page should be read after <a href="../concurrency/partial-order.html">Partially
+ <!-- #BeginEditable "LongBody" -->
+ <p>This page should be read after <a href="../concurrency/partial-order.html">Partially
Ordered Message Delivery</a>.</p>
- <p>So far we only have forks in the order specification. This creates only
- a tree order, not a general partial order. For pure capabilities without
- equality (as in Actors or Joule), this would be fine. However, E also
- has a distributed equality construct able to do distributed <a href="grant-matcher/index.html">grant
- matching</a>. To satisfy the constraints implied by the Grant Matcher
- Puzzle, this distributed equality construct must also introduce a join
- in the specification topology. Fortunately, this is easily implemented
- in E, in which the only special primitive is "==" (local immediate
+ <p>So far we only have forks in the order specification. This creates only
+ a tree order, not a general partial order. For pure capabilities without
+ equality (as in Actors or Joule), this would be fine. However, E also
+ has a distributed equality construct able to do distributed <a href="grant-matcher/index.html">grant
+ matching</a>. To satisfy the constraints implied by the Grant Matcher
+ Puzzle, this distributed equality construct must also introduce a join
+ in the specification topology. Fortunately, this is easily implemented
+ in E, in which the only special primitive is "==" (local immediate
sameness): </p>
- <p>
- <blockquote>
+ <p>
+ <blockquote>
<pre> def join(a, b) :any {
def [result, resolver] := PromiseMaker()
def hasLeft := false
@@ -100,19 +100,53 @@
}
</pre>
</blockquote>
- <p>Given <i>a</i> and <i>b</i>, this immediately returns a promise for a
- reference that will be acceptable as a valid interpretation what <i>a</i>
- meant, and a valid interpretation of what <i>b</i> meant. (Valid in the
- sense that the introducer that sent us each of these references would
- have no cause for complaint if we use the promised reference instead.)
- We may immediately start sending messages on this new reference, confident
- that these messages will only get delivered if the promise indeed gets
- fulfilled, and therefore a mutually acceptable reference could be obtained.
- If a mutually acceptable reference cannot be obtained, then the promise
- will become broken, and all messages sent to it will be discarded, using
- the usual broken promise contagion rules.</p>
- <p> <i><font color="#ff0000">XXXMore later...</font></i></p>
- <P ALIGN="left">
+ <p>The above function is actually predefined as the <code>join</code> method
+ of the object <code>E</code>.</p>
+ <p>Given <i>a</i> and <i>b</i>, "<code>def c := E join(a, b)</code>"
+ immediately defines <i>c</i> as a promise for a reference that will be
+ acceptable as a valid interpretation what <i>a</i> meant, and a valid
+ interpretation of what <i>b</i> meant. (Valid in the sense that the introducer
+ that sent us each of these references would have no cause for complaint
+ if we use the promised reference instead.) We may immediately start sending
+ messages on this new reference, confident that these messages will only
+ get delivered if the promise indeed gets fulfilled, and therefore a mutually
+ acceptable reference could be obtained. If a mutually acceptable reference
+ cannot be obtained, then the promise will become broken, and all messages
+ sent to it will be discarded, using the usual broken promise contagion
+ rules.</p>
+ <h2><a name="join-order"></a>Joining The Orders</h2>
+ <p>In fact, <i>c</i>, if it resolves, is a fork of <i>a</i> and a fork of
+ <i>b</i>. This is where the join in the ordering comes from. Given the
+ following sequence of actions</p>
+ <blockquote>
+ <pre>a <- u()
+b <- v()
+c := E join(a, b)
+a <- w()
+c <- x()
+b <- y()</pre>
+ </blockquote>
+ <p> if <i>a</i> and <i>b</i> are independent references to the same object,
+ and assuming no partition occurs, then </p>
+ <ul>
+ <li>u() and v() may be delivered in any order.</li>
+ <li> w() may only be delivered after u() is delivered.</li>
+ <li>x() may only be delivered after u() is delivered, as implied by "c
+ is a fork of a".</li>
+ <li>x() may only be delivered after v() are delivered, as implied by "c
+ is a fork of b".</li>
+ <li>y() may only be delivered after v() is delivered.</li>
+ <li>w(), x(), and y() may be delivered in any order.</li>
+ <li>All these messages are delivered at most once.</li>
+ </ul>
+ <p>If <i>a</i> and <i>b</i> do not designate the same object, then all the
+ above statements hold except that x() must not be delivered. In addition,
+ <i>c</i> must eventually resolve to BROKEN.</p>
+ <p>Should a partition occur, all the above statements continue to hold anyway,
+ but not in the obvious way. For example, should v() be lost in a partition,
+ never to be delivered, then x() and y() must never be delivered, and both
+ <i>b</i> and <i>c</i> must eventually resolve to BROKEN, as implied by
+ "c is a fork of b".</p>
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>