Resending due to a mail error. > -----Original Message----- > From: [email protected] [mailto:es-discuss- > [email protected]] 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 > <[email protected]> wrote: > > From: Andreas Rossberg [[email protected]] > >> 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 Arrays. > > 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 > times. > 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.
Ron _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
