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

On Tue, May 7, 2013 at 11: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.

Could you please explain which part of the promise concept makes this
eager evaluation necessary?

> 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 have a promise library on my disk that does provide this ability. It
is a trivial extension.

>>> 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().
>
> One reason that was brought up was that if getting the promise from
> the hash is fast, but getting the value from the promise is slow, then
> the caller might want to know about the intermediate step of having
> the promise from the hash.
>
> So essentially this is a way of modelling progress by having several
> nested promises. Each unwrapping callback represents an indication of
> progress.
>
> I'm not sure if this is a great way of modelling progress though. The
> ProgressFuture that has been proposed seems like a more robust
> solution to me.

If you're happy with ProgressFuture, that's great. If someone else
wants to use nested promises to achieve this, will you tell them "you
can't, that's not 'robust'"?

The properly polymorphic promises that have been proposed seem like a
more robust solution to me.

David

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