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

Re: Promises: Auto-assimilating thenables returned by .then() callbacks: yay/nay?

From: Mark S. Miller <erights@google.com>
Date: Mon, 6 May 2013 11:19:45 -0700
Message-ID: <CABHxS9g5EAMfiG+fTvQjRyz06jsNYaM=bUSRnJwE79BBHpSeqQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Sam Tobin-Hochstadt <samth@ccs.neu.edu>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, May 6, 2013 at 10:57 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Mon, May 6, 2013 at 10:39 AM, Mark S. Miller <erights@google.com>
> wrote:
> > I'm surprised that no one has come up with *any* use cases. As I
> mentioned
> > before, I have encountered some use cases that individually seem to argue
> > for promises-for-promises. But I don't find them compelling. Given the
> > absence of promises-for-promises, these can easily work around their
> > absence. Here are two use cases. One of them even cuts both ways.
> >
> > * The generic contract host defined in Figure 3 of
> > <http://research.google.com/pubs/pub40673.html> requires its contract
> > function to be a function of resolved arguments. It cannot handle a
> contract
> > function that could validly take a pending promise as argument because it
> > uses a Q.all to determine when all the arguments have arrived.
> In this case, you mean that the contract function could take a
> fulfilled promise for a pending promise, but it couldn't do so it
> promises were auto-flattened (so that it was just a pending promise)?

No. The problem is created merely by defining and trying to use a contract
function that takes a pending promise as argument. Promise parameters
aside, if a contract function takes a parameter x, the Q.all within
makeContractHost will be .then-ing a promise-for-x. If
promises-for-promises were possible, then x could be a pending promise and
the Q.all would be .then-ing a promise-for-a-pending promise. When this
outer promise becomes a fulfilled-promise-for-a-pending-promise, the Q.all
would fire providing the contract function the outer promise's fulfillment
value, which is the pending promise. Given that promises-for-promises are
not possible, the only working contract functions that can be provided to
makeContractHost are those whose arguments are anything other than pending

> > * The Infinite Queue at
> > <
> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#infinite_queue
> >
> > cuts both ways. If the producer enqueues a pending promise, the consumer
> > cannot detect this as different from the producer not yet having enqueued
> > anything. For most purposes, this is the more convenient behavior.
> However,
> > for flow control purposes, the consumer might want to limit how far
> ahead of
> > the producer it dequeues, and this ambiguity would cause the consumer to
> > stall inappropriately.
> I believe this relies on auto-flattening, no?  "front ! head" returns
> a promise for front.head, which is assumed to be a plain value.  If
> you enqueue a promise, assuming monadic flattening, I think you should
> just get the promise back out.  (However, I'm not entirely clear on
> the semantics of !.)

"p ! foo" is just syntactic sugar for "Q(p).get('foo')". In the absence of
extended or remote promises, this is essentially equivalent to

Q(p).then(v => v.foo)

> ~TJ

Received on Monday, 6 May 2013 18:20:12 UTC

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