markm 01/09/13 21:36:18
Modified: doc Makefile toc.txt
doc/download index.html which.html
doc/download/0-8-9-1 index.html
doc/download/stl-0-8-9-t index.html windows-src.html
doc/download/stl-0-8-9-t-1 index.html
doc/elang quick-ref.html
doc/elang/blocks miranda.html
doc/elang/concurrency introducer.html race.html
doc/elang/tools updoc.html
doc/elib/concurrency msg-passing.html turns.html
doc/elib/equality after-both.html
doc/history fcp.html lambda.html
Log:
preparing for the 0.8.10alpha1 release
Revision Changes Path
1.40 +0 -2 e/doc/Makefile
Index: Makefile
===================================================================
RCS file: /cvs/e/doc/Makefile,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- Makefile 2001/08/28 02:12:44 1.39
+++ Makefile 2001/09/14 01:36:17 1.40
@@ -137,5 +137,3 @@
clobber-javadocs:
-rm -rf javadoc
-rm -rf impldoc
-
-
1.43 +7 -2 e/doc/toc.txt
Index: toc.txt
===================================================================
RCS file: /cvs/e/doc/toc.txt,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- toc.txt 2001/07/14 12:54:09 1.42
+++ toc.txt 2001/09/14 01:36:17 1.43
@@ -290,12 +290,17 @@
windows-src.html
unix-bin.html
unix-src.html
- stl-0-8-9-s/
+ stl-0-8-9-t/
windows-bin.html
windows-src.html
unix-bin.html
unix-src.html
- stl-0-8-9-t/
+ stl-0-8-9-t-1/
+ windows-bin.html
+ windows-src.html
+ unix-bin.html
+ unix-src.html
+ 0-8-10alpha/
windows-bin.html
windows-src.html
unix-bin.html
1.26 +5 -5 e/doc/download/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/download/index.html,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- index.html 2001/04/27 05:18:36 1.25
+++ index.html 2001/09/14 01:36:17 1.26
@@ -81,16 +81,16 @@
</tr>
<tr>
<td> </td>
- <td><a href="stl-0-8-9-s/index.html">stl-0.8.9s</a>: Non distributed
- internal release. Variables are default final, unless declared "<a href="http://www.eros-os.org/pipermail/e-lang/2001-February/004437.html"><code>var</code></a>"</td>
+ <td><a href="stl-0-8-9-t/index.html">stl-0.8.9t</a>: Non distributed
+ internal release. Major syntax reform. Enhanced eBrowser.</td>
</tr>
<tr>
<td> </td>
- <td><a href="stl-0-8-9-t/index.html">stl-0.8.9t</a>: Non distributed
- internal release. Major syntax reform. Enhanced eBrowser.</td>
+ <td><a href="stl-0-8-9-t-1/index.html"><b>stl-0.8.9t.1</b></a>: Dean's
+ transformer -- more efficient interpretation, and a first step towards
+ an <i><b><font color="#009000">E</font></b></i> compiler.</td>
</tr>
</table>
- <h2> </h2>
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>
1.29 +18 -15 e/doc/download/which.html
Index: which.html
===================================================================
RCS file: /cvs/e/doc/download/which.html,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- which.html 2001/04/27 05:18:36 1.28
+++ which.html 2001/09/14 01:36:17 1.29
@@ -64,11 +64,10 @@
<b><i><font color="#009000">E</font></i></b> 0.8.9.</p>
<p>
<ul>
- <li><b><a href="0-8-4/index.html"><i>E</i> 0.8.4</a></b>. Syntactically,
- <b><i><font color="#009000">E</font></i></b> 0.8.4 is a classic expression
- language, in which the value revealed by a function or method body is
- the value that the body evaluates to, as in this function for adding
- three numbers.
+ <li><a href="0-8-4/index.html"><i>E</i> 0.8.4</a>. Syntactically, <b><i><font color="#009000">E</font></i></b>
+ 0.8.4 is a classic expression language, in which the value revealed
+ by a function or method body is the value that the body evaluates to,
+ as in this function for adding three numbers.
<pre>
def add3(a, b, c) { a + b + c }</pre>
</li>
@@ -83,7 +82,7 @@
<pre>
def add3(a, b, c) { ^ a + b + c }<i><font color="#009000"> </font></i></pre>
</li>
- <li> <b><a href="0-8-9/index.html">E 0.8.9</a></b>. The "<code>^</code>"
+ <li> <a href="0-8-9/index.html">E 0.8.9</a>. The "<code>^</code>"
proposal generated a lot of discussion, for which the major thread-roots
are <a href="http://www.eros-os.org/%7Emajordomo/e-lang/0844.html">here</a>,
<a href="http://www.eros-os.org/%7Emajordomo/e-lang/0895.html">here</a>,
@@ -100,7 +99,7 @@
<p>See the thread rooted in the <a href="http://www.eros-os.org/%7Emajordomo/e-lang/1322.html">release
notes</a>.</p>
</li>
- <li>
+ <li>
<p><a href="0-8-9-1/index.html"><b>E 0.8.9.1</b></a> is a branch off
of 0.8.9, in which many of the bugs fixed in the internal development
successors of 0.8.9, listed below, have been applied to 0.8.9 itself.
@@ -108,7 +107,7 @@
we all await the release of 0.8.10.</p>
</li>
<li>
- <p><b><a href="stl-0-8-9-s/index.html">E slt-0.8.9s</a></b> is an interim
+ <p><b><i><font color="#009000">E</font></i> stl-0.8.9s</b> was an interim
non-distributed version, released mainly to support E compilation
work. It has several important language improvements, including the
hosting of locally untrusted code. The build and install system have
@@ -116,18 +115,22 @@
are now non-mutable by default.</p>
</li>
<li>
- <p><b><a href="stl-0-8-9-t/index.html">E slt-0.8.9t</a></b> is an interim
- non-distributed version, released with some major syntactic reforms
- due to discussion on the e-lang list. Also, it has a much improved
- eBrowser. </p>
- </li>
+ <p><a href="stl-0-8-9-t/index.html">E stl-0.8.9t</a> is an interim non-distributed
+ version, released with some major syntactic reforms due to discussion
+ on the e-lang list. Also, it has a much improved eBrowser. </p>
+ </li>
+ <li><a href="stl-0-8-9-t-1/index.html"><b>E stl-0.8.9t.1</b></a> is an
+ internal branch off of stl-0.8.9t, released mainly to support E compilation
+ work, in which the old slow interpreter has been replaced by Dean's
+ new transformer and faster interpreter. Besides speeding interpretation,
+ this transformation should be major progress towards an E compiler.</li>
</ul>
<p>So the price of developing with <b><i><font color="#009000">E</font></i></b>
- 0.8.4 is that, once <b><i><font color="#009000">E</font></i></b> 0.8.10
+ 0.8.9.1 is that, once <b><i><font color="#009000">E</font></i></b> 0.8.10
is released, you will have to edit your program to use the new syntax.
If your current use of <b><i><font color="#009000">E</font></i></b> does
not yet involve distributed (inter-Vat) messaging, then you should use
- the <b><i><font color="#009000">E</font></i></b> 0.8.9 or stl-0.8.9p release.</p>
+ the <b><i></i></b>stl-0.8.9t.1 release.</p>
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>
1.8 +1 -1 e/doc/download/0-8-9-1/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/download/0-8-9-1/index.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- index.html 2001/04/27 23:24:47 1.7
+++ index.html 2001/09/14 01:36:17 1.8
@@ -35,7 +35,7 @@
<tr>
<td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="../0-8-9/index.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: E 0.8.9 Download and Install E" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><a href="windows-bin.html"><img src="../../images/first.gif" width="32" height="64" alt="1st child: E 0.8.9.1: Installing on Windows" border="0"></a><!-- #EndEditable --></td>
- <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="../stl-0-8-9-s/index.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: E stl-0.8.9s Download and Install E" border="0"></a><!-- #EndEditable --></td>
+ <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="../stl-0-8-9-t/index.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: E stl-0.8.9t Download and Install E" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
1.3 +2 -2 e/doc/download/stl-0-8-9-t/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/download/stl-0-8-9-t/index.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- index.html 2001/04/05 04:27:07 1.2
+++ index.html 2001/09/14 01:36:17 1.3
@@ -33,9 +33,9 @@
<!-- #BeginEditable "Path" -->/ <a href="../index.html">download</a> <!-- #EndEditable --></td>
</tr>
<tr>
- <td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="../stl-0-8-9-s/index.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: E stl-0.8.9s Download and Install E" border="0"></a><!-- #EndEditable --></td>
+ <td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="../0-8-9-1/index.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: E 0.8.9.1 Download and Install E" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><a href="windows-bin.html"><img src="../../images/first.gif" width="32" height="64" alt="1st child: E stl-0.8.9t: Installing on Windows" border="0"></a><!-- #EndEditable --></td>
- <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><img src="../../images/next-gray.gif" width="64" height="32"><!-- #EndEditable --></td>
+ <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="../stl-0-8-9-t-1/index.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: E stl-0.8.9t.1 Download and Install E" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
1.2 +15 -11 e/doc/download/stl-0-8-9-t/windows-src.html
Index: windows-src.html
===================================================================
RCS file: /cvs/e/doc/download/stl-0-8-9-t/windows-src.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- windows-src.html 2001/04/05 03:16:04 1.1
+++ windows-src.html 2001/09/14 01:36:17 1.2
@@ -73,8 +73,8 @@
</table>
</div>
<p>See the <a href="index.html#dependencies">Dependencies</a> section for
- information on obtaining appropriate version of a JDK, the Cygwin environment,
- the byacc/J parser generator, and the zipping tools.</p>
+ information on obtaining appropriate versions of a JDK, the Cygwin environment,
+ the BYacc/J parser generator, and the zipping tools.</p>
<h1><a name="src"></a>The <font color="#009000"><em>E</em></font> Source
Distribution</h1>
<p>For Windows users, we recommend downloading the <a href="stl-E-src-0.8.9t.zip">zip
@@ -97,7 +97,9 @@
4.1 Standard Edition). For concreteness, and because it's what I use,
I'll explain how to build a Cafe project for <font color="#009000"><em><b>E</b></em></font>,
but users of other development environments should easily see how to do
- likewise in their system.</p>
+ likewise in their system. The following instructions assume that you unpack
+ your sources into "<code>d:/e/src</code>", and that you install
+ into "<code>c:/Program Files/erights.org</code>".</p>
<p>To start with, create a "New Project". For a project type,
select "Empty Project" since we don't want it generating new
source files for us. Select "Project Options". Under the "Project"
@@ -106,16 +108,17 @@
- A program that requires a java.exe to run".</p>
<p>For the "<code>Main Class</code>" enter "<code>org.erights.e.elang.interp.Interp</code>"
-- the class whose <code>main()</code> is the top of the E interpreter.
- For command like arguments, put "<code>d:\e\src\esrc\scripts\elmer.e</code>".
- Elmer is a good way to test each new build of <font color="#009000"><em><b>E</b></em></font>.</p>
+ Your command line arguments string should be </p>
+ <blockquote>
+ <pre>"-De.home=c:/Program Files/erights.org" "d:/e/src/esrc/scripts/elmer.e"</pre>
+ </blockquote>
+ <p>Elmer is a good way to test each new build of <font color="#009000"><em><b>E</b></em></font>.</p>
<p>On the "<code>Compiler</code>" tab, we recommend deselecting
"<code>Show command line</code>", but salt to taste.</p>
<p>On the "<code>Directories</code>" tab, for "<code>Show
directories for</code>", first select "<code>Input class files</code>".
- This is where you enter the equivalent of the CLASSPATH. Assuming you
- installed the <font color="#009000"><em><b>E</b></em></font> source tree
- at "<code>d:\e\src</code>", you should enter the following in
- this order:</p>
+ This is where you enter the equivalent of the CLASSPATH. You should enter
+ the following in this order:</p>
<div align="center">
<table cellpadding="8" border="1">
<tr>
@@ -154,10 +157,11 @@
enter "<code>d:\e\classes</code>". This is where Cafe's compiler
will place the <code>*.class</code> files.</p>
<p>Now we need to suck all the <code>e\src\jsrc\*.java</code> files into
- the project. Right click in the project windows and select "<code>Insert
+ the project. Right click in the Project pane and select "<code>Insert
files</code>". Navigate to the directory "<code>e\src\jsrc</code>",
select "subfolders", click on "Add All", and then
- click on "Ok". Wait while it adds all these files to your project.</p>
+ click on "Ok". Wait while it adds all these files to your project.
+ Once it's done, be sure to remember to save your project or Save All.</p>
<p>Finally, on the "<code>Project</code>" menu, select "<code>Run
in Debugger</code>". Hopefully, after everything successfully compiles,
you'll see an Elmer window. You are now running <i>Elmer</i> under the
1.2 +2 -2 e/doc/download/stl-0-8-9-t-1/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/download/stl-0-8-9-t-1/index.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.html 2001/09/03 02:08:58 1.1
+++ index.html 2001/09/14 01:36:17 1.2
@@ -33,9 +33,9 @@
<!-- #BeginEditable "Path" -->/ <a href="../index.html">download</a> <!-- #EndEditable --></td>
</tr>
<tr>
- <td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="../stl-0-8-9-s/index.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: E stl-0.8.9s Download and Install E" border="0"></a><!-- #EndEditable --></td>
+ <td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="../stl-0-8-9-t/index.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: E stl-0.8.9t Download and Install E" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><a href="windows-bin.html"><img src="../../images/first.gif" width="32" height="64" alt="1st child: E stl-0.8.9t.1: Installing on Windows" border="0"></a><!-- #EndEditable --></td>
- <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><img src="../../images/next-gray.gif" width="64" height="32"><!-- #EndEditable --></td>
+ <td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="../0-8-10alpha/index.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: E 0.8.10alpha Download and Install E" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
1.26 +12 -12 e/doc/elang/quick-ref.html
Index: quick-ref.html
===================================================================
RCS file: /cvs/e/doc/elang/quick-ref.html,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- quick-ref.html 2001/04/30 20:36:04 1.25
+++ quick-ref.html 2001/09/14 01:36:17 1.26
@@ -59,17 +59,17 @@
<ul>
<li><a href="#Simple">Simple Statements</a>: def, assign, print, add,
comment
- <li><a href="#Flow">Basic Flow</a>: if, while, for, try
+ <li><a href="#Flow">Basic Flow</a>: if, while, for, try
<li><a
href="#Modules">Modules</a>: Function, Singleton Object, Object Maker,
Delegation, Matching
<li><a href="#io">Text File I/O</a>
- <li><a href="#Windowing">Windowed Apps</a>
+ <li><a href="#Windowing">Windowed Apps</a>
<li><a
- href="#Structures">Data Structures</a>: Strings, ConstLists, ConstMaps,
- FlexLists, FlexMaps
+ href="#Structures">Data Structures</a>: Strings, ConstLists, ConstMaps,
+ FlexLists, FlexMaps
<li><a href="#Java">Java Interface</a>
- <li><a href="#Asynch">Asynch Sends</a>
+ <li><a href="#Asynch">Asynch Sends</a>
<li><a href="#Remote">Remote Comm</a> </li>
</ul>
<hr>
@@ -217,8 +217,8 @@
</tr>
<tr>
<td>
- <p>Text files are always normalized to use linefeed (<code>'\n'</code>)
- as end of line when read in to the program; the end of line is converted
+ <p>Text files are always normalized to use linefeed (<code>'\n'</code>)
+ as end of line when read in to the program; the end of line is converted
to native format upon being written out.</p>
<pre> def fileA := <file:/home/marcs/text.txt>
def fileB := <file: "/home/marcs/text.txt">
@@ -291,11 +291,11 @@
</tr>
</tbody>
</table>
- <p>Strings are ConstLists of <code>char</code> that have additional methods
+ <p>Strings are ConstLists of <code>char</code> that have additional methods
including Java string operators.<br>
- Flex structures respond to all Const messages except the comparison operators
+ Flex structures respond to all Const messages except the comparison operators
("<", <=", etc...).<br>
- All these structures have many methods not listed here.
+ All these structures have many methods not listed here.
<hr>
<p><a name=Java><!-- --></a><b>Java Interface</b>
<pre> def awt__uriGetter := <import:java.awt.*>
@@ -329,12 +329,12 @@
</tr>
<tr>
<td>
- <pre>def farCar := farCarMaker <- new("Mercedes")
+ <pre>def farCar := farCarMaker <- new("Mercedes")
Ref whenBroken(farCar, def lost(brokenRef) {
println("Lost connection to farCar")
})</pre>
</td>
- <td>
+ <td>
<pre>def [result, resolver] := PromiseMaker()
Ref whenResolved(result, def obs(answer) {
if (! (Ref isBroken(answer))) {
1.23 +6 -8 e/doc/elang/blocks/miranda.html
Index: miranda.html
===================================================================
RCS file: /cvs/e/doc/elang/blocks/miranda.html,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- miranda.html 2001/07/16 03:28:30 1.22
+++ miranda.html 2001/09/14 01:36:17 1.23
@@ -195,16 +195,14 @@
could catch Errors as well.</p>
</blockquote>
</li>
- <li><font color="#CC0000"><a name="getType"></a><b>getType / protocol</b></font>
- <blockquote>Currently, we have a placeholder Miranda Method, protocol,
- which is deprecated and will go away. Instead, we will have <code>getType</code>,
- which will return a Type object describing the protocol that this
- object responds to.
+ <li><a name="getType"></a><b>getAllegedType</b>
+ <blockquote><code>getAllegedType</code>, which will return a Type object
+ describing the protocol that this object alleges it responds to.
<p></p>
- <p>The Miranda behavior will be</p>
+ <p>The Miranda behavior is</p>
<p>
<blockquote>
- <pre>to getType() :Type {
+ <pre>to getAllegedType() :Type {
<font face="Times New Roman, Times, serif">/*not expressible in E*/</font>
}</pre>
</blockquote>
@@ -219,7 +217,7 @@
<p>
<blockquote>
<pre>to respondsTo(verb :String, arity :integer) :boolean {
- self getType() hasMethod(verb, arity)
+ self getAllegedType() hasMethod(verb, arity)
}</pre>
</blockquote>
<p></p>
1.34 +55 -55 e/doc/elang/concurrency/introducer.html
Index: introducer.html
===================================================================
RCS file: /cvs/e/doc/elang/concurrency/introducer.html,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- introducer.html 2001/05/09 05:00:41 1.33
+++ introducer.html 2001/09/14 01:36:17 1.34
@@ -6,7 +6,7 @@
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<!-- #BeginEditable "doctitle" -->
<TITLE>Introducing Remote Objects</TITLE>
-<!-- #EndEditable -->
+<!-- #EndEditable -->
<meta name="Author" content="Mark S. Miller">
<link rel=author rev=made href="mailto:markm@caplet.com" title="Mark S. Miller">
<META NAME="description" CONTENT="E: Cryptographic Capabilities for Distributed Smart Contracting">
@@ -18,30 +18,30 @@
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFEEDD" LINK="#0000FF" VLINK="#800080">
-<P>
+<P>
<TABLE BORDER="0" width="100%">
- <TR VALIGN="TOP">
+ <TR VALIGN="TOP">
<TD WIDTH="10%"> </TD>
- <TD>
- <P>
+ <TD>
+ <P>
<TABLE BORDER="0" WIDTH="100%">
- <TR>
- <TD ALIGN="LEFT" valign="top">
+ <TR>
+ <TD ALIGN="LEFT" valign="top">
<table cellpadding="2">
- <tr>
- <td valign="top" align="left" colspan="3"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a>
+ <tr>
+ <td valign="top" align="left" colspan="3"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a>
<!-- #BeginEditable "Path" -->/ <a href="../index.html">elang</a> / <a href="index.html">concurrency</a> <!-- #EndEditable --></td>
</tr>
- <tr>
+ <tr>
<td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><img src="../../images/prev-gray.gif" width="64" height="32"><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><!-- #EndEditable --></td>
<td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="race.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: Concurrency Races" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
- <TD ALIGN="RIGHT">
+ <TD ALIGN="RIGHT">
<P ALIGN="RIGHT"><FONT SIZE="7"><!-- #BeginEditable "BigTitle" --><FONT SIZE="7"><b>Introducing<br>
- Remote Objects</b></FONT><!-- #EndEditable --></FONT>
+ Remote Objects</b></FONT><!-- #EndEditable --></FONT>
</TD>
</TR>
</TABLE>
@@ -55,11 +55,11 @@
# value: <Off The Air>
</pre>
</blockquote>
- <p>When you type this in, you should see either "<code>Off The Air</code>"
- as above, "<code>On The Air</code>", or "<code>null</code>".
- If you see "<code>null</code>", you aren't using full E, but
- rather a space-local subset of E. As explained on the <a href="../../download/0-8-9/index.html">download
- page</a>, the <i>space-local subset</i> is the subset of E supporting
+ <p>When you type this in, you should see either "<code>Off The Air</code>"
+ as above, "<code>On The Air</code>", or "<code>null</code>".
+ If you see "<code>null</code>", you aren't using full E, but
+ rather a space-local subset of E. As explained on the <a href="../../download/0-8-9/index.html">download
+ page</a>, the <i>space-local subset</i> is the subset of E supporting
only conventional non-distributed programming. </p>
<p>Normally you'll see "<code>Off The Air</code>", which means
your E should be capable of distributed object programming, but it hasn't
@@ -76,13 +76,13 @@
<pre>? introducer
# value: <On The Air [3DES_SDH_M]></pre>
</blockquote>
- <p><i>(The list in square brackets is the set of protocols that your E process
- is willing to speak. If you see "</i><code>[AUTH_SDH_M, NONE_SDH_M]</code><i>"
- instead of "</i><code>[3DES_SDH_M]</code><i>", you are running
- daffE rather than E, and your process will only be able to communicate
- with other daffE processes. As explained on the <a href="../../download/0-8-9/index.html">download
- page</a>, daffE was an insecure variant of E, built domestically and crypto-crippled
- to appease export bureaucrats. Except under peculiar circomstances, you
+ <p><i>(The list in square brackets is the set of protocols that your E process
+ is willing to speak. If you see "</i><code>[AUTH_SDH_M, NONE_SDH_M]</code><i>"
+ instead of "</i><code>[3DES_SDH_M]</code><i>", you are running
+ daffE rather than E, and your process will only be able to communicate
+ with other daffE processes. As explained on the <a href="../../download/0-8-9/index.html">download
+ page</a>, daffE was an insecure variant of E, built domestically and crypto-crippled
+ to appease export bureaucrats. Except under peculiar circomstances, you
should always use E instead.)</i></p>
<p>Since we are about to demonstrate distributed object programming, you
need to bring up another E processes and go through the above steps again.
@@ -206,13 +206,13 @@
</blockquote>
</blockquote>
</blockquote>
- <p>Alternatively, if you have windows to both processes in front of you,
- you can just copy and paste from one to the other. Or you could email
- the uri to an account you can read on the other machine -- whatever works.
- This is the act of <i>initial introduction</i>. In situations where security
- is important you must convey this string from one process to the other
- in a secure manner, such as in a PGP-encrypted email message. Assuming
- this has been done, E ensures that all further communication between these
+ <p>Alternatively, if you have windows to both processes in front of you,
+ you can just copy and paste from one to the other. Or you could email
+ the uri to an account you can read on the other machine -- whatever works.
+ This is the act of <i>initial introduction</i>. In situations where security
+ is important you must convey this string from one process to the other
+ in a secure manner, such as in a PGP-encrypted email message. Assuming
+ this has been done, E ensures that all further communication between these
processes remains secure. </p>
<p align="center"><img src="images/uri-intro.gif" width="308" height="312"></p>
<p>This act of introduction is another example of the <a href="../../elib/capability/ode/index.html">Granovetter
@@ -281,7 +281,7 @@
<blockquote>
<blockquote>
<blockquote>
- <pre><font color="#008800">? def val := remote <- incr
+ <pre><font color="#008800">? def val := remote <- incr
# value: <Deferred ref></font></pre>
</blockquote>
</blockquote>
@@ -324,53 +324,53 @@
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>
- <TR VALIGN="TOP">
+ <TR VALIGN="TOP">
<TD WIDTH="10%"> </TD>
- <TD>
+ <TD>
<hr>
- <div align="center">
+ <div align="center">
<table cellpadding="4" cellspacing="0">
- <tr>
- <td>
+ <tr>
+ <td>
<div align="left"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a></div>
</td>
- <td>
+ <td>
<table border="3" align="center" cellpadding="6" cellspacing="3">
- <tr>
- <td>
- <div align="center"><font size="-1"><a href="../../elib/index.html">ELib</a>
- <a href="../index.html">E Language</a>
- <a href="../../smart-contracts/index.html">Smart
- Contracts</a> <a href="../../related.html">Related</a>
+ <tr>
+ <td>
+ <div align="center"><font size="-1"><a href="../../elib/index.html">ELib</a>
+ <a href="../index.html">E Language</a>
+ <a href="../../smart-contracts/index.html">Smart
+ Contracts</a> <a href="../../related.html">Related</a>
</font></div>
</td>
</tr>
- <tr>
- <td>
- <div align="center"><font size="-1"><a href="../../download/index.html">Download</a>
- <a href="../../javadoc/index.html">API</a>
- <a href="http://www.eros-os.org/pipermail/e-lang/">Mail
+ <tr>
+ <td>
+ <div align="center"><font size="-1"><a href="../../download/index.html">Download</a>
+ <a href="../../javadoc/index.html">API</a>
+ <a href="http://www.eros-os.org/pipermail/e-lang/">Mail
Archive</a> <a href="../../donate.html">Donations</a></font></div>
</td>
</tr>
</table>
</td>
</tr>
- </table>
+ </table>
<table width="100%" border="0" cellspacing="0" cellpadding="4">
- <tr>
+ <tr>
<td><i><a href="mailto:webmaster@erights.org">webmaster@erights.org</a></i><br>
- or <a href="http://www.blindpay.com/crit-me-now.cgi"><img src="../../images/cmn.gif" width="98" height="21" border="0" align="middle" alt="Annotate this page"></a>
+ or <a href="http://www.blindpay.com/crit-me-now.cgi"><img src="../../images/cmn.gif" width="98" height="21" border="0" align="middle" alt="Annotate this page"></a>
</td>
- <td>
- <div align="right">
+ <td>
+ <div align="right">
<p><a href="http://www.privacy.org/ipc/"><img src="../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://mirrors.yahoo.com/eff/blueribbon.html"><img src="../../images/ribbon.gif" width="18" height="30"
alt="Blue Ribbon Campaign" border="0"></a></p>
</div>
</td>
</tr>
</table>
-
+
</div>
</TD>
<TD WIDTH="10%" valign="bottom"> </TD>
1.30 +58 -36 e/doc/elang/concurrency/race.html
Index: race.html
===================================================================
RCS file: /cvs/e/doc/elang/concurrency/race.html,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- race.html 2001/05/07 08:29:24 1.29
+++ race.html 2001/09/14 01:36:17 1.30
@@ -56,7 +56,7 @@
> def [result, resolver] := PromiseMaker()
> def done := false
> for prom in promises {
-> E <a href="../blocks/miranda.html#whenMoreResolved">whenResolved</a>(prom, def observer(val) {
+> Ref <a href="../blocks/miranda.html#whenMoreResolved">whenResolved</a>(prom, def observer(val) {
> if (!done) {
> resolver resolve(val)
> done := true
@@ -70,17 +70,17 @@
</blockquote>
<p> In this test, <code>c</code> is the winner of racing <code>a</code>
and <code>b</code>:</p>
- <blockquote>
+ <blockquote>
<pre>? def [a,ar] := PromiseMaker()
-# value: [Deferred promise, Unresolved Resolver]
+# value: [<Eventual ref>, <Open Resolver>]
? def [b,br] := PromiseMaker()
-# value: [Deferred promise, Unresolved Resolver]</pre>
+# value: [<Eventual ref>, <Open Resolver>]</pre>
<pre>? def c := race([a, b])
-# value: Deferred promise</pre>
+# value: <Eventual ref></pre>
<pre>? c
-# value: Deferred promise</pre>
+# value: <Eventual ref></pre>
<pre>? ar resolve(3)
? c
# value: 3</pre>
@@ -100,24 +100,60 @@
"<code>once(<i>verb</i>, <i>target</i>)</code>" is a generalization
which will forward no more than one "<code><i>verb</i></code>"
message to the <i><code>target</code></i>.</p>
- <p>This abstraction is intended to be secure, but isn't yet, because all
- the Miranda methods are forwarded to the target, including "<code>yourself</code>",
- which the caller can use to obtain the target. This should be simple to
- fix.</p>
- <blockquote>
+ <p>For the <a href="../blocks/miranda.html">Miranda Methods</a>, the result
+ of the <code>once</code> (the forwarder below) must make good decisions
+ about whether to override them and possibly forward them, or not override
+ them and let them default to methods on the forwarder. For non-Miranda
+ methods other than the suppressed method, they are simply forwarded.</p>
+ <blockquote>
<pre>? def once {
> to (verb, target) :any {
> def used := false
-> def forwarder match [verb2, args] {
-> if (verb == verb2) {
-> if (used) {
-> throw("used up")
+> def forwarder {
+> <font face="Times New Roman, Times, serif"># use the Miranda order/3, though it shouldn't matter</font>
+>
+> <font face="Times New Roman, Times, serif"># use the Miranda optMeta/1 to protect the target</font>
+>
+> <font face="Times New Roman, Times, serif"># forward getAllegedType/0, though one could argue that, once</font>
+> <font face="Times New Roman, Times, serif"># used up, the type shouldn't include the supressed verb</font>
+> to getAllegedType() :any {
+> target getAllegedType()
+> }
+>
+> <font face="Times New Roman, Times, serif"># forward respondsTo, but supress verb. One could argue that respondsTo</font>
+> <font face="Times New Roman, Times, serif"># and getAllegedType() should be consistent with each other.</font>
+> to respondsTo(verb2, arity) :boolean {
+> verb != verb2 && target respondsTo(verb2, arity)
+> }
+>
+> <font face="Times New Roman, Times, serif"># forward printOn/1</font>
+> to printOn(out) { target printOn(out) }
+>
+> <font face="Times New Roman, Times, serif"># forward reactToLostClient</font>
+> to reactToLostClient(problem) {
+> target reactToLostClient(problem)
+> }
+>
+> <font face="Times New Roman, Times, serif"># use the Miranda whenMoreResolved/1 to protect the target</font>
+>
+> <font face="Times New Roman, Times, serif"># use the Miranda whenBroken/1 to protect the target</font>
+>
+> <font face="Times New Roman, Times, serif"># use the Miranda yourself/0 to protect the target</font>
+>
+> <font face="Times New Roman, Times, serif"># handle all other messages</font>
+> match [verb2, args] {
+> if (verb == verb2) {
+> if (used) {
+> throw("used up")
+> }
+> used := true
> }
-> used := true
+> E call(target, verb2, args)
> }
-> E call(target, verb2, args)
> }
> }
+>
+> <font face="Times New Roman, Times, serif"># default to suppressing "run"</font>
> to (target) :any { once("run", target) }
> }
# value: <once></pre>
@@ -150,7 +186,7 @@
? def asynchAnd(bools) :any {
> def [result, resolver] := PromiseMaker()
> def done := false
-> def numUntrue := bools size
+> def numUntrue := bools size()
> def resolve(val) {
> if (!done) {
> resolver resolve(val)
@@ -195,26 +231,12 @@
# value: false</pre>
<pre>? z
# value: false</pre>
- </blockquote>
- <p> Imports for being able to delay activity</p>
- <blockquote>
- <pre>
-? def TimerMaker := <import:org.erights.e.extern.timer.Timer>
-# value: <import:org.erights.e.extern.timer.Timer></pre>
- <pre>? def TheTimer := TimerMaker theTimer
-# value: org.erights.e.extern.timer.Timer@1be8d2</pre>
</blockquote>
- <p> "timeBomb(5000)" returns a promise that will become broken
- in 5000 milliseconds, ie, 5 seconds.</p>
+ <p> "<code>timeBomb(5000)</code>" returns a promise that will
+ become broken in 5000 milliseconds, ie, 5 seconds.</p>
<blockquote>
<pre>? def timeBomb(millis) :any {
-> def [result, resolver] := PromiseMaker()
-> TheTimer after(millis, def trigger noticeTimeout {
-> try { throw("time's up") } catch ex {
-> resolver smash(ex)
-> }
-> })
-> result
+> timer whenPast(millis, thunk{ throw("time's up") })
> }
# value: <timeBomb></pre>
</blockquote>
@@ -237,7 +259,7 @@
sure to have a resolved answer within around 5 seconds even if Bob is
wedged:</p>
<blockquote>
- <pre> def answer := race(bob <- gimmeInteger, timeBomb(5000))</pre>
+ <pre> def answer := race(bob <- gimmeInteger(), timeBomb(5000))</pre>
</blockquote>
<p></p>
<P ALIGN="left">
1.8 +1 -2 e/doc/elang/tools/updoc.html
Index: updoc.html
===================================================================
RCS file: /cvs/e/doc/elang/tools/updoc.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- updoc.html 2001/07/16 19:51:28 1.7
+++ updoc.html 2001/09/14 01:36:17 1.8
@@ -28,8 +28,7 @@
<table cellpadding="2">
<tr>
<td valign="top" align="left" colspan="3"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a>
- <!-- #BeginEditable "Path" --> / <a href="../index.html">elang</a> / <a href="index.html">tools</a>
- <!-- #EndEditable --></td>
+ <!-- #BeginEditable "Path" -->/ <a href="../index.html">elang</a> / <a href="index.html">tools</a> <!-- #EndEditable --></td>
</tr>
<tr>
<td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><img src="../../images/prev-gray.gif" width="64" height="32"><!-- #EndEditable --></td>
1.14 +217 -217 e/doc/elib/concurrency/msg-passing.html
Index: msg-passing.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/msg-passing.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- msg-passing.html 2001/05/09 05:00:41 1.13
+++ msg-passing.html 2001/09/14 01:36:17 1.14
@@ -6,7 +6,7 @@
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<!-- #BeginEditable "doctitle" -->
<TITLE>Message Passing</TITLE>
-<!-- #EndEditable -->
+<!-- #EndEditable -->
<meta name="Author" content="Mark S. Miller">
<link rel=author rev=made href="mailto:markm@caplet.com" title="Mark S. Miller">
<META NAME="description" CONTENT="E: Cryptographic Capabilities for Distributed Smart Contracting">
@@ -18,88 +18,88 @@
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFEEDD" LINK="#0000FF" VLINK="#800080">
-<P>
+<P>
<TABLE BORDER="0" width="100%">
- <TR VALIGN="TOP">
+ <TR VALIGN="TOP">
<TD WIDTH="10%"> </TD>
- <TD>
- <P>
+ <TD>
+ <P>
<TABLE BORDER="0" WIDTH="100%">
- <TR>
- <TD ALIGN="LEFT" valign="top">
+ <TR>
+ <TD ALIGN="LEFT" valign="top">
<table cellpadding="2">
- <tr>
- <td valign="top" align="left" colspan="3"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a>
+ <tr>
+ <td valign="top" align="left" colspan="3"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a>
<!-- #BeginEditable "Path" -->/ <a href="../index.html">elib</a> / <a href="index.html">concurrency</a> <!-- #EndEditable --></td>
</tr>
- <tr>
+ <tr>
<td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="refmech.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: Reference Mechanics" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><!-- #EndEditable --></td>
<td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="turns.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: Game Turns as MicroTransactions" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
- <TD ALIGN="RIGHT">
+ <TD ALIGN="RIGHT">
<P ALIGN="RIGHT"><FONT SIZE="7"><!-- #BeginEditable "BigTitle" --><b>Message
- Passing</b><!-- #EndEditable --></FONT>
+ Passing</b><!-- #EndEditable --></FONT>
</TD>
</TR>
</TABLE>
<hr>
- <!-- #BeginEditable "LongBody" -->
+ <!-- #BeginEditable "LongBody" -->
<h1>Taxonomy of Messaging Primitives</h1>
<p>E has the following message passing primitives, </p>
- <p align="left">
+ <p align="left">
<ul>
- <li> i) the synchronous <i>immediate</i> <b><a href="#call">call</a></b>
+ <li> i) the synchronous <i>immediate</i> <b><a href="#call">call</a></b>
(*)</li>
- <li>ii) the synchronous <b><a href="#outcome">outcome</a></b>, which has
- three sub-cases
+ <li>ii) the synchronous <b><a href="#outcome">outcome</a></b>, which has
+ three sub-cases
<ol>
<li><b><a href="#success">Success</a></b>: evaluation to a result</li>
<li><b><a href="#failure">Failure</a></b>: throw()ing a problem report</li>
<li><b><a href="#escape">Escape</a></b>: like break() or continue()</li>
</ol>
</li>
- <li>iii) the asynchronous <i>eventual</i> ("<-") <b><a href="#send">send</a></b>,
- where an outcome report
+ <li>iii) the asynchronous <i>eventual</i> ("<-") <b><a href="#send">send</a></b>,
+ where an outcome report
<ol>
<li> is not expected -- the <b><a href="#sendOnly">sendOnly</a></b>.</li>
- <li> may be expected -- the <a href="#pipe-send"><b>pipelined send</b></a>
+ <li> may be expected -- the <a href="#pipe-send"><b>pipelined send</b></a>
(*)</li>
</ol>
</li>
</ul>
- <p>For all of these, a message is conveyed to an individual recipient, and
- contains at least a verb (a String) and a tuple of arguments. A message
- often represents a request (identified by the verb and the number of arguments,
- but not their types), so the recipient generally knows why it is receiving
- new authority. This facilitates the programming of non-confusable <a href="../capability/deputy.html">deputies</a>.
- For the cases marked with (*), the message additionally contains a <i>continuation</i>
- -- the object to which the outcome of performing the request should be
+ <p>For all of these, a message is conveyed to an individual recipient, and
+ contains at least a verb (a String) and a tuple of arguments. A message
+ often represents a request (identified by the verb and the number of arguments,
+ but not their types), so the recipient generally knows why it is receiving
+ new authority. This facilitates the programming of non-confusable <a href="../capability/deputy.html">deputies</a>.
+ For the cases marked with (*), the message additionally contains a <i>continuation</i>
+ -- the object to which the outcome of performing the request should be
reported.</p>
- <p align="left"><img src="images/call.gif" width="178" height="215" align="right">E
- computation only occurs within a stack frame -- shown as a lightning bolt
- within an object. A stack frame happens when an object receives a call
- or send/sendOnly. Recall that an object is an instance of an object expression,
- and combines the behavior this expression describes with the state from
- its instantiating context (the scope in which the object expression was
- evaluated). Similarly, a stack frame can be seen as an instance of the
- method or matcher corresponding to the received message, and combines
- the described behavior with state as well. The stack frame’s state is
- the object’s state plus the state resulting from matching the incoming
- message with the head of the method or matcher. During its execution,
- a stack frame can accumulate more state by defining new variables.
- <p align="left">Since all computation happens only within stack frames,
- all messages are emitted only from stack frames. When object-granularity
- analysis suffices, as it often does for security reasoning, we often skip
- illustrating the stack frames, as in the <a href="../capability/ode/index.html">Granovetter
- Diagram</a>.
+ <p align="left"><img src="images/call.gif" width="178" height="215" align="right">E
+ computation only occurs within a stack frame -- shown as a lightning bolt
+ within an object. A stack frame happens when an object receives a call
+ or send/sendOnly. Recall that an object is an instance of an object expression,
+ and combines the behavior this expression describes with the state from
+ its instantiating context (the scope in which the object expression was
+ evaluated). Similarly, a stack frame can be seen as an instance of the
+ method or matcher corresponding to the received message, and combines
+ the described behavior with state as well. The stack frame’s state is
+ the object’s state plus the state resulting from matching the incoming
+ message with the head of the method or matcher. During its execution,
+ a stack frame can accumulate more state by defining new variables.
+ <p align="left">Since all computation happens only within stack frames,
+ all messages are emitted only from stack frames. When object-granularity
+ analysis suffices, as it often does for security reasoning, we often skip
+ illustrating the stack frames, as in the <a href="../capability/ode/index.html">Granovetter
+ Diagram</a>.
<h2 align="left"><a name="call"></a>i) The Immediate Call</h2>
- <p align="left">The above diagram and the following code illustrates Alice
- synchronously calling Bob:
- <p align="left">
- <blockquote>
+ <p align="left">The above diagram and the following code illustrates Alice
+ synchronously calling Bob:
+ <p align="left">
+ <blockquote>
<pre>def alice {
to msg1() {
def result := bob msg2(carol)
@@ -107,51 +107,51 @@
}
}</pre>
</blockquote>
- <p align="left">The call is only allowed if the reference to the recipient
- is <font color="#009900"><b>NEAR</b></font>. Otherwise, the attempt to
- call instead throws an appropriate exception.
- <p align="left"><img src="images/stackchain.gif" width="216" height="265" align="right">Besides
- the components shared by all messages, a synchronous call contains an
- additional special argument -- the continuation -- that points at the
- caller’s stack frame. The call also turns the calling stack frame from
- active to suspended. Computation in fact occurs only in active stack frames.
- A suspended stack frame must be pointed to by exactly one special continuation
- argument. An active stack frame is not pointed at. There can be at most
- one active stack frame in a Vat, and all stack frames are in a linear
- chain between it and a <i>top stack frame</i> -- a stack frame directly
- spawned to service a pending delivery. (When between turns, there are
- no stack frames, as happens when the queue is empty, or when a Vat is
- sitting on disk waiting to be revived from checkpoint.)
- <p align="left">The message passed in a call need not be allocated as a
- separate object, as no time passes between departing from the caller and
- arriving at the callee. Rather, the act of calling simultaneously creates
- the receiving stack frame in the callee. All stack frames contain the
- special continuation argument from the message they received, but -- unlike
- the other arguments received from the message -- the continuation is not
- explicitly accessible to the program.
- <p align="left">See also the <a href="../../elang/kernel/CallExpr.html">Kernel-E
- Call Expression</a>.
- <h2 align="left"><a name="outcome"></a>ii) Synchronous Outcome of Stack-Frame
+ <p align="left">The call is only allowed if the reference to the recipient
+ is <font color="#009900"><b>NEAR</b></font>. Otherwise, the attempt to
+ call instead throws an appropriate exception.
+ <p align="left"><img src="images/stackchain.gif" width="216" height="265" align="right">Besides
+ the components shared by all messages, a synchronous call contains an
+ additional special argument -- the continuation -- that points at the
+ caller’s stack frame. The call also turns the calling stack frame from
+ active to suspended. Computation in fact occurs only in active stack frames.
+ A suspended stack frame must be pointed to by exactly one special continuation
+ argument. An active stack frame is not pointed at. There can be at most
+ one active stack frame in a Vat, and all stack frames are in a linear
+ chain between it and a <i>top stack frame</i> -- a stack frame directly
+ spawned to service a pending delivery. (When between turns, there are
+ no stack frames, as happens when the queue is empty, or when a Vat is
+ sitting on disk waiting to be revived from checkpoint.)
+ <p align="left">The message passed in a call need not be allocated as a
+ separate object, as no time passes between departing from the caller and
+ arriving at the callee. Rather, the act of calling simultaneously creates
+ the receiving stack frame in the callee. All stack frames contain the
+ special continuation argument from the message they received, but -- unlike
+ the other arguments received from the message -- the continuation is not
+ explicitly accessible to the program.
+ <p align="left">See also the <a href="../../elang/kernel/CallExpr.html">Kernel-E
+ Call Expression</a>.
+ <h2 align="left"><a name="outcome"></a>ii) Synchronous Outcome of Stack-Frame
Completion</h2>
- <p align="left">The callee can use the continuation only by completing the
- execution of its stack frame, thereby also causing it to be discarded.
- The nature of this completion implicitly passes an outcome message to
- the continuation. Unlike calls and returns, outcome messages have no hidden
- arguments. There are three kinds of outcome, each represented with its
- own outcome message. When the continuation is a stack frame, these outcome
- messages are only for expository purposes, as neither the caller nor callee
- can deal with them explicitly. We choose describe these as messages so
- we can understand all transfer of authority in terms of the <a href="../capability/ode/index.html">Granovetter
- diagram</a>.
- <p align="left">
+ <p align="left">The callee can use the continuation only by completing the
+ execution of its stack frame, thereby also causing it to be discarded.
+ The nature of this completion implicitly passes an outcome message to
+ the continuation. Unlike calls and returns, outcome messages have no hidden
+ arguments. There are three kinds of outcome, each represented with its
+ own outcome message. When the continuation is a stack frame, these outcome
+ messages are only for expository purposes, as neither the caller nor callee
+ can deal with them explicitly. We choose describe these as messages so
+ we can understand all transfer of authority in terms of the <a href="../capability/ode/index.html">Granovetter
+ diagram</a>.
+ <p align="left">
<ol>
- <li><a name="success"></a><img src="images/completion.gif" width="149" height="215" align="right"><b>Success</b>,
- corresponding to “falling off the end” and represented by passing a
- “<code>resolve(result)</code>” message to the continuation. The diagram
- and the following code illustrate Bob returning Dana as a successful
- result to Alice:
- <p align="left">
- <blockquote>
+ <li><a name="success"></a><img src="images/completion.gif" width="149" height="215" align="right"><b>Success</b>,
+ corresponding to “falling off the end” and represented by passing a
+ “<code>resolve(result)</code>” message to the continuation. The diagram
+ and the following code illustrate Bob returning Dana as a successful
+ result to Alice:
+ <p align="left">
+ <blockquote>
<pre>def bob {
to msg2(carol) {
... <font face="Times New Roman, Times, serif">//whatever
@@ -159,16 +159,16 @@
}
}</pre>
</blockquote>
- <p>In this case, the call expression with which Alice called Bob evaluates
- to this result, and the stack frame in Alice suspended on this call
+ <p>In this case, the call expression with which Alice called Bob evaluates
+ to this result, and the stack frame in Alice suspended on this call
expression continues from this point.</p>
- <li>
- <p align="left"><b><a name="failure"></a>Failure</b>, as a result of
- execution of a “<code>throw(problem)</code>” and represented by passing
- a “<code>smash(problem)</code>” message to the continuation. The following
- code:
- <p align="left">
- <blockquote>
+ <li>
+ <p align="left"><b><a name="failure"></a>Failure</b>, as a result of
+ execution of a “<code>throw(problem)</code>” and represented by passing
+ a “<code>smash(problem)</code>” message to the continuation. The following
+ code:
+ <p align="left">
+ <blockquote>
<pre>def bob {
to msg2(carol) {
... <font face="Times New Roman, Times, serif">//whatever</font>
@@ -177,120 +177,120 @@
</font> }
}</pre>
</blockquote>
- <p align="left">can be illustrated with the same diagram, but the verb
- is now “<code>smash</code>” instead of “<code>resolve</code>”. Execution
- within Alice's stack frame now skips to the closest enclosing <a href="../../elang/kernel/CatchExpr.html">try-catch</a>
- or <a href="../../elang/kernel/FinallyExpr.html">try-finally</a> expression.
- If these are none, then Alice's stack frame completes in failure as
- well, and the <code>smash(problem)</code> message gets forwarded to
- Alice's stack frame's continuation, if any.
- <p>
- <li>
- <p align="left"><b><a name="escape"></a>Escape</b>, corresponding to
- invoking a non-disabled ejector (as created by an <code><a href="../../elang/kernel/EscapeExpr.html">escape</a></code><a href="../../elang/kernel/EscapeExpr.html">
- expression</a>), and represented by passing “<code>eject(ejection)</code>”
- to the continuation. (** need explanation of Ejectors and ejections)
- <p>
+ <p align="left">can be illustrated with the same diagram, but the verb
+ is now “<code>smash</code>” instead of “<code>resolve</code>”. Execution
+ within Alice's stack frame now skips to the closest enclosing <a href="../../elang/kernel/CatchExpr.html">try-catch</a>
+ or <a href="../../elang/kernel/FinallyExpr.html">try-finally</a> expression.
+ If these are none, then Alice's stack frame completes in failure as
+ well, and the <code>smash(problem)</code> message gets forwarded to
+ Alice's stack frame's continuation, if any.
+ <p>
+ <li>
+ <p align="left"><b><a name="escape"></a>Escape</b>, corresponding to
+ invoking a non-disabled ejector (as created by an <code><a href="../../elang/kernel/EscapeExpr.html">escape</a></code><a href="../../elang/kernel/EscapeExpr.html">
+ expression</a>), and represented by passing “<code>eject(ejection)</code>”
+ to the continuation. (** need explanation of Ejectors and ejections)
+ <p>
</li>
</ol>
- <p align="left">Both Failure and Escape are forms of non-local exit.
- <p align="left">Other than by invoking its continuation, the callee cannot
- stop executing, even on I/O. I/O operations that would normally block
- are instead handled by requesting notification be delivered -- by sending
- -- to a designated object. As a result, E is strongly deadlock-free (but
- is still subject to live-lock by infinite loops).
+ <p align="left">Both Failure and Escape are forms of non-local exit.
+ <p align="left">Other than by invoking its continuation, the callee cannot
+ stop executing, even on I/O. I/O operations that would normally block
+ are instead handled by requesting notification be delivered -- by sending
+ -- to a designated object. As a result, E is strongly deadlock-free (but
+ is still subject to live-lock by infinite loops).
<h2 align="left"><a name="send"></a>iii) The Eventual Send</h2>
<div align="center"></div>
- <p align="left">Returning to the human world for a moment, as I schedule
- my time, I find I mainly use two patterns: If in performing task X I find
- I’m blocked on the outcome of a subtask Y, I put the X aside for awhile,
- work on Y until it's done, and then continue with X. This corresponds
- to synchronous <i>do it immediately</i>, or call-return scheduling as
- explained above. The other pattern is that, in performing task X, I come
- to realize another task Y I need to perform, but I don’t need to do Y
- now. To ensure I don’t forget Y, I jot a note on a to-do list, and then
- continue with my present task.
- <p align="left">This latter pattern corresponds to asynchronous<i> do it
- eventually</i> scheduling, as supported by the eventual send. A send is
- written like a synchronous call, but with a “<code><-</code>”, the <i>eventually</i>
- operator, between the recipient and the message. A record that this message
- must be delivered to this recipient is duly noted, but then the original
- turn continues about its business unaffected.
- <p align="left"><img src="images/sendOnly.gif" width="178" height="215" align="right">There
- are two forms of eventual send, written the same way, but distinguished
- by whether the value of send expression appears to be needed.
- <p align="left">
- <p>
+ <p align="left">Returning to the human world for a moment, as I schedule
+ my time, I find I mainly use two patterns: If in performing task X I find
+ I’m blocked on the outcome of a subtask Y, I put the X aside for awhile,
+ work on Y until it's done, and then continue with X. This corresponds
+ to synchronous <i>do it immediately</i>, or call-return scheduling as
+ explained above. The other pattern is that, in performing task X, I come
+ to realize another task Y I need to perform, but I don’t need to do Y
+ now. To ensure I don’t forget Y, I jot a note on a to-do list, and then
+ continue with my present task.
+ <p align="left">This latter pattern corresponds to asynchronous<i> do it
+ eventually</i> scheduling, as supported by the eventual send. A send is
+ written like a synchronous call, but with a “<code><-</code>”, the <i>eventually</i>
+ operator, between the recipient and the message. A record that this message
+ must be delivered to this recipient is duly noted, but then the original
+ turn continues about its business unaffected.
+ <p align="left"><img src="images/sendOnly.gif" width="178" height="215" align="right">There
+ are two forms of eventual send, written the same way, but distinguished
+ by whether the value of send expression appears to be needed.
+ <p align="left">
+ <p>
<ol>
- <li>
- <p><a name="sendOnly"></a><b>sendOnly</b>. When a send expression appears
- in a context where it is statically apparent that the value of the
+ <li>
+ <p><a name="sendOnly"></a><b>sendOnly</b>. When a send expression appears
+ in a context where it is statically apparent that the value of the
send expression will be unused, such as to the left of a semi-colon:</p>
- <blockquote>
- <pre>bob <- foo(carol); ...</pre>
+ <blockquote>
+ <pre>bob <- foo(carol); ...</pre>
</blockquote>
- <p>then the message is a pure one-way message containing only the verb
- ("foo") and a list of the explicit arguments ([carol]),
- just as shown in the basic Granovetter diagram. The only feedback
- Alice can get from the performance of the message is that which she
- explicitly arranges for. When Bob finishes processing the message,
+ <p>then the message is a pure one-way message containing only the verb
+ ("foo") and a list of the explicit arguments ([carol]),
+ just as shown in the basic Granovetter diagram. The only feedback
+ Alice can get from the performance of the message is that which she
+ explicitly arranges for. When Bob finishes processing the message,
he reports the outcome of the turn to no one.</p>
</li>
- <li>
- <p><i><a name="pipe-send"></a></i><b>The pipelined send</b>. When a
- send expression appears in a context where it is not statically apparent
- that the value of the send expression will be unused, ie, where static
- analysis does not rule out that the value may be used, such as on
+ <li>
+ <p><i><a name="pipe-send"></a></i><b>The pipelined send</b>. When a
+ send expression appears in a context where it is not statically apparent
+ that the value of the send expression will be unused, ie, where static
+ analysis does not rule out that the value may be used, such as on
the right side of a def:</p>
- <blockquote>
- <pre>def promise := bob <- foo(carol); </pre>
+ <blockquote>
+ <pre>def promise := bob <- foo(carol); </pre>
</blockquote>
- <p><i><img src="images/send.gif" width="178" height="215" align="right"></i>then,
- like the immediate call, the message additionally contains a continuation.
- As with the call, when Bob finishes processing the message, the outcome
- is reported to the continuation. Unlike a call, the continuation is
- not a stack frame but the <a href="../../javadoc/org/erights/e/elib/ref/Resolver.html">Resolver</a>
- of a promise. This is the arrowhead with the gray halo shown in continuation-position
- in the message. Since the outcome to be reported is the outcome of
- an eventual send, it is the outcome of a <i>top-level</i> stack frame,
+ <p><i><img src="images/send.gif" width="178" height="215" align="right"></i>then,
+ like the immediate call, the message additionally contains a continuation.
+ As with the call, when Bob finishes processing the message, the outcome
+ is reported to the continuation. Unlike a call, the continuation is
+ not a stack frame but the <a href="../../javadoc/org/erights/e/elib/ref/Resolver.html">Resolver</a>
+ of a promise. This is the arrowhead with the gray halo shown in continuation-position
+ in the message. Since the outcome to be reported is the outcome of
+ an eventual send, it is the outcome of a <i>top-level</i> stack frame,
which is to say, the outcome of a turn as a whole.</p>
</li>
</ol>
<h2>Turning Control-Flow into Semi-Data-Flow</h2>
- <p>Since Ejectors are only dynamic in extent -- they only remain valid until
- their spawning escape expression completes -- the outcome of a turn cannot
- be an escape, only success or failure. Therefore, the Resolver only needs
- to respond to "<code>resolve(result)</code>" and "<code>smash(problem)</code>".
- In the first case, the promise becomes equivalent to <code>result</code>.
- In the second, the promise becomes broken, and problem is reported as
+ <p>Since Ejectors are only dynamic in extent -- they only remain valid until
+ their spawning escape expression completes -- the outcome of a turn cannot
+ be an escape, only success or failure. Therefore, the Resolver only needs
+ to respond to "<code>resolve(result)</code>" and "<code>smash(problem)</code>".
+ In the first case, the promise becomes equivalent to <code>result</code>.
+ In the second, the promise becomes broken, and problem is reported as
the reason. </p>
- <p>Assume that <code>brokenRef</code> is a reference broken with <code>problem</code>.
- Note that a stack-frame as continuation reacts differently to "resolve(brokenRef)"
- and "smash(problem)" -- the first causes successful evaluation
- to brokenRef while the second causes exceptional flow of control. On the
- other hand, A Resolver reacts to these two messages identically. As a
- result, Alice cannot distinguish between these two ways Bob may have reported
+ <p>Assume that <code>brokenRef</code> is a reference broken with <code>problem</code>.
+ Note that a stack-frame as continuation reacts differently to "resolve(brokenRef)"
+ and "smash(problem)" -- the first causes successful evaluation
+ to brokenRef while the second causes exceptional flow of control. On the
+ other hand, A Resolver reacts to these two messages identically. As a
+ result, Alice cannot distinguish between these two ways Bob may have reported
a problematic outcome.</p>
- <p align="left">All messages sent on a reference arrow move towards the
- arrowhead in order to eventually be delivered to the object pointed at.
- Messages sent on an unresolved promise do likewise, but wait behind the
- unbound arrowhead until the promise is resolved. Once the promise is resolved,
- all messages sent on the promise may now be delivered to this resolution.
- In the control-flow programming we started with the caller waits for the
- recipient to be determined. By contrast, with <i>semi-data-flow</i> programming
- -- the message, not the sender, waits for the recipient to be determined.
+ <p align="left">All messages sent on a reference arrow move towards the
+ arrowhead in order to eventually be delivered to the object pointed at.
+ Messages sent on an unresolved promise do likewise, but wait behind the
+ unbound arrowhead until the promise is resolved. Once the promise is resolved,
+ all messages sent on the promise may now be delivered to this resolution.
+ In the control-flow programming we started with the caller waits for the
+ recipient to be determined. By contrast, with <i>semi-data-flow</i> programming
+ -- the message, not the sender, waits for the recipient to be determined.
</p>
- <p align="left">(We call this <i>semi-data-flow</i> to distinguish it from
- conventional data flow. In conventional data flow, a message would not
- be delivered until the recipient and all its arguments were resolved.
- This cannot be reconciled with E's partial ordering constraints, and is
- undesirable on other grounds as well. On those occasions where it is desired,
- it may easily be programmed in E. See the <code>promiseAllDone</code>
+ <p align="left">(We call this <i>semi-data-flow</i> to distinguish it from
+ conventional data flow. In conventional data flow, a message would not
+ be delivered until the recipient and all its arguments were resolved.
+ This cannot be reconciled with E's partial ordering constraints, and is
+ undesirable on other grounds as well. On those occasions where it is desired,
+ it may easily be programmed in E. See the <code>promiseAllDone</code>
(*** link needed) pattern.)</p>
<h2 align="left">Turning Semi-Data-Flow back into Control-Flow</h2>
- <p align="left">In our story so far, there is a puzzling contagion of eventual-ness.
- Once you have a reference that might be eventual, you must send rather
- than call on it; and when you do so, you get back another eventual reference
+ <p align="left">In our story so far, there is a puzzling contagion of eventual-ness.
+ Once you have a reference that might be eventual, you must send rather
+ than call on it; and when you do so, you get back another eventual reference
as a promise for the result.</p>
<h3 align="left">when-catch</h3>
<h3 align="left">whenResolved & whenMoreResolved</h3>
@@ -299,53 +299,53 @@
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>
- <TR VALIGN="TOP">
+ <TR VALIGN="TOP">
<TD WIDTH="10%"> </TD>
- <TD>
+ <TD>
<hr>
- <div align="center">
+ <div align="center">
<table cellpadding="4" cellspacing="0">
- <tr>
- <td>
+ <tr>
+ <td>
<div align="left"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a></div>
</td>
- <td>
+ <td>
<table border="3" align="center" cellpadding="6" cellspacing="3">
- <tr>
- <td>
- <div align="center"><font size="-1"><a href="../index.html">ELib</a>
- <a href="../../elang/index.html">E Language</a>
- <a href="../../smart-contracts/index.html">Smart
- Contracts</a> <a href="../../related.html">Related</a>
+ <tr>
+ <td>
+ <div align="center"><font size="-1"><a href="../index.html">ELib</a>
+ <a href="../../elang/index.html">E Language</a>
+ <a href="../../smart-contracts/index.html">Smart
+ Contracts</a> <a href="../../related.html">Related</a>
</font></div>
</td>
</tr>
- <tr>
- <td>
- <div align="center"><font size="-1"><a href="../../download/index.html">Download</a>
- <a href="../../javadoc/index.html">API</a>
- <a href="http://www.eros-os.org/pipermail/e-lang/">Mail
+ <tr>
+ <td>
+ <div align="center"><font size="-1"><a href="../../download/index.html">Download</a>
+ <a href="../../javadoc/index.html">API</a>
+ <a href="http://www.eros-os.org/pipermail/e-lang/">Mail
Archive</a> <a href="../../donate.html">Donations</a></font></div>
</td>
</tr>
</table>
</td>
</tr>
- </table>
+ </table>
<table width="100%" border="0" cellspacing="0" cellpadding="4">
- <tr>
+ <tr>
<td><i><a href="mailto:webmaster@erights.org">webmaster@erights.org</a></i><br>
- or <a href="http://www.blindpay.com/crit-me-now.cgi"><img src="../../images/cmn.gif" width="98" height="21" border="0" align="middle" alt="Annotate this page"></a>
+ or <a href="http://www.blindpay.com/crit-me-now.cgi"><img src="../../images/cmn.gif" width="98" height="21" border="0" align="middle" alt="Annotate this page"></a>
</td>
- <td>
- <div align="right">
+ <td>
+ <div align="right">
<p><a href="http://www.privacy.org/ipc/"><img src="../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://mirrors.yahoo.com/eff/blueribbon.html"><img src="../../images/ribbon.gif" width="18" height="30"
alt="Blue Ribbon Campaign" border="0"></a></p>
</div>
</td>
</tr>
</table>
-
+
</div>
</TD>
<TD WIDTH="10%" valign="bottom"> </TD>
1.12 +65 -65 e/doc/elib/concurrency/turns.html
Index: turns.html
===================================================================
RCS file: /cvs/e/doc/elib/concurrency/turns.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- turns.html 2001/05/09 05:00:41 1.11
+++ turns.html 2001/09/14 01:36:17 1.12
@@ -6,7 +6,7 @@
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<!-- #BeginEditable "doctitle" -->
<TITLE>Game Turns as MicroTransactions</TITLE>
-<!-- #EndEditable -->
+<!-- #EndEditable -->
<meta name="Author" content="Mark S. Miller">
<link rel=author rev=made href="mailto:markm@caplet.com" title="Mark S. Miller">
<META NAME="description" CONTENT="E: Cryptographic Capabilities for Distributed Smart Contracting">
@@ -18,31 +18,31 @@
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFEEDD" LINK="#0000FF" VLINK="#800080">
-<P>
+<P>
<TABLE BORDER="0" width="100%">
- <TR VALIGN="TOP">
+ <TR VALIGN="TOP">
<TD WIDTH="10%"> </TD>
- <TD>
- <P>
+ <TD>
+ <P>
<TABLE BORDER="0" WIDTH="100%">
- <TR>
- <TD ALIGN="LEFT" valign="top">
+ <TR>
+ <TD ALIGN="LEFT" valign="top">
<table cellpadding="2">
- <tr>
- <td valign="top" align="left" colspan="3"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a>
+ <tr>
+ <td valign="top" align="left" colspan="3"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a>
<!-- #BeginEditable "Path" -->/ <a href="../index.html">elib</a> / <a href="index.html">concurrency</a> <!-- #EndEditable --></td>
</tr>
- <tr>
+ <tr>
<td valign="top" align="right"><!-- #BeginEditable "PrevButton" --><a href="msg-passing.html"><img src="../../images/prev.gif" width="64" height="32" alt="Back to: Message Passing" border="0"></a><!-- #EndEditable --></td>
<td valign="bottom" align="left"><!-- #BeginEditable "FirstButton" --><!-- #EndEditable --></td>
<td valign="top" align="left"><!-- #BeginEditable "NextButton" --><a href="partial-order.html"><img src="../../images/next.gif" width="64" height="32" alt="On to: Partial Order" border="0"></a><!-- #EndEditable --></td>
</tr>
</table>
</TD>
- <TD ALIGN="RIGHT">
+ <TD ALIGN="RIGHT">
<P ALIGN="RIGHT"><FONT SIZE="7"><!-- #BeginEditable "BigTitle" --><FONT SIZE="7"><B>Game
Turns as<br>
- <font size="4">Micro</font>Transactions</B></FONT><!-- #EndEditable --></FONT>
+ <font size="4">Micro</font>Transactions</B></FONT><!-- #EndEditable --></FONT>
</TD>
</TR>
</TABLE>
@@ -61,16 +61,16 @@
because of a sequence of turns, and each turn executes with mutually exclusive
access to this state, and it executes to completion before before the
next turn starts. </p>
- <p align="left">Although other Vats are executing concurrently, a caller
- will only see synchronous side effects caused by its callee. Because Vats
- are only asynchronously coupled to each other, an E turn implicitly has
- full mutual exclusion on all state to which it has synchronous access
- -- which is only state within its Vat. As a result, E execution is not
- observably distinguishable (except for timing and the effects of infinite
- loops) from an implementation in which, across the universe, only one
- Vat at a time takes a turn. E’s turns are therefore atomic serializable
- micro-transactions, and E is strongly consistency preserving in the face
- of concurrency, without any error-prone fine-grained locking.
+ <p align="left">Although other Vats are executing concurrently, a caller
+ will only see synchronous side effects caused by its callee. Because Vats
+ are only asynchronously coupled to each other, an E turn implicitly has
+ full mutual exclusion on all state to which it has synchronous access
+ -- which is only state within its Vat. As a result, E execution is not
+ observably distinguishable (except for timing and the effects of infinite
+ loops) from an implementation in which, across the universe, only one
+ Vat at a time takes a turn. E’s turns are therefore atomic serializable
+ micro-transactions, and E is strongly consistency preserving in the face
+ of concurrency, without any error-prone fine-grained locking.
<p align="left">We say <i>micro-transaction</i> above because we purposely
unbundle or avoid the features combined by the classic ACID transaction:
<p align="left">
@@ -80,16 +80,16 @@
a Vat is checkpointed much less often than once per turn.
<p>
</li>
- <li>Unlike many systems, E doesn’t claim to provide distributed atomic
- transactions. But seeing as how these are provably unimplementable (see
- the <a href="http://hpc.serc.iisc.ernet.in/%7Ekama/lec7/sld013.htm">Coordinated
- Attack Problem</a>), this might not be the loss it seems. Although one
- can build distributed mutual exclusion protocols on top of E, good E
- style is to avoid these like the plague. Indeed, we have so far only
- encountered one practical application that demanded it (ref ** The Communities.com
- Containership problem). <a href="../distrib/partial-failure.html">Handling
- Partial Failures</a> explains E's very different approach to recovering
- distributed consistency following network partitions or rollbacks.
+ <li>Unlike many systems, E doesn’t claim to provide distributed atomic
+ transactions. But seeing as how these are provably unimplementable (see
+ the <a href="http://hpc.serc.iisc.ernet.in/%7Ekama/lec7/sld013.htm">Coordinated
+ Attack Problem</a>), this might not be the loss it seems. Although one
+ can build distributed mutual exclusion protocols on top of E, good E
+ style is to avoid these like the plague. Indeed, we have so far only
+ encountered one practical application that demanded it (ref ** The Communities.com
+ Containership problem). <a href="../distrib/partial-failure.html">Handling
+ Partial Failures</a> explains E's very different approach to recovering
+ distributed consistency following network partitions or rollbacks.
<p>
</li>
<li>There is no facility for aborting a turn and automatically undoing
@@ -120,7 +120,7 @@
to getValue() {value}
to setValue(newValue) {
for observer in observers {
- observer <- valueChanged(newValue)
+ observer <- valueChanged(newValue)
}
value := newValue
}
@@ -138,15 +138,15 @@
observable variable’s assigner returned from the assignment. The code
containing the assignment was likely written without taking the possibility
of such side effects in mind, and this is as it should be.
- <p align="left">When Alice passes a message to Bob in order to subcontract
- part of her plan to Bob, she is invoking Bob on her own behalf, and so
- would often want to wait for Bob’s side effects and outcome. The immediate
- call does precisely this. When Alice passes a message to Bob on Bob’s
- behalf, as when Alice is an observable and Bob is an observer, this courtesy
- provided to Bob should be minimally disruptive to Alice. The send above
- queues, on the queue of the observer's vat, a pending delivery of a <code>valueChanged()</code>
- message to this observer. This delivery will happen in its own separate
- turn, and cannot affect the turn from which it was sent.
+ <p align="left">When Alice passes a message to Bob in order to subcontract
+ part of her plan to Bob, she is invoking Bob on her own behalf, and so
+ would often want to wait for Bob’s side effects and outcome. The immediate
+ call does precisely this. When Alice passes a message to Bob on Bob’s
+ behalf, as when Alice is an observable and Bob is an observer, this courtesy
+ provided to Bob should be minimally disruptive to Alice. The send above
+ queues, on the queue of the observer's vat, a pending delivery of a <code>valueChanged()</code>
+ message to this observer. This delivery will happen in its own separate
+ turn, and cannot affect the turn from which it was sent.
<p align="left">We can now understand why the other peculiar thing in the
above code is harmless: To illustrate our point, we put the actual assignment
after the loop notifying the observers. If we were calling the observers
@@ -163,53 +163,53 @@
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
</TR>
- <TR VALIGN="TOP">
+ <TR VALIGN="TOP">
<TD WIDTH="10%"> </TD>
- <TD>
+ <TD>
<hr>
- <div align="center">
+ <div align="center">
<table cellpadding="4" cellspacing="0">
- <tr>
- <td>
+ <tr>
+ <td>
<div align="left"><a href="../../index.html"><img src="../../images/e-lambda.gif" width="32" height="32" border="0" valign="center" alt="ERights Home"></a></div>
</td>
- <td>
+ <td>
<table border="3" align="center" cellpadding="6" cellspacing="3">
- <tr>
- <td>
- <div align="center"><font size="-1"><a href="../index.html">ELib</a>
- <a href="../../elang/index.html">E Language</a>
- <a href="../../smart-contracts/index.html">Smart
- Contracts</a> <a href="../../related.html">Related</a>
+ <tr>
+ <td>
+ <div align="center"><font size="-1"><a href="../index.html">ELib</a>
+ <a href="../../elang/index.html">E Language</a>
+ <a href="../../smart-contracts/index.html">Smart
+ Contracts</a> <a href="../../related.html">Related</a>
</font></div>
</td>
</tr>
- <tr>
- <td>
- <div align="center"><font size="-1"><a href="../../download/index.html">Download</a>
- <a href="../../javadoc/index.html">API</a>
- <a href="http://www.eros-os.org/pipermail/e-lang/">Mail
+ <tr>
+ <td>
+ <div align="center"><font size="-1"><a href="../../download/index.html">Download</a>
+ <a href="../../javadoc/index.html">API</a>
+ <a href="http://www.eros-os.org/pipermail/e-lang/">Mail
Archive</a> <a href="../../donate.html">Donations</a></font></div>
</td>
</tr>
</table>
</td>
</tr>
- </table>
+ </table>
<table width="100%" border="0" cellspacing="0" cellpadding="4">
- <tr>
+ <tr>
<td><i><a href="mailto:webmaster@erights.org">webmaster@erights.org</a></i><br>
- or <a href="http://www.blindpay.com/crit-me-now.cgi"><img src="../../images/cmn.gif" width="98" height="21" border="0" align="middle" alt="Annotate this page"></a>
+ or <a href="http://www.blindpay.com/crit-me-now.cgi"><img src="../../images/cmn.gif" width="98" height="21" border="0" align="middle" alt="Annotate this page"></a>
</td>
- <td>
- <div align="right">
+ <td>
+ <div align="right">
<p><a href="http://www.privacy.org/ipc/"><img src="../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://mirrors.yahoo.com/eff/blueribbon.html"><img src="../../images/ribbon.gif" width="18" height="30"
alt="Blue Ribbon Campaign" border="0"></a></p>
</div>
</td>
</tr>
</table>
-
+
</div>
</TD>
<TD WIDTH="10%" valign="bottom"> </TD>
1.2 +61 -61 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.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- after-both.html 2001/05/07 09:25:20 1.1
+++ after-both.html 2001/09/14 01:36:18 1.2
@@ -1,11 +1,11 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <!--last modified on Saturday, October 03, 1998 04:19 PM -->
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <!--last modified on Saturday, October 03, 1998 04:19 PM -->
-
+
-
+
Four Party Partial Order
-
+
@@ -16,48 +16,48 @@
Contracting, Agoric E-Commerce, Open Source, Message pipelining, quasi literal, vat, event loop, granovetter diagram ">
-
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 grant
- matching. 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
+
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 grant
+ matching. 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):
Given a and b, this immediately returns a promise for a
- reference that will be acceptable as a valid interpretation what a
- meant, and a valid interpretation of what b 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
+
Given a and b, this immediately returns a promise for a
+ reference that will be acceptable as a valid interpretation what a
+ meant, and a valid interpretation of what b 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.
