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

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

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

~TJ

Received on Monday, 6 May 2013 17:58:07 UTC