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

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
>
>


-- 
    Cheers,
    --MarkM