Where'd Promise#done go?

Mark S. Miller erights at google.com
Thu Jun 20 23:13:12 PDT 2013

On Thu, Jun 20, 2013 at 3:25 PM, Forbes Lindesay <forbes at lindesay.co.uk>wrote:

> Returning to Mark Miller's comment:
> > Any beginning JavaScript programmer learns the meaning of `a.foo(b,c)`,
> i.e., synchronous message send, long before they learn about callbacks.
> I don't see any simple and obvious path from understanding the synchronous
> message send to understanding how promises work.  How does that explanation
> look?

Take it in three steps.

Step 1

var d = a.foo(b,c);

This does synchronous message sending. It delivers the message "foo(b,c)"
to the object designated by "a" immediately, transferring control to that
object -- the callee -- now. The caller blocks waiting for the callee to
respond. The callee runs to completion, finally returning a value. At this
point the caller receives that value into d and continues.

In order for the callee to be invoked synchronously, it must be local,
since we don't want to wait on a round trip to a remote object.

In a communicating event-loop system, such synchronous call/return has a
strong side effect contract with pros and cons.
* pros: no local time passes between the calling and the being called, so
the callee gets control in the state in which the caller made the request.
* cons: the callee runs while the caller, and the caller's caller, etc, are
suspended in the midst of some operations. They might have suspended
invariants, or otherwise be unprepared for recursive entry in their current
state. This threatens both caller and callee.

Step 2

var dP = aP ! foo(b,c);

This does asynchronous message sending. It delivers the message "foo(b,c)"
to the object designated by aP eventually, eventually causing that object
-- the callee -- to gain control. But the caller proceeds now without any
interleaving of control by others. Since the caller proceeds immediately,
dP cannot yet provide access to what the callee will return. But it still
designates that value, whatever it will be. A designator whose designation
is not yet determined is a promise. If the callee eventually returns an
int, then dP is already a promise for that int, though neither it nor we
know that yet.

Since we're only sending a message to the callee eventually and not waiting
for it to respond, we don't much care whether it is local or remote.

In a communicating event loop system, such asynchronous message sending has
a strong side effect contract with the opposite pros and cons.
* pros: The caller executes to completion without possibility of
interference from the callee. Any delicate state the caller was in the
midst of manipulating is unperturbed, and the caller can complete its
manipulation, confident that its invariants were not disrupted. Likewise,
the callee receives the message in an empty stack state, in which all
previous turns have presumably restored all heap invariants. This is a
robust situation from which to start running.
* cons: Between the caller requesting and the callee receiving, and
arbitrary number of previously queued turns may run in the meantime,
changing the world from the one in which the caller decided to send the
message. By the time it arrives, it may no longer be relevant or

Step 3

Ok, so we can "." on local objects like "a", and we can "!" on local or
remote objects like aP. What about dP? It also designates something, but
that something is separated from us in time, not (necessarily) in space. No
matter! Asynchrony handles that too. If aP is remote, the message gets
queued on the event-loop hosting the object aP designates. If dP is
pending, the message gets queued in dP itself. Once dP knows what it
designates, it forwards all these queued messages to that target using !.

> It seems on the other hand I can see a natural progression from callbacks
> to `.done` and from `.done` to `.then` because if you write any code using
> `.done` it's infinitely obvious that you need `.then`.
> I think it's interesting to also reflect on Tasks in C# which have been
> around for a while.  They don't have any methods for automatically tracking
> unhandled rejections even though the language supports handling object
> destruction.  All the methods that are built in to the Task object match up
> with `.done` rather than `.then`.  This becomes much less of a problem once
> the language has `await` or similar.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130620/47651d18/attachment.html>

More information about the es-discuss mailing list