Re: Futures

On Tue, Apr 23, 2013 at 11:30 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Apr 23, 2013 at 11:25 AM, David Sheets <kosmo.zb@gmail.com> wrote:
>> On Tue, Apr 23, 2013 at 7:02 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Tue, Apr 23, 2013 at 6:12 AM, David Bruant <bruant.d@gmail.com> wrote:
>>>> Anyway, my point was that there exist libraries in which "then" is a
>>>> function and the object with this function isn't a promise. These libraries
>>>> will end up in a terrible confusion when used with Futures.
>>>> You think you're resolving a future with an object and... oops! the built-in
>>>> Future algorithm confused your object for a promise. Suddenly, not only are
>>>> you not resolving your promise with the value, but your .then method is
>>>> called unexpectedly.
>>>
>>> Agreed.  I'll note, though, that if the semantics of .resolve() are
>>> non-recursive (it strips off one layer of promise/future, but no
>>> further), then this becomes somewhat less of an issue, as it can be
>>> worked around - if you want to return something that's not a promise,
>>> just wrap it in a fulfilled promise (via some sugar function - I've
>>> proposed such in www-dom).  That wrapper will be unwrapped straight
>>> away, and the future accepted with the value within.
>>
>> <http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0051.html>?
>> Future.of == "monadic return"? Doesn't seem too sugary...
>
> It's sugar because you already achieve it with existing functionality.
>  Instead of "var f = Future.of(v);", you can write:
>
> var f = new Future(function(r) { r.accept(v); });
>
> or, in ES6:
>
> var f = new Future(r=>r.accept(v));
>
> However, I think it's sufficiently useful sugar that it bears adding.
>
> And yes, it's the monadic return.
>
>>> The big problem only arrives if you both treat all thenables as
>>> promises/futures, *and* have recursive resolve semantics, because then
>>> you can't *ever* return a non-promise with a .then() method.
>>>
>>> I'd prefer that resolve only strip away a branded future, not an
>>> arbitrary thenable, and for there to be a way to brand a thenable as a
>>> future.  That way, using other-library promises just requires one trip
>>> through the branding function and they can interoperate.  Existing
>>> libraries tend to expose the same mechanism already, so that the
>>> other-library promises expose all the proper methods of the "main"
>>> library.
>>>
>>> But I want non-recursive resolve *more*, and if I was forced to choose
>>> one, would take monadic resolve over branded futures.
>>
>> "non-recursive resolve" == "monadic run" == "comonadic extract"?
>> "recursive resolve" == "monadic run" compose { fixpoint of "monadic join" }?
>
> Yes.  (Comonadic "extend", not "extract".)
>
>> Will Futures be associative and have left and right identity between
>> bind ("then") and return ("of")? Will this be specified explicitly?
>
> Yes, they do.  It's part of the basic mechanics of the two functions.

Domenic points out
<http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0234.html>
that DOM Futures currently do a recursive resolution which seems to
violate these equivalences. I also don't see anything about these
equivalences specified explicitly.

Notably, it seems that DOM Futures is written in such a way as to
abstract over resolvers though I don't see how to provide an
author-defined FutureResolver. Can I simply construct a JavaScript
object that quacks like FutureResolver and use the FutureInit
constructor?

Thanks,

David

Received on Friday, 26 April 2013 16:02:36 UTC