Promises in E (was Re: A Challenge Problem for Promise Designers)
frantz at pwpconsult.com
Fri Apr 26 15:47:48 PDT 2013
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 at google.com (Mark S. Miller) wrote:
>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
>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. 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.
>"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.
> See Chapter 23 of <http://erights.org/talks/thesis/markm-thesis.pdf>
>"From Objects to Actors and Back Again"
> 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 at 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
>>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
408-356-8506 | intelligence. There's a knob called
www.pwpconsult.com | it doesn't work. -- Gallagher
More information about the es-discuss