[e-lang] Events as Bad Ideas

[Mark Miller]

(With the inclusion of the following, this email is also a valid updoc script. 
You can otherwise ignore it.)

     ? def i := 3
     # value: 3

     ? def j := 0
     # value: 0

Jonathan S. Shapiro wrote:
> The point I was trying to make is simply that failure handling is
> orthogonal to the events vs. threads issue. No matter which scheme one
> uses, some mechanism is required to handle exceptional situations.
> 
> My understanding was that a broken promise results from remote vat
> failure. That is, it is the result of some vat failing to compute an
> expected result because the remote vat has crashed or otherwise run out
> of resources.
> 
> Have I misunderstood broken promises?

Ok, I see the confusion. You're half right. The case you're talking about is 
when a partition causes an already resolved remote reference (a Far reference) 
to transition to a Broken reference. It doesn't matter whether the partition 
is caused by a crash or a genuine partition.

The other case is when an unresolved promise makes a transition directly to a 
broken promise. For this case, the threads vs events issue is not orthogonal. 
Let's contrast two expressions:

     ? def k := i.floorDivide(j)  # can be abbreviated as i // j
     # problem: <ArithmeticException: / by zero>


vs

     ? def k := i <- floorDivide(j)
     # value: <Promise>

If j is 0, the first example will throw an exception, terminating the normal 
control flow, thereby causing k never to come into scope.

In the second example, we have arranged for the message "floorDivide(j)" to be 
delivered to i in a separate (serializably later) event. Once this arrangement 
is made, k is immediately bound to a promise for the value that will be 
computed by this event. Control flow then proceeds in the current event 
independent of what will be computed in this other event.

In this case, if j is 0, then this other event will throw an exception rather 
than returning a value. In this case, the promise becomes broken rather than 
fulfilled. It transitions directly to a broken reference reporting divide by zero.

     ? interp.waitAtTop(k)  # pauses updoc script until k is resolved

     ? k
     # value: <ref broken by problem: <ArithmeticException: / by zero>>

Like non-signaling NaNs, broken references are contagious, allowing the 
aggregation of exceptional state without getting in the way of pipelining. One 
could think of a broken reference as "Not an Object", or "NanO". But "broken" 
seems clearer.

For more on this, please see
<http://www.erights.org/elib/concurrency/index.html>,
<http://www.skyhunter.com/marcs/ewalnut.html#SEC18>, and
<http://www.erights.org/talks/promises/index.html>.

See especially <http://www.erights.org/elib/concurrency/refmech.html> for the 
state transition diagram among the possible states of a reference in E.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM