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

On Tue, May 7, 2013 at 6:03 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, May 6, 2013 at 10:40 AM, Sam Tobin-Hochstadt <samth@ccs.neu.edu> wrote:
>> 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.
>
> No. Existing promise libraries are built around the idea that the
> calculation to create the value always happens, no matter if someone
> has said they are listening to the promise or not.
>
> So they do not provide the ability to postpone a calculation until
> someone that has access to the promise requests the calculation to be
> performed.

I said nothing about performing calculation.  Given a promise, you can
either wait for its result by using .then(), or not. This is just like
the ability to call a function, or not. That other computation might
happen in the background regardless of what we do is neither here nor
there.

>>> 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?
>
> This is similar to the example I brought up, except that you store the
> values in a hash table rather than storing them in a database.
>
> This is indeed an interesting use case. One relevant question is: What
> is the use case for getting the promise stored in the hash/database,
> rather than getting the value that the promise represents?
>
> In your hash table example as a consumer I would think it's great if
> what I get out of the API is values rather than promises so that I
> don't have to bother with additional (recursive?) calls of .then().

If I have a synchronous hash table, I really want the following
property (in some cases you'd need a different equivalence predicate,
but that's not relevant here):

    table.set(k,v);
    assert(v === table.get(k));

The equivalent for an async hash table with callbacks is:

    table.set(k,v);
    table.get(k, function(v2) { assert(v === v2); });

or with promises:

    table.set(k,v);
    table.get(k).then(function(v2) { assert(v === v2); });

What you're suggesting is to break this invariant in the case that `v`
is a promise. That doesn't sound "great" to me.

Sam

Received on Tuesday, 7 May 2013 22:16:57 UTC