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

On Mon, May 6, 2013 at 11:19 AM, Mark S. Miller <erights@google.com> wrote:
> 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.

Right; apologies for the confusion, this is what I meant.

*Given* nestable promises, the contract function *can* take promise
arguments, because the caller can produce a promise for it.  So this
is a gain in functionality.

This is actually simply another example of the "distinct types of
promises" meta-use-case - the "contract host" returned by
makeContractHost runs on promises-for-an-argument, which the contract
users fulfill at their leisure.  The contract function itself can take
a promise-for-[anything], which is completely distinct.

This is a nice, completely different example of distinct promises
being useful when nested.

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

Well, "v=>Future.accept(v.foo)", given monadic resolution semantics.
(If .then() unwraps fully, this is obviously unnecessary.)

I believe my statement was correct, then - given monadic resolution
semantics and the code as presented at that link, enqueuing a pending
promise and then dequeueing will get you a fulfilled promise for a
pending promise.  Auto-flattening gives you a simple pending promise.

~TJ

Received on Monday, 6 May 2013 19:29:44 UTC