Re: ES6 __proto__ test suite

Le 24/04/2013 20:08, Rick Waldron a écrit : On Wed, Apr 24, 2013 at 6:14 AM, David Bruant > wrote: Le 23/04/2013 23:47, Rick Waldron a écrit : On Tue, Apr 23, 2013 at 1:34 PM, David Bruant mailto:bruan...@gmail.com>> wrote: Hi, Based on recen

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)

Be it Promise or Future, instanceof won't work across frames. It would likely still require a Future.isFuture/Promise.isPromise just as we need to have Array.isArray now. That is, of course, unless we can use symbols for branding in a fashion that library authors could use without forking their

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 > Subject: Re: Futures (was:

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: ES6 __proto__ test suite

On Wed, Apr 24, 2013 at 6:14 AM, David Bruant wrote: > Le 23/04/2013 23:47, Rick Waldron a écrit : > > On Tue, Apr 23, 2013 at 1:34 PM, David Bruant wrote: > >> Hi, >> >> Based on recent messages on es-discuss, I feel that both es-discuss and >> apparently even TC39 meetings with notes have lef

Re: B.3.1 The __proto__ pseudo property

To clarify, since I was perhaps "somewhat" terse here. :-) print(eval('[{"__proto__": 17}]')[0].hasOwnProperty("__proto__")); print(eval('[{"__proto__":0x17}]')[0].hasOwnProperty("__proto__")); SunSpider uses eval() on JSONish input, so engines have to make that fast. Most/all engines for

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 API review) > > On Wed,

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

Thanks, that makes a lot of sense to me. On Wed, Apr 24, 2013 at 4:36 PM, Mark S. Miller wrote: > The Roadmap will be on the agenda for the upcoming TC39 May meeting. Many > of us want macros eventually, the ES6 module system gives us the stage > separation necessary for clean macros, and I don

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

The Roadmap will be on the agenda for the upcoming TC39 May meeting. Many of us want macros eventually, the ES6 module system gives us the stage separation necessary for clean macros, and I don't recall any objections to eventually including macros if they are clean enough. But macros are a big har

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: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

Le 24/04/2013 17:20, Dean Landolt a écrit : On Wed, Apr 24, 2013 at 11:04 AM, Anne van Kesteren > wrote: On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller mailto:erig...@google.com>> wrote: > Thoughts? I was wondering when operator overloading is planned.

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

On Wed, Apr 24, 2013 at 11:04 AM, Anne van Kesteren wrote: > On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller > wrote: > > Thoughts? > > I was wondering when operator overloading is planned. It would be > great to be able to do things like new URL("http://example.org";) == > new URL("http://exampl

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: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller wrote: > Thoughts? I was wondering when operator overloading is planned. It would be great to be able to do things like new URL("http://example.org";) == new URL("http://example.org/";). -- http://annevankesteren.nl/ __

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

Also, see Peter Hallams part from NodeConf 2011 where he walks through how await works: http://youtu.be/ntDZa7ekFEA?t=17m2s On Wed, Apr 24, 2013 at 10:18 AM, Erik Arvidsson wrote: > On Tue, Apr 23, 2013 at 8:01 AM, Mark S. Miller wrote: > >> Hi Kevin, you are correct that it isn't a co-routine,

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

Is there any chance at all of macros á la sweet.js will be on the agenda for ES7 (or 8)? I would very much like for that to happen to enable even more, and more light-weight, experimentation with and cow-path building for the syntactic language surface. On Sun, Apr 21, 2013 at 5:21 AM, Mark S. M

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

On Tue, Apr 23, 2013 at 8:01 AM, Mark S. Miller wrote: > Hi Kevin, you are correct that it isn't a co-routine, and that it > corresponds to a mechanical CPS rewrite of only the local function itself. > Fortunately, it is *exactly* the same CPS rewrite required to account for > the semantics of ge

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,

Module naming and declarations

The module proposal has made good progress, thanks to the hard work by Dave & Sam. I'm glad to see it close to the home stretch for the ES6 race (some healthy minor controversies on the side notwithstanding :) ). However, there is one central part of the design over which we still do not have agre

Re: ES6 __proto__ test suite

Le 23/04/2013 23:47, Rick Waldron a écrit : On Tue, Apr 23, 2013 at 1:34 PM, David Bruant > wrote: Hi, Based on recent messages on es-discuss, I feel that both es-discuss and apparently even TC39 meetings with notes have left ambiguity in what people u

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: