Re: Promise/Future: asynchrony in 'then'

On Thu, May 2, 2013 at 2:28 PM, Claus Reinke wrote: >>Promise.of(value).then(cb) = cb(value) >>promise.then(Promise.of) = promise > > My interpretation of these laws for promises is that attaching a callback to > a resolved promise should execute that callback synchronously (though the > c

Re: Promise/Future: asynchrony in 'then'

Thanks for the various references and explanations - it took me a while to follow them. So, while discussion is still ongoing on the details (both of how to spec and what to spec), all specs seem to agree on trying to force asynchrony, and on doing something in 'then' to achieve this. I suspec

Re: yield* desugaring

Greets, Thanks for the kind words! And thanks also for the new iteration proposal; it looks great to my ignorant eyes. I'll probably take a look at for-of next. On Thu 02 May 2013 20:07, David Herman writes: >> IMHO yield* should be specified to return the result object as-is, >> without re-b

Re: Module naming and declarations

On 1 May 2013 01:15, Sam Tobin-Hochstadt wrote: > On Mon, Apr 29, 2013 at 9:34 AM, Andreas Rossberg wrote: >> I brought up [removing module declarations] as a "min-max" sort of >> compromise at >> the March meeting, but it did not get much love. And I agree that it >> isn't pretty, although it a

Re: yield* desugaring

Andy Wingo wrote: On Wed 01 May 2013 01:55, David Herman writes: On Apr 30, 2013, at 7:25 AM, Brendan Eich wrote: Andreas Rossberg wrote: And as Andy points out correctly, that raises the question whether having 'close' makes much sense at all. I think we have evolved away from it. Cc'ing

Re: yield* desugaring

Brendan reminded me I never replied to the earlier part of this thread. On Apr 29, 2013, at 8:37 AM, Andy Wingo wrote: > For what it's worth (which is very little) this seems like a decent > plan to me. Actually it's worth a lot to me! Your blog post on StopIteration was part of what got me th

Re: yield* desugaring

On May 2, 2013, at 9:51 AM, David Herman wrote: > On May 2, 2013, at 6:25 AM, Andreas Rossberg wrote: > >> On 1 May 2013 02:06, David Herman wrote: >>> It also has a smell to it: the idea that an expression can cause a return, >>> without the syntactic appearance of `return`. (I'm not opposed

Re: yield* desugaring

On May 2, 2013, at 6:25 AM, Andreas Rossberg wrote: > On 1 May 2013 02:06, David Herman wrote: >> It also has a smell to it: the idea that an expression can cause a return, >> without the syntactic appearance of `return`. (I'm not opposed to the idea >> of being able to return from expressions

Re: Most current Proxy-as-implemented test suite?

On Wed, May 1, 2013 at 11:42 PM, Tom Van Cutsem wrote: > 2013/5/1 Kevin Reid > >> What is the most current test suite available for this variant of >> proxies? So far I have found >> , which seems to be a more >> recent version of what we are currently u

Re: Module naming and declarations

> > > > We don't need to solve the IPDR problem with the core module system. > Instead, we can provide the primitives and see what flourishes. > > And to bring this back around full-circle, once we let go of the requirement to solve the IPDR problem, then the need for lexical modules come back int

Re: Module naming and declarations

On 1 May 2013 22:02, Kevin Smith wrote: > Thanks James, for your input. As an aside, I want to make perfectly clear > that I don't think the AMD approach to module IDs is necessary a bad thing, > or that full "http" URLs are necessarily any better for dependency naming. > > I am arguing that AMD

Re: Module naming and declarations

On 1 May 2013 00:01, David Herman wrote: > On Apr 29, 2013, at 6:34 AM, Andreas Rossberg wrote: > >> ...you are generally assuming the use of some package manager. This >> is a fairly significant assumption, that I wished I had heard being >> made explicit in any of the previous discussions. AFAI

Re: yield* desugaring

On 1 May 2013 02:06, David Herman wrote: > It also has a smell to it: the idea that an expression can cause a return, > without the syntactic appearance of `return`. (I'm not opposed to the idea of > being able to return from expressions -- I still love do-expressions. But I > prefer `return` t

Re: Most current Proxy-as-implemented test suite?

Le 02/05/2013 08:51, Tom Van Cutsem a écrit : 2013/5/1 David Bruant mailto:bruan...@gmail.com>> If anything, I would recommend to move away from the initial proxy design for Caja, because the harmony:proxies API is meant to never see light in the spec (and should probably be removed

Re: Future cancellation

On Thu, May 2, 2013 at 1:40 PM, Bill Frantz wrote: > Upon further reflection, I think the point about premature standardization > stands. FWIW, that answer does not work for the web. If people want a particular API it will be made, shipped, and network effects will prevent us from ever removing i

Re: Future cancellation

On 5/1/13 at 5:43 PM, fra...@pwpconsult.com (Bill Frantz) wrote: On 5/1/13 at 1:37 PM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: Ah, I'm not proposing that we augment the base Future class with cancellation properties. I explicitly used the term "subtype" in the quoted bit above. *Some* o

Re: Most current Proxy-as-implemented test suite?

On 2 May 2013 08:42, Tom Van Cutsem wrote: > 2013/5/1 Kevin Reid >> >> What is the most current test suite available for this variant of >> proxies? So far I have found >> , which seems to be a more >> recent version of what we are currently using, but ha

Re: Future cancellation

On Wed, May 1, 2013 at 7:17 PM, Kevin Smith wrote: > Curious: has this proposed XHR api been published anywhere? My tentative plan is to have a new API that sits on top of http://fetch.spec.whatwg.org/ somehow. (In due course http://xhr.spec.whatwg.org/ will build almost directly on that too, so

RE: Promise/Future: asynchrony in 'then'

I think eventual synchronicity of `then` is just theoretical problem and in practice we face much bigger issues when we force asynchronicity. If we want to have "fast" asynchronicity, then we enter the problem of overloaded recurrence of next tick calls. It was already exposed by popular libraries

Re: yield* desugaring

On Wed 01 May 2013 01:55, David Herman writes: > On Apr 30, 2013, at 7:25 AM, Brendan Eich wrote: > >> Andreas Rossberg wrote: >>> And as Andy points out correctly, that raises the question whether >>> having 'close' makes much sense at all. >> >> I think we have evolved away from it. Cc'ing Da