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

On Mon, May 6, 2013 at 1:25 PM, 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.

This is silly in just the same way.  Given a promise, we can choose to
wait for its result, or not, just as with a function, we can run it or
not.

In fact, if you write in continuation-passing style everywhere,
instead of just when interacting with I/O, calling a function and
waiting on a promise are *the same operation*.

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

I don't know what you mean by "useful", but they have perfectly
well-defined and consistent semantics.

> Nor have anyone brought forward any use cases.

Consider a hash table that keeps some state remotely. Then a promise
is useful for the results.  If promises for promises are impossible,
can you store promises in the table?

Sam

Received on Monday, 6 May 2013 17:41:02 UTC