W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Futures

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 23 Apr 2013 15:30:14 -0700
Message-ID: <CAAWBYDDyG=36daF9F9R3DwQc=xkts6ru5xewyAgGx-v2EMZXeg@mail.gmail.com>
To: David Sheets <kosmo.zb@gmail.com>
Cc: David Bruant <bruant.d@gmail.com>, Dean Landolt <dean@deanlandolt.com>, Brendan Eich <brendan@mozilla.com>, "Mark S. Miller" <erights@google.com>, Douglas Crockford <douglas@crockford.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Norbert Lindenberg <w3@norbertlindenberg.com>, Markus Lanthaler <markus.lanthaler@gmx.net>, EcmaScript <es-discuss@mozilla.org>
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.

> If libraries are able to create Future-like objects that interoperate
> with built-in Futures, will they be required (ha) to satisfy these
> equivalences (associativity, identity)?

"Required" in the same sense that Haskell "requires" that things which
implement the Monad typeclass satisfy the monad laws - nothing
enforces the restrictions, but things might be wonky if you don't.

Received on Tuesday, 23 April 2013 22:31:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC