[e-cvs] cvs commit: e/doc/elang/concurrency epimenides.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Tue, 17 Jul 2001 20:11:20 -0400
markm 01/07/17 20:11:20
Modified: doc/elang/concurrency epimenides.html
Log:
closer to updocing
Revision Changes Path
1.28 +66 -66 e/doc/elang/concurrency/epimenides.html
Index: epimenides.html
===================================================================
RCS file: /cvs/e/doc/elang/concurrency/epimenides.html,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- epimenides.html 2001/05/09 05:00:41 1.27
+++ epimenides.html 2001/07/18 00:11:20 1.28
@@ -46,7 +46,7 @@
</TR>
</TABLE>
<hr>
- <!-- #BeginEditable "LongBody" -->
+ <!-- #BeginEditable "LongBody" -->
<P ALIGN="left">Epimenides the Cretan, <a href="http://www.wordsmith.demon.co.uk/paradoxes/#epimenides">so
the story goes</a>, once said "All Cretans are liars." The logical
issues raised were later distilled into pure form as the <i>Liar Paradox</i>,
@@ -56,11 +56,11 @@
false isn't true, so the sentence would be true. As long as we insist
that all sentences are either true or false, we can get tied up in such
knots.
- <p>What does this have to do with E? At the end of <i><a href="../blocks/defVar.html#scopeConsistency">Defining
- Variables</a> </i> we saw how to initialize circular structures by using
- variables on the right side of a define expression that are to be defined
+ <p>What does this have to do with E? At the end of <i><a href="../blocks/defVar.html#scopeConsistency">Defining
+ Variables</a> </i> we saw how to initialize circular structures by using
+ variables on the right side of a define expression that are to be defined
on the left:</p>
- <blockquote>
+ <blockquote>
<pre>def model := modelMaker(...)
def [view, controller] := [
viewMaker(model, controller),
@@ -68,88 +68,88 @@
]</pre>
</blockquote>
<p>in order to create:<img src="images/mvc.gif" width="282" height="278" align="top"></p>
- <p align="left">Since we can define data in terms of itself, can we do so
- paradoxically? Let's try to define a variable, <code>liar</code>, whose
+ <p align="left">Since we can define data in terms of itself, can we do so
+ paradoxically? Let's try to define a variable, <code>liar</code>, whose
value is the truth of the above paradoxical sentence:</p>
- <blockquote>
+ <blockquote>
<pre>? def liar := !liar
-# problem: java.lang.RuntimeException: not synchronously callable</pre>
+# problem: not synchronously callable</pre>
</blockquote>
- <p>Since the sentence is true if and only if it's false, we just define
- <code>liar</code> to be the opposite of itself. But what problem are we
- running into? Before we answer that, let's try this again using the explicit
+ <p>Since the sentence is true if and only if it's false, we just define
+ <code>liar</code> to be the opposite of itself. But what problem are we
+ running into? Before we answer that, let's try this again using the explicit
message passing syntax instead of the operator shorthand:</p>
- <blockquote>
- <pre>? def liar := liar not
-# problem: java.lang.RuntimeException: not synchronously callable</pre>
- </blockquote>
- <p>As is familiar, in E the value of a variable or an expression is an object
- reference, sometimes called a <i>pointer to an object</i>. This is often
- diagrammed as an arrow whose tail is the reference as a value, and whose
- head is attached to an object. Messages passed onto the reference ride
- from tail to head until they meet the object that should process the message.
- In the familar <a href="../../elib/capability/ode/index.html">Granovetter
+ <blockquote>
+ <pre>? def liar := liar not()
+# problem: not synchronously callable</pre>
+ </blockquote>
+ <p>As is familiar, in E the value of a variable or an expression is an object
+ reference, sometimes called a <i>pointer to an object</i>. This is often
+ diagrammed as an arrow whose tail is the reference as a value, and whose
+ head is attached to an object. Messages passed onto the reference ride
+ from tail to head until they meet the object that should process the message.
+ In the familar <a href="../../elib/capability/ode/index.html">Granovetter
Diagram</a></p>
<p align="center"><img src="images/fundamental.gif" width="308" height="312"></p>
- <p align="left">we say that Alice sends to Bob a <code>foo</code> message
+ <p align="left">we say that Alice sends to Bob a <code>foo</code> message
containing a copy of Alice's reference to Carol:</p>
- <blockquote>
+ <blockquote>
<pre align="left"># Somewhere inside Alice:
bob foo(carol)</pre>
</blockquote>
- <p>The two dots on the arrow tails within Alice represent Alice's instance
- variables "bob" and "carol" as used in the corresponding
- snippet of code. Though the diagram is neutral about what kind of message
- passing Alice is doing, the above code snippet shows a synchronous call,
- meaning that Bob will receive the message, deal with it, and pass control
- back to Alice before the above code in Alice continues. By using a synchronous
- call, Alice is asking Bob to <i>do it now</i>. She can only do this if
- her reference to Bob is a <i>local</i> reference. A reference is <i>local</i>
- if </p>
+ <p>The two dots on the arrow tails within Alice represent Alice's instance
+ variables "<code>bob</code>" and "<code>carol</code>"
+ as used in the corresponding snippet of code. Though the diagram is neutral
+ about what kind of message passing Alice is doing, the above code snippet
+ shows a synchronous call, meaning that Bob will receive the message, deal
+ with it, and pass control back to Alice before the above code in Alice
+ continues. By using a synchronous call, Alice is asking Bob to <i>do it
+ now</i>. She can only do this if her reference to Bob is a <i><a href="../../elib/concurrency/refmech.html">near</a></i><a href="../../elib/concurrency/refmech.html">
+ reference</a>. A reference is <i>near</i> if </p>
<ol>
<li>both the arrow head and the arrow tail are in the same Vat, and </li>
<li>if the arrow head is already attached to an object.</li>
</ol>
- <p>Once a reference is local it will be forever local, and it will always
- be attached to the same object. A local reference will never fail to deliver
- a message sent on it to this object. Conventional single-address-space
- object-oriented programming (sasoop) has only the equivalent of local
- references.</p>
- <p>The other possible states for a reference are <i>deferred</i> and <i>broken</i>.
- A reference that crosses between machines is deferred, as is a reference
+ <p>Once a reference is near it will be forever near, and it will always
+ be attached to the same object. A near reference will never fail to deliver
+ a message sent on it to this object. Conventional single-address-space
+ object-oriented programming (sasoop) has only the equivalent of near references.</p>
+ <p>The other possible states for a reference are <i>eventual</i> and <i>broken</i>.
+ A reference that crosses between machines is eventual, as is a reference
whose arrow head isn't yet attached to an object. When you use a variable
on the right side of a definition that will be defined on the left side,
during the execution of this right side, the value of the variable is
- a deferred reference designating the object that the variable will be
- initialized to. It is the tail of an arrow whose head will be hooked up,
- but it doesn't get hooked up until after the right side finishes executing.
- We also refer to this as a <i>promise</i> for the value of the variable.</p>
- <p>Since there's not yet an object on the other side of the arrow, a <i>do
- it now</i> message pass results in the above error. However, we can use
- E's <i>do it eventually</i> message pass, the asynchronous send operator:<br>
- </p>
- <blockquote>
- <pre>? def liar := liar <- not
-# value: Deferred promise</pre>
- </blockquote>
- <p>We are asking whatever object comes to be pointed at by the arrow tail
- held at <code>liar</code> to compute the <code>not</code> of itself. We
- then "resolve" the value of <code>liar</code> by initializing
- it to the eventual result of this <code>not</code> message.</p>
+ an eventual reference designating the object the variable will be initialized
+ to. It is the tail of an arrow whose head will be hooked up, but it doesn't
+ get hooked up until after the right side finishes executing. We also refer
+ to this as a <i>promise</i> for the value of the variable.</p>
+ <p>Since there's not yet an object on the other side of the arrow, a <i>do
+ it now</i> message pass results in the above error. However, we can use
+ E's <i>do it eventually</i> message pass, the asynchronous send operator,
+ "<code><-</code>": </p>
+ <blockquote>
+ <pre>? def liar := liar <- not()
+# value: <Eventual ref></pre>
+ </blockquote>
+ <p>We are asking whatever object comes to be pointed at by the arrow tail
+ held at <code>liar</code> to compute the <code>not()</code> of itself.
+ We then "resolve" the value of <code>liar</code> by initializing
+ it to the eventual result of this <code>not()</code> message.</p>
<p align="center"><img src="images/liar.gif" width="261" height="99"></p>
- <p> The not message is stalled until there is an object for it to be delivered
- to. The object it's waiting for is the result of the not message itself.
- Therefore, the variable is stuck in an unresolved state, never being able
- to decide if it's true or false, and therefore never having to deal with
- the paradox. Forever more, with this value you'll get:</p>
- <blockquote>
+ <p> The <code>not()</code> message is stalled until there is an object for
+ it to be delivered to. The object it's waiting for is the result of the
+ <code>not()</code> message itself. Therefore, the variable is stuck in
+ an unresolved state, never being able to decide if it's true or false,
+ and therefore never having to deal with the paradox. Forever more, with
+ this value you'll get:</p>
+ <blockquote>
<pre>? liar
-# value: Deferred promise</pre>
+# value: <Eventual ref></pre>
</blockquote>
- <p align="left"><i>"Doctor, it hurts when I take this inference step."
- "Well then, don't take that inference step."</i> Such unresolvable
- circular definitions are the closest E comes to conventional deadlock.
+ <p align="left"><i>"Doctor, it hurts when I take this inference step."
+ "Well then, don't take that inference step."</i> Such unresolvable
+ circular definitions are the closest E comes to conventional deadlock.
We call this <i>data-lock</i>.</p>
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>