Promises in E (was Re: A Challenge Problem for Promise Designers)
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 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.
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:
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 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 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 "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.
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