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

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


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



-- 
    Cheers,
    --MarkM