Re: A Challenge Problem for Promise Designers (was: Re: Futures)

2013/5/21 Andreas Rossberg > What's your definition of "entirely transparent" then? Or in other > words, what if I use 'promise' outside a when? > I clarified this with Andreas in person, but FTR: "entirely transparent" is indeed the wrong word to describe E promises. For context, E has two mes

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On 20 May 2013 14:15, Tom Van Cutsem wrote: > 2013/4/26 Andreas Rossberg >> >> I'm not sure if your description of E is accurate -- I'd find that >> surprising. It _is_ a perfectly sensible design to have transparent >> futures that you can just use in place of the value they eventually >> get re

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

(catching up on old threads, sorry for the asynchrony [no puns intended ;-)]) On 26 April 2013 12:19, David Bruant wrote: > > I have read somewhere (I can't remember where, hopefully MarkM will > confirm > > or say if I imagined it) that in E, if a variable contains a promise and > > this promis

Re: Futures

On Sat, Apr 27, 2013 at 1:59 AM, Alex Russell wrote: > On Friday, April 26, 2013, Tab Atkins Jr. wrote: > >> On Fri, Apr 26, 2013 at 12:24 PM, Alex Russell >> wrote: >> > On Apr 26, 2013 8:33 PM, "Tab Atkins Jr." wrote: >> >> On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith >> >> wrote: >> >> > Ac

Re: Futures

On Friday, April 26, 2013, Tab Atkins Jr. wrote: > On Fri, Apr 26, 2013 at 12:24 PM, Alex Russell > > > wrote: > > On Apr 26, 2013 8:33 PM, "Tab Atkins Jr." > > > > wrote: > >> On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith > >> > > > >> wrote: > >> > Actually, I may have gotten it terribly wro

RE: Futures

rg>; Norbert Lindenberg<mailto:w...@norbertlindenberg.com>; Markus Lanthaler<mailto:markus.lantha...@gmx.net>; EcmaScript<mailto:es-discuss@mozilla.org> Subject: Re: Futures If resolved called the thenable's then() with accept and reject, it would only unwrap one layer. Good spec

Re: Futures

On Fri, Apr 26, 2013 at 11:44 AM, Juan Ignacio Dopazo wrote: > 2013/4/26 Tab Atkins Jr. >> >> On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith >> wrote: >> > Actually, I may have gotten it terribly wrong (apologies). In my >> > prototype >> > implementation, the following: >> > >> > Future.acc

Re: Futures

> > The difference would only surface when testing that case. > > Not quite. You can still have thenables that call `onFulfilled` with > another thenable, to any depth. You can also insert a real promise at the > end of any-length thenable chain. I understand now. Essentially, in the test you cr

RE: Futures

From: Kevin Smith [zenpars...@gmail.com] >>> Yes, sorry. It will on version 1.1: >>> https://github.com/promises-aplus/promises-spec/#the-promise-resolution-procedure >> To clarify: in 1.0, the behavior of returning a thenable was highly >> underspecified, in part because of a lack of clarity a

Re: Futures

> > > Yes, sorry. It will on version 1.1: > https://github.com/promises-aplus/promises-spec/#the-promise-resolution-procedure > > To clarify: in 1.0, the behavior of returning a thenable was highly > underspecified, in part because of a lack of clarity about promises vs. > thenables. In 1.1, return

RE: Futures

From: Juan Ignacio Dopazo [dopazo.j...@gmail.com] > 2013/4/26 Kevin Smith Oops yeah. I guess that should be fixed. :/ >>> Fixing that would break compatibility with Promises/A+. To remain >>> compatible with A+ and unwrap only one layer, the spec would need a way to >>> discern promis

Re: Futures

On Fri, Apr 26, 2013 at 12:24 PM, Alex Russell wrote: > On Apr 26, 2013 8:33 PM, "Tab Atkins Jr." wrote: >> On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith >> wrote: >> > Actually, I may have gotten it terribly wrong (apologies). In my >> > prototype >> > implementation, the following: >> > >> >

Re: Futures

2013/4/26 Kevin Smith > > Oops yeah. I guess that should be fixed. :/ >>> >> >> Fixing that would break compatibility with Promises/A+. To remain >> compatible with A+ and unwrap only one layer, the spec would need a way to >> discern promises from thenables. >> > > I don't think so. It has no

Re: Futures

On Apr 26, 2013 8:33 PM, "Tab Atkins Jr." wrote: > > On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith wrote: > > Actually, I may have gotten it terribly wrong (apologies). In my prototype > > implementation, the following: > > > > Future.accept(Future.resolve(1)).then(value => { > > > >

Re: Futures

> Oops yeah. I guess that should be fixed. :/ >> > > Fixing that would break compatibility with Promises/A+. To remain > compatible with A+ and unwrap only one layer, the spec would need a way to > discern promises from thenables. > I don't think so. It has no bearing on Promises/A+, because A+ d

Re: Futures

2013/4/26 Anne van Kesteren > > If resolve called the thenable's then() with accept and reject, it would > only unwrap one layer. > > Oops yeah. I guess that should be fixed. :/ > Fixing that would break compatibility with Promises/A+. To remain compatible with A+ and unwrap only one layer, th

Re: Futures

On Fri, Apr 26, 2013 at 7:44 PM, Juan Ignacio Dopazo wrote: > I think Kevin's assertion is correct. According to the spec, callbacks are > wrapped in something called a "future wrapper callback". When a promise is > returned from the callback, the wrapper does this: > >> Let value be the result of

Re: Futures

> If resolved called the thenable's then() with *accept *and reject, it > would only unwrap one layer. > > Good spec googles (I think). I just whiteboarded it and came to the same conclusion. Does anyone else have a prototype implementation they can run this program on? { Kevin } ___

Re: Futures

On Fri, Apr 26, 2013 at 7:25 PM, Kevin Smith wrote: > Future.accept(Future.resolve(1)).then(value => { > > console.log(value !== 1); > return Future.accept(Future.resolve(1)); > > }).then(value => { > > console.log(value === 1); > }); > > logs > > - true > - tru

Re: Futures

2013/4/26 Tab Atkins Jr. > On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith > wrote: > > Actually, I may have gotten it terribly wrong (apologies). In my > prototype > > implementation, the following: > > > > Future.accept(Future.resolve(1)).then(value => { > > > > console.log(value !=

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

On Apr 26, 2013 1:03 PM, "Domenic Denicola" wrote: > > From: Tab Atkins Jr. [jackalm...@gmail.com] > > > The need for this will decrease now that DOM Futures exist, and libraries switch to using those (or a subclass of them) rather than rolling bespoke promises. > > Last I heard, jQuery has commit

Re: Futures

On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith wrote: > Actually, I may have gotten it terribly wrong (apologies). In my prototype > implementation, the following: > > Future.accept(Future.resolve(1)).then(value => { > > console.log(value !== 1); > return Future.accept(Future.r

Re: Futures

Actually, I may have gotten it terribly wrong (apologies). In my prototype implementation, the following: Future.accept(Future.resolve(1)).then(value => { console.log(value !== 1); return Future.accept(Future.resolve(1)); }).then(value => { console.log(value ===

Re: Futures

On Fri, Apr 26, 2013 at 11:03 AM, Kevin Smith wrote: > The current DOM spec, in code: Or, much more simply: * Future.accept takes a Foo and returns a Future. * Future.resolve takes either a Foo or a Future. In either case, it returns a Future. * In Future.then(cb), the cb is expected to have the

Re: Futures

The current DOM spec, in code: Future.resolve(1).then(value => { value === 1; // Return a non-promise return 2; }).then(value => { value === 2; // Return a promise for a non-promise return Future.resolve(3); }).then(value => {

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 10:03 AM, Domenic Denicola wrote: > From: Tab Atkins Jr. [jackalm...@gmail.com] >> The need for this will decrease now that DOM Futures exist, and libraries >> switch to using those (or a subclass of them) rather than rolling bespoke >> promises. > > Last I heard, jQuery

Re: Futures

On Fri, Apr 26, 2013 at 9:01 AM, David Sheets wrote: > Domenic points out > > that DOM Futures currently do a recursive resolution which seems to > violate these equivalences. I also don't see anything about these > equ

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

From: Tab Atkins Jr. [jackalm...@gmail.com] > The need for this will decrease now that DOM Futures exist, and libraries > switch to using those (or a subclass of them) rather than rolling bespoke > promises. Last I heard, jQuery has committed to never switching their promises implementation to

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 8:45 AM, David Sheets wrote: >>> Could you point me to some code that needs dynamic flattening? >> >> From >> https://github.com/promises-aplus/promises-spec/issues/101#issuecomment-16657518 >> >>> ```js >>> var promise = getDataFromServerUsingQ().then(function (data) { >>

Re: Futures (was: Request for JSON-LD API review)

s-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] > On Behalf Of Dean Landolt > Sent: Wednesday, April 24, 2013 12:09 PM > To: Tab Atkins Jr. > Cc: Mark S. Miller; es-discuss > Subject: Re: Futures (was: Request for JSON-LD API review) > > > > > On We

Re: Futures

On Tue, Apr 23, 2013 at 11:30 PM, Tab Atkins Jr. wrote: > On Tue, Apr 23, 2013 at 11:25 AM, David Sheets wrote: >> On Tue, Apr 23, 2013 at 7:02 PM, Tab Atkins Jr. wrote: >>> On Tue, Apr 23, 2013 at 6:12 AM, David Bruant wrote: Anyway, my point was that there exist libraries in which "then"

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 4:03 PM, Domenic Denicola wrote: > From: David Sheets [kosmo...@gmail.com] > >> Why is there a semantic distinction between my thenables and your thenables? > > Because your thenables are not to be trusted! They could do pathological > things like jQuery, or conceptually i

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 3:19 AM, David Bruant wrote: > Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit : >> On 26 April 2013 10:54, David Bruant wrote: >>> The Priority of Constituencies [1] asks us to be remain careful about >>> theoretical standpoints. How does the theoretical par

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

From: David Sheets [kosmo...@gmail.com] > Why is there a semantic distinction between my thenables and your thenables? Because your thenables are not to be trusted! They could do pathological things like jQuery, or conceptually incoherent things like thenables-for-thenables. Sanitation at the b

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 3:27 PM, Domenic Denicola wrote: > From: David Sheets [kosmo...@gmail.com] > >> From my reading, DOM Futures doesn't state anything about resolution >> semantics, to its detriment, but abstracts those semantics behind >> `FutureResolver`. > > This is not correct. See "Let

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

> > > Promise/A+ does not prohibit promises for promises. But in practice the > problem is recognizing what is a promise. > I would say rather that we have two orthogonal, but highly interfering issues: 1. Do we allow promises-(for-promises)+? 2. How do we recognize a promise type within the "res

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

From: David Sheets [kosmo...@gmail.com] > From my reading, DOM Futures doesn't state anything about resolution > semantics, to its detriment, but abstracts those semantics behind > `FutureResolver`. This is not correct. See "Let resolve be a future callback for the context object and its resol

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 3:20 PM, David Sheets wrote: >> 2013/4/26 Kevin Smith >>> >>> What exactly is the controversy here? > > I believe the controversy is over the number of resolution iterations > for a given wrapped value. > >>> I think we all agree with the semantics of "then" as specified i

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

> 2013/4/26 Kevin Smith >> >> What exactly is the controversy here? I believe the controversy is over the number of resolution iterations for a given wrapped value. >> I think we all agree with the semantics of "then" as specified in >> Promises/A+. (If not, then we have a really big problem!)

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

From: David Bruant [bruan...@gmail.com] > Thoughts? Since this entire problem seems predicated on Claus's misunderstanding of the term "thenable," which apparently has no basis in real libraries but instead entirely in wishful thinking, it might be more prudent for him to use the term "monad"

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Le 26/04/2013 15:47, Claus Reinke a écrit : My own argument is not for nested futures themselves, but (1) for futures to offer the same interface (.of, .then) as other thenables, which (2) implies that there is to be no implicit lifting or flattening in .then. For promises, I don't expect to u

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

Bruant Cc: Mark S. Miller; es-discuss Subject: Re: A Challenge Problem for Promise Designers (was: Re: Futures) > Can you point to any code in wide use that makes use of this > "thenables = monads" idea you seem to be implicitly assuming? > Perhaps some of this "generic t

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Can you point to any code in wide use that makes use of this "thenables = monads" idea you seem to be implicitly assuming? Perhaps some of this "generic thenable library code"? I have never seen such code, whereas the use of "thenable" to mean "object with a then method, which we will try to tre

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I'm still wading through the various issue tracker threads, but only two concrete rationales for flattening nested Promises have emerged so far: 1 "library author doesn't want nested Promises." 2 crossing Promise library boundaries can create unwanted nesting Perhaps you didn't read my post then?

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

2013/4/26 Kevin Smith > What exactly is the controversy here? > > I think we all agree with the semantics of "then" as specified in > Promises/A+. (If not, then we have a really big problem!) > Promise/A+ does not prohibit promises for promises. But in practice the problem is recognizing what i

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 9:28 AM, Alex Russell wrote: > Yes, you do. > Mark or Domenic, is the point about Q true as well? (That it could, in principle, provide something like Future.accept, but it chooses not to.) Just wanted to check before I say somethin' foolish : ) { Kevin } ___

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Yes, you do. On Apr 26, 2013 2:54 PM, "Kevin Smith" wrote: > What exactly is the controversy here? > > I think we all agree with the semantics of "then" as specified in > Promises/A+. (If not, then we have a really big problem!) > > If so, then the only real controversy is whether or not the API

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

What exactly is the controversy here? I think we all agree with the semantics of "then" as specified in Promises/A+. (If not, then we have a really big problem!) If so, then the only real controversy is whether or not the API allows one to create a promise whose eventual value is itself a promis

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On 26 April 2013 12:19, David Bruant wrote: >> In particular, irregularity and exceptions become a pain >> when you start building abstractions, or plug together abstractions. >> In other words, regularity is a prerequisite for what some people >> (including me) like to call "compositionality". >>

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

[adding public-script-coord and Anne] Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit : On 26 April 2013 10:54, David Bruant wrote: The Priority of Constituencies [1] asks us to be remain careful about theoretical standpoints. How does the theoretical part translates into helpin

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On 26 April 2013 10:54, David Bruant wrote: > The Priority of Constituencies [1] asks us to be remain careful about > theoretical standpoints. How does the theoretical part translates into > helping users? authors (more than what I described at [2] which is derived > from my own experience)? imple

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Le 26/04/2013 03:39, Tab Atkins Jr. a écrit : On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble wrote: So what's an example that motivates you to want to build a tower of promise types? The main one I know of is the implementation (not use of) higher-order collection constructs that use promises i

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

A Future for a Future seems like a corner case compared to the broader simplicity of an implicit unwrap. The argument is not about whether Future> is a common case. The Argument is that Future<...> and Array<...> and Optional<...> and things that may raise catchable errors and other types have

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Le 26/04/2013 00:21, Claus Reinke a écrit : I'm still wading through the various issue tracker threads, but only two concrete rationales for flattening nested Promises have emerged so far: 1 "library author doesn't want nested Promises." 2 crossing Promise library boundaries can create unwanted

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Something that wasn't clear to me personally until reading the last few posts: I suspect that some of the negative reaction to unwrapping/wrapping, and the suggestion that Future> is a meaningful construct, comes from the mindset of static typing - not in the sense that static types themselves are

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Thu, Apr 25, 2013 at 8:52 PM, Mark S. Miller wrote: > So how does the semantics of Q(x) differ from the semantics of > Future.resolve(x) ? I suppose you tell me? You offered, as an example of why recursive unwrapping was useful, some example code that used Q(val).then(). The surrounding expl

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I’m not sure I fully grok the use cases for FutureResolver#accept and having Future>. Having to call an Unwrap extension method on a Task> in .NET is an unfortunate necessity. Also, since Future#then implicitly resolves a future it is difficult to return a Future> from a then. In every case w

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

So how does the semantics of Q(x) differ from the semantics of Future.resolve(x) ? On Thu, Apr 25, 2013 at 8:38 PM, Tab Atkins Jr. wrote: > On Thu, Apr 25, 2013 at 6:49 PM, Mark S. Miller > wrote: > > What is the semantics of Future.resolve? > > Creates an already-accepted future using the "res

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Thu, Apr 25, 2013 at 6:49 PM, Mark S. Miller wrote: > What is the semantics of Future.resolve? Creates an already-accepted future using the "resolve" algorithm, which is the same magic that happens to the return value of a .then() callback (if it's a future, it adopts the state; otherwise, it

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

What is the semantics of Future.resolve? On Thu, Apr 25, 2013 at 6:45 PM, Tab Atkins Jr. wrote: > On Thu, Apr 25, 2013 at 8:57 AM, Mark Miller wrote: > > The refactoring of putting the "Q(srcP).then" in the deposit method > > unburdened all clients such as the buy method above from doing this

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Thu, Apr 25, 2013 at 8:57 AM, Mark Miller wrote: > The refactoring of putting the "Q(srcP).then" in the deposit method > unburdened all clients such as the buy method above from doing this > postponement themselves. The new buy method on page 13 now reads: > > buy: (desc, paymentP) => { >

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble wrote: > So what's an example > that motivates you to want to build a tower of promise types? The main one > I know of is the implementation (not use of) higher-order collection > constructs that use promises internally (e.g., the implementation of ma

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Hmm. I agree that the example code isn't relevant to JavaScript. For background, the last time issues this came up for me was in the context of a language keyword (which had other interesting but unrelated trade offs), where it really did impose that interaction (call sites had to declare that the

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Thu, Apr 25, 2013 at 4:30 PM, Dean Tribble wrote: > I've built multiple large systems using promises. A fundamental distinction > that must be clear to the client of a function is whether the function "goes > async": does it return a result that can be used synchronously or will the > result o

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

minority libraries who have misinterpreted > what it means to be a thenable. > -- > From: Claus Reinke > Sent: 4/25/2013 18:21 > To: Mark Miller ; David Bruant > Cc: Mark S. Miller ; es-discuss > Subject: Re: A Challenge Problem for Promise Designe

RE: A Challenge Problem for Promise Designers (was: Re: Futures)

> Cc: Mark S. Miller<mailto:erig...@google.com>; es-discuss<mailto:es-discuss@mozilla.org> Subject: Re: A Challenge Problem for Promise Designers (was: Re: Futures) I'm still wading through the various issue tracker threads, but only two concrete rationales for flattening nested

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I'm still wading through the various issue tracker threads, but only two concrete rationales for flattening nested Promises have emerged so far: 1 "library author doesn't want nested Promises." 2 crossing Promise library boundaries can create unwanted nesting There is little to be said about 1,

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

That's a good point. Neither the E language nor the Q library allow subclassing of promises. The motivating reason in both cases is the security properties that promises must provide. But you're right -- this is an additional benefit. Promises/A+, being a minimalistic codification of broader agreem

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I think flattening is also tied inextricably to the fact that promises are a featureless wrapper for values. Nobody cares about promises-as-values because of this featureless-ness. And because they are completely uninteresting as values, programmers can think "straight through" to the eventual va

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I think we see a correlation -- not a 1.0 correlation, but something. Those who've actually used promise libraries with this flattening property find it pleasant. Those who come from either a statically typed or monadic perspective, or have had no experience with flattening promises, generally thi

A Challenge Problem for Promise Designers (was: Re: Futures)

I think we see a correlation -- not a 1.0 correlation, but something. Those who've actually used promise libraries with this flattening property find it pleasant. Those who come from either a statically typed or monadic perspective, or have had no experience with flattening promises, generally thin

Re: Futures

Le 24/04/2013 19:41, Andreas Rossberg a écrit : On 24 April 2013 19:20, Mark S. Miller wrote: On Wed, Apr 24, 2013 at 10:14 AM, Tab Atkins Jr. wrote: Q and similar libraries don't actually assume that a Future> is a Future. Yes it does. Except of course that we call these "promises". Please

Re: Futures (was: Request for JSON-LD API review)

Now, instead of a ducktest for a `then` method the promise check would instead be specified as `instanceof Promise`. Picking a message at random for an interjection, there is something that seems to be missing in this discussion: *Promises are only one kind of thenables (the asynchronous th

RE: Futures (was: Request for JSON-LD API review)

their library for pre- and post- ES6 (or later) versions. From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Dean Landolt Sent: Wednesday, April 24, 2013 12:09 PM To: Tab Atkins Jr. Cc: Mark S. Miller; es-discuss Subject: Re: Futures (was: Request for JSON-L

Re: Futures (was: Request for JSON-LD API review)

On Wed, Apr 24, 2013 at 2:18 PM, Tab Atkins Jr. wrote: > On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola > wrote: > > From: Andreas Rossberg [rossb...@google.com] > >> Mark, could you summarize the rationale for this, or provide a more > specific link to the appropriate bit of the discussion y

RE: Futures (was: Request for JSON-LD API review)

Resending due to a mail error. > -Original Message- > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- > boun...@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 > Subj

Re: Futures (was: Request for JSON-LD API review)

On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola wrote: > From: Andreas Rossberg [rossb...@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 somet

RE: Futures (was: Request for JSON-LD API review)

From: Andreas Rossberg [rossb...@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:

Re: Futures (was: Request for JSON-LD API review)

On 24 April 2013 19:20, Mark S. Miller wrote: > On Wed, Apr 24, 2013 at 10:14 AM, Tab Atkins Jr. > wrote: >> Q and similar libraries don't actually assume that a Future> >> is a Future. > > Yes it does. Except of course that we call these "promises". Please see the > extensive discussions on the

Re: Futures (was: Request for JSON-LD API review)

On Wed, Apr 24, 2013 at 10:14 AM, Tab Atkins Jr. wrote: > On Wed, Apr 24, 2013 at 10:10 AM, Ron Buckton > wrote: > > I'm not yet sold on having both accept and resolve on the resolver. In > the .NET world, a Task for a Task (e.g. Task>) is just that, and > you have to unwrap the Task with someth

Re: Futures (was: Request for JSON-LD API review)

On Wed, Apr 24, 2013 at 10:10 AM, Ron Buckton wrote: > I'm not yet sold on having both accept and resolve on the resolver. In the > .NET world, a Task for a Task (e.g. Task>) is just that, and you have > to unwrap the Task with something like a TaskCompletionSource, which is > explicitly like

RE: Futures (was: Request for JSON-LD API review)

> -Original Message- > From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] > On Behalf Of Anne van Kesteren > Sent: Wednesday, April 24, 2013 7:08 AM > To: Ron Buckton > Cc: Tab Atkins Jr.; es-discuss > Subject: Re: Futures (was: Request for JSON-LD AP

Re: Futures

On Tue, Apr 23, 2013 at 10:38 PM, Brendan Eich wrote: > Tab Atkins Jr. wrote: >> I still think that burdening the >> call-site with the need to pull a future out of the object like that >> (even though, yes, the object itself will be optimized out by future >> VMs) is too much. > > > This started

Re: Futures (was: Request for JSON-LD API review)

On Wed, Apr 17, 2013 at 4:46 PM, Anne van Kesteren wrote: > I don't find the whole who owns what discussions very interesting to > be honest. If it was up to me JavaScript would just be part of the W3C > and we would not have to deal with that layer of distraction. I got some private feedback tha

Re: Futures (was: Request for JSON-LD API review)

On Wed, Apr 24, 2013 at 1:16 AM, Ron Buckton wrote: > * Future#then (tentatively adds the options argument in my proposal for > forcing synchronous execution of continuation) > * Future#done (tentatively adds the options argument in my proposal for > forcing synchronous execution of continuation

Re: Futures

2013/4/23 Ron Buckton > I fall mostly under the "native futures should not implicitly chain > library futures" camp. Its easy enough to write: > > var p = // some thenable > return new Future(resolver => p.then(resolver.resolve, resolver.reject); > That looks terrible inefficient, so in our impl

Re: Futures

Le 20/04/2013 16:03, Brendan Eich a écrit : David Bruant wrote: Le 20/04/2013 15:17, Brendan Eich a écrit : Tab Atkins Jr. wrote: It would be so nice if JS had multiple return values, so we could let cancellable future-returning APIs just return a naked resolver as their second value, Hello,

Re: Futures

Le 24/04/2013 11:27, Alex Russell a écrit : Sorry for the late post. Just wanted to agree with you assessment of the landscape and options. We should not let theoretical purity poison the utility of this feature. Futures as currently spec'ed misbehave in the presence of objects with a "then

Re: Futures

On Apr 22, 2013 5:29 PM, "Mark S. Miller" wrote: > > On Mon, Apr 22, 2013 at 8:16 AM, Domenic Denicola < dome...@domenicdenicola.com> wrote: >> >> From: David Bruant [bruan...@gmail.com] >> >> > Especially given that it's only for a transitioning period where native (or polyfilled) have to cohabit

Re: Futures

Sorry for the late post. Just wanted to agree with you assessment of the landscape and options. We should not let theoretical purity poison the utility of this feature. On Apr 22, 2013 4:15 PM, "Mark S. Miller" wrote: > On Mon, Apr 22, 2013 at 5:37 AM, David Bruant wrote: > >> Le 22/04/2013 14:

Re: Futures

Tab Atkins Jr. wrote: I still think that burdening the call-site with the need to pull a future out of the object like that (even though, yes, the object itself will be optimized out by future VMs) is too much. This started (for me) when you wrote: > It would be so nice if JS had multiple retu

Re: Futures

On Tue, Apr 23, 2013 at 6:41 PM, Brendan Eich wrote: > Tab Atkins Jr. wrote: >> Yeah, that's fine when you're explicitly invoking something that needs >> to return two objects. > > You didn't grok what I wrote. The object is erased, and the value(s) are > returned to the caller depending on the pa

Re: Futures

Eich Sent: Tuesday, April 23, 2013 6:41 PM To: Tab Atkins Jr. Cc: es-discuss Subject: Re: Futures Tab Atkins Jr. wrote: On Sat, Apr 20, 2013 at 6:17 AM, Brendan Eich wrote: Tab Atkins Jr. wrote: It would be so nice if JS had multiple return values, so we could let cancellable future-returning

RE: Futures

Eich Sent: Tuesday, April 23, 2013 6:41 PM To: Tab Atkins Jr. Cc: es-discuss Subject: Re: Futures Tab Atkins Jr. wrote: > On Sat, Apr 20, 2013 at 6:17 AM, Brendan Eich wrote: >> Tab Atkins Jr. wrote: >>> It would be so nice if JS had multiple return values, so we could >>

Re: Futures

Brendan Eich wrote: The object is erased Meaning, not allocated. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

Tab Atkins Jr. wrote: On Sat, Apr 20, 2013 at 6:17 AM, Brendan Eich wrote: Tab Atkins Jr. wrote: It would be so nice if JS had multiple return values, so we could let cancellable future-returning APIs just return a naked resolver as their second value, Hello, destructuring: let{ proxy, revo

Re: Futures (was: Request for JSON-LD API review)

On Tue, Apr 23, 2013 at 5:16 PM, Ron Buckton wrote: > [...] a Future-based AMD module loader I'm tinkering with. In that case, you might want to look at < http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#amd_loader_lite> and < https://code.google.com/p/google-caja/source/browse/trunk/sr

RE: Futures (was: Request for JSON-LD API review)

a Future#finally as well, as I've found some use cases in a Future-based AMD module loader I'm tinkering with. Ron -Original Message- From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Sent: Friday, April 19, 2013 6:42 PM To: Ron Buckton Cc: Kevin Gadd; es-discuss Subject: Re

Re: Futures

On Tue, Apr 23, 2013 at 11:25 AM, David Sheets wrote: > On Tue, Apr 23, 2013 at 7:02 PM, Tab Atkins Jr. wrote: >> On Tue, Apr 23, 2013 at 6:12 AM, David Bruant wrote: >>> Anyway, my point was that there exist libraries in which "then" is a >>> function and the object with this function isn't a p

RE: Futures

Lindenberg<mailto:w...@norbertlindenberg.com>; Markus Lanthaler<mailto:markus.lantha...@gmx.net>; es-discuss<mailto:es-discuss@mozilla.org> Subject: Re: Futures I would love to see this, but best I can tell it can't be a straitforward polyfill. The necessary infrastruc

  1   2   >