W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Promises in E (was Re: A Challenge Problem for Promise Designers)

From: Bill Frantz <frantz@pwpconsult.com>
Date: Fri, 26 Apr 2013 15:47:48 -0700
To: "Mark S. Miller" <erights@google.com>
cc: Andreas Rossberg <rossberg@google.com>, David Bruant <bruant.d@gmail.com>, public-script-coord@w3.org, Mark Miller <erights@gmail.com>, Dean Tribble <tribble@e-dean.com>, es-discuss <es-discuss@mozilla.org>
Message-ID: <r422Ps-1075i-A6448C33CE9B4DFAA0D7631C16FD5AD2@Williams-MacBook-Pro.local>
Thanks for making these issues clearer to me Mark. I am 
beginning to get some idea of the problems that JS promises face 
given that they must have an object-like appearance.

I like the fact that in E, promises "just work" and I think of 
Joule as a language where every value is a promise and 
computation will take place when the data is ready.

Cheers - Bill

On 4/26/13 at 9:43 AM, erights@google.com (Mark S. Miller) wrote:

>Hi Bill,
>I think I know what you mean by these terms, and what I think you mean is
>correct ;). But given the history of promises and futures, you make two
>unfortunate and confusing terminology choices: "forced" and "wait".
>Instead, E promises, like all JS promises, are inherently non-blocking. The
>"when" (aka "then") doesn't "force" or "wait" or block, it registers the
>callback[s] to be called in a later turn of the event loop sometime after
>the promise they are registered on is fulfilled or broken (aka "fulfilled"
>or "rejected"). The "when" immediately returns a promise for what the
>invoked callback will return. In all these ways, E promises are like modern
>JS promises.
>None of this however addresses the prior question about E promises. E
>promises were inspired by Joule Channels and Xanadu promises, both of which
>were at least as influenced by Concurrent Prolog logic variables as they
>were by previous promise/future systems[1]. As with logic variables, once
>an E promise is fulfilled with a value, it is that value, i.e., it is not
>observably different from that value. The E equality tests will judge it to
>be identical to its fulfillment. In Actor or Smalltalk terms, one could say
>it becomes that value. This was viable in E for reasons not available in
>JS, and so a JS promise fulfilled with a value remains distinct from the
>value itself. The formalism that originally inspired modern JS promises is
>thus the logic variables of concurrent logic programming; so the similarity
>of the resulting abstractions in some ways to monads surprised me.
>The reason this works in E is indeed touched on by your email -- an
>unresolved (aka "pending") E promise is a kind of reference, not a kind of
>object, and so does not have its own methods. Using "." on a pending E
>promise is an error. Using "<-" (aka "!") on an E promise invokes the
>object it is a promise for, rather than invoking the promise itself[2].
>"when" is something one does to a promise, not something one asks a promise
>to do. It is the extreme form of the "featureless"ness that Kevin raises.
>[1] See Chapter 23 of <http://erights.org/talks/thesis/markm-thesis.pdf>
>"From Objects to Actors and Back Again"
>[2] Not quite true. There are three eventual messages that are a visible
>part of the promise infrastructure: __whenMoreResolved, __whenBroken, and
>__reactToLostClient. The first two are understood by the promises. The last
>is emitted by promises on partition. But none of these are part of the
>normal use experience -- hence the two initial underbars in their names. JS
>promises achieve the needs these serve by other means.
>On Fri, Apr 26, 2013 at 6:03 AM, Bill Frantz <frantz@pwpconsult.com> wrote:
>>Let me take a crack at describing E's support for promises.
>>E has two modes for sending a message to an object. There is the immediate
>>send and the eventual send. If the Object is an unresolved promise the
>>immediate send will trap. (A promise can be forced to resolve using the
>>"when" construct.)
>>If the program uses eventual sends, then unresolved promises act like any
>>other value. This allows operations such as:
>>Object A on machine 1
>>Object B on machine 2
>>A sends to B getting back object C also hosted on machine 2
>>A sends to C getting back a final result.
>>The way this is implemented is that when A sends to B, a promise for the
>>result C is constructed. When A sends to C, that promise is used for the
>>send and a promise for the final result is constructed. The message to C is
>>sent without waiting for the response from the message to B, eliminating
>>one round trip communication delay.
>>If A needs to use the final result in an immediate operation, it will wait
>>for the final result promise to be resolved using the "when" construct.
>>Cheers - Bill
>>Bill Frantz        | I like the farmers' market   | Periwinkle
>>(408)356-8506      | because I can get fruits and | 16345 Englewood Ave
>>www.pwpconsult.com | vegetables without stickers. | Los Gatos, CA 95032
Bill Frantz        | "I wish there was a knob on the TV to turn 
up the
408-356-8506       | intelligence.  There's a knob called 
"brightness", but
www.pwpconsult.com | it doesn't work. -- Gallagher
Received on Saturday, 27 April 2013 17:52:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC