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

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.

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



On Mon, May 6, 2013 at 10:25 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, May 3, 2013 at 7:10 PM, Sam Tobin-Hochstadt <samth@ccs.neu.edu>
> wrote:
> > On Fri, May 3, 2013 at 7:17 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> Third, there's the question of what a nested promise actually means.
> >> Normally a promise represents "a value after some time". But what does
> >> a nested promise mean? "A value after a longer time" obviously isn't
> >> correct since there are no time constraints associated with a promise.
> >> "A promise after some time" also isn't really meaningful given that
> >> that simply means "A value after some time after some time".
> >
> > I've been staying out of all of the promises discussions, but this
> > just doesn't make any sense at all.  A function of no arguments is a
> > "computation that produces a value".  By a similar argument to yours,
> > functions of no arguments that produce the same aren't meaningful,
> > because it's a "computation that produces a computation that produces
> > a value".  I hope we can all see that this in fact makes perfect
> > sense.
>
> The difference is that it's meaningful for a function that takes no
> argument to return a function that takes no argument. That provides
> the capability for the caller of the initial function to determine
> when the returned function should be called. Thus it lets the caller
> postpone the CPU cycles spent by the returned function until the
> result is actually needed.
>
> To put it another way a "computation that produces a computation that
> produces a value" is meaningful since you can choose to not perform
> the second computation if it turns out that you don't need it.
>
> And then there's of course the fact that in many languages functions
> can have side effects, and so the caller of the first function can
> choose to have the side effects from the returned function happen at a
> desired time.
>
> None of these use cases apply for promises.
>
> But I can agree that using sentence parsing to make my point might not
> have been the best way to do it. But my point still stands that
> promises that return promises doesn't appear to have any useful
> semantics. Nor have anyone brought forward any use cases.
>
> / Jonas
>



-- 
    Cheers,
    --MarkM