Futures (was: Request for JSON-LD API review)
rbuckton at chronicles.org
Wed Apr 24 11:52:19 PDT 2013
Resending due to a mail error.
> -----Original Message-----
> From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
> bounces at mozilla.org] On Behalf Of Tab Atkins Jr.
> Sent: Wednesday, April 24, 2013 11:18 AM
> To: Domenic Denicola
> Cc: Mark S. Miller; es-discuss
> Subject: Re: Futures (was: Request for JSON-LD API review)
> On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola
> <domenic at domenicdenicola.com> wrote:
> > From: Andreas Rossberg [rossberg at google.com]
> >> Mark, could you summarize the rationale for this, or provide a more
> specific link to the appropriate bit of the discussion you are referring to?
> > I'm not Mark, and he might have something more specific in mind, but
> > this
> summary was pretty helpful:
> > https://gist.github.com/ForbesLindesay/5392612
> These aren't very good reasons, unfortunately. :/
> The JQP... problem can be solved by a single "flatten" operation added
> to the API. This is a totally reasonable operation, same as it would be for
> The identify function for monads is the monadic lift function -
> Future.accept() in the case of Futures. The only reason passing the
> identity function in *at all* works is because we have special magic
> that lets authors return non-Futures from the callbacks (which I think
> is a good idea, mind you). It's not actually an identity function, though.
> The synchronous analog objections don't make sense. The analogue is
> returning the Error object itself, which could certainly be reasonable at
> Recursive unwrapping is like making "return new Error()"
> identical to "throw new Error()". I don't even understand the
> attempted analogy with f() and g() - chaining takes care of unwrapping
> in all reasonable cases like that. Similarly, I don't think the Stack
> Frame analogy has been well- thought-out - chaining Futures is the
> analogy to stack frames, and that works just fine.
> I'm not sure what the Parametricity Argument is.
> However, all of this falls before the simple fact that recursive
> unwrapping means that *no one can ever create any object with a
> .then() method on it ever again*. If .then() is treated as the normal
> monadic operation over Futures (that is, it unwraps one layer of its
> return value), then you can safely return objects with a .then()
> method by wrapping them in a Future with a method like
> Future.accept(). (You can safely do this to *all* values unless
> you're explicitly asking for chaining to happen.)
Given the collision with possible existing uses of "then", it might be better to
either use a symbol to brand an object as a thenable, or use a symbol to
define a compatible then (or done) -like method similar to @iterator. It
would only be necessary to import and apply the symbol to interoperate with
a native Future, and subclasses of Future would implicitly have support.
Alternatively, only "recursively unwrap" native Futures or Future subclasses,
and require an explicit coercion using something like Future.of.
More information about the es-discuss