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

On Thu, May 2, 2013 at 4:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, May 2, 2013 at 3:39 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
>> The issue of whether a way to create promises for promises is an important one, and I fear that if DOMFuture continues to allow it, speculative-TC39-promises will be forced to include recursive implicit thenable assimilation in order to prevent such entities, which have made it into the wild of the web via DOMFutures, from infecting the program.
>
> Yeah. I kind of wish that we simply removed the Future.accept
> function. As far as I know no use cases for it has been brought
> forward, and it introduces a decent chunk of complexity.

Can you elaborate on the complexity?  Based on the Futures spec, it
seems to be pretty simple.

> The one use case I've come across is if we create a FunctionFuture
> interface to allow for background compilation of large JS bodies, and
> if we also convert IndexedDB to use Futures, and if we also enable
> storing FunctionFutures in IndexedDB as a way to enable not having to
> recompile the JS code for backends that can support storing the
> compiled code.
>
> In that scenario having Future.accept would allow IndexedDB to return
> the FunctionFuture rather than returning the compiled Function object.
> Having to return the Function object could mean that you tie the
> operation of reading from the database with the operation of compiling
> the JS code which is a problem if you're also doing other operations
> against the database that shouldn't be blocked by a lengthy JS
> compilation.
>
> But there's a lot of "ifs" and "coulds" in the above. So I think it's
> a use-case that's too early to worry about.

This is, generically, the ability to compose Futures without having to
worry about what's inside of them.  You've come up with one example.
The community of functional programmers has shown that, in general,
this kind of thing is very often useful, and is captured in the
abstract pattern of "monad".

Mark has argued against nesting, based on his experience with E, where
promises are featureless wrappers that disappear as soon as they're no
longer needed.  We can't do the disappearing trick in JS, so that
opens us up to the possibility of embracing other abstractions, like
Futures-as-monads, which is accomplished pretty trivially by simply
making Futures nestable and making resolve semantics just do monadic
"join", which flattens two Future layers into one (not N future layers
into one).

In <http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0279.html>
and other posts in that thread, I tried to pin down why recursive
flattening of native promises would be useful, and nobody could answer
me.  Domenic responded with
<http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0280.html>
that multi-level (recursive) flattening is only useful for
assimilation.

It occurs to me now that Domenic may have been doing the same "nested
promises can't exist, so of course you (trivially) don't need
recursive flattening for them" thing that Mark did earlier in this
thread, in which case >_<.


>> But that aside, the issue of whether to assimilate thenables implicitly or explicitly can be considered separately from DOMFuture's promises-for-promises abilities.
>
> I agree. Though several people seem to feel that the two is connected
> somehow. Though I haven't understood why.

Yes, they are independent, though close-together in argument-space.  ^_^

~TJ

Received on Thursday, 2 May 2013 23:42:53 UTC