- From: David Sheets <kosmo.zb@gmail.com>
- Date: Tue, 23 Apr 2013 19:25:48 +0100
- To: "Tab Atkins Jr." <jackalmage@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 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... > 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" }? Will Futures be associative and have left and right identity between bind ("then") and return ("of")? Will this be specified explicitly? 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)? Thanks, David
Received on Tuesday, 23 April 2013 18:27:15 UTC