Re: Single frame continuations proposal

David Herman wrote: We've given this quite a bit of time, and I don't know how far we're going to get in understanding all the details of your proposal. But I think I can address some of my disagreements. 1) I'm skeptical whether the requirement you stated of future-proofing code for async

Re: Single frame continuations using yield keyword with generators compatibility proposal

The key idea of this approach is that when a function is called that contains a yield operator, rather than following a hard-coded prescription to return an generator/iterator object, this triggers a call to the startCoroutine variable (from the current lexical scope) Totally opposed. I don't

Re: Single frame continuations proposal

Greasing the wheels of shared-state concurrency is dangerous and not a good idea for ES. We definitely have not introduced shared-state concurrency Introduced, no-- it's already there. IMO what this does is make it too easy to trip over. You're talking about a use case where clients can

let expressions strawman

Dear all, We've talked about various let-binding forms in the past, and the let-declaration form has pretty wide support. The other two forms proposed for ES4 were more controversial. I've just posted a small strawman proposal for let expressions that brings this down to just one additional

Re: let expressions strawman

f(let (a = getArray()) { if (x.length === 0) throw empty array; = a[0] }) erm, a.length. Like it matters. :) Dave ___ es-discuss mailing list es-discuss@mozilla.org