2012/11/7 Kevin Smith
>
> In other words, futures provide synchronisation, while promises
>> provide resolution.
>>
>
> This is exactly the API that Q (and it's derivatives) use, although the
> nomenclature is different. In Q, the "future" is called
rejections
> (and by extension, errors thrown from `then` callbacks), should ALWAYS be
> observable. In other words, if a rejection is not observable via error
> listeners at the time when error listeners should be called, then an
> unhandled error should be thrown by the runtime.
>
2. Once we have DOMPromises implemented, we advocate broader
use throughout DOM APIs.
3. Introduce ES7 Promises as a compatible subset of DOMPromises
I agree with this approach provided TC39 (not just you) keeps tracking
and commenting. public-script-coord is not overused...
In an ideal
> In other words, futures provide synchronisation, while promises
> provide resolution.
>
This is exactly the API that Q (and it's derivatives) use, although the
nomenclature is different. In Q, the "future" is called a promise, and the
"promise" is what you
ise... but it
> has this absurd thing that it has to have both an error and result field
> while only one is actually field at any given point.
>
There are absurdities like this all over DOM for want of promises. A short
list must include:
- XHR's "readystate" system
On 6 November 2012 20:55, David Herman wrote:
> - a way to create promises that don't expose their internal "resolve me"
> methods, etc. so they can be delivered to untrusted clients, e.g.:
>
> var [internalView, externalView] = Promise.makePair();
> &qu
Home: http://rauschma.de
Blog: http://2ality.com
On 07.11.2012, at 00:42, "Claus Reinke" wrote:
I agree that promises should be standardized in Ecma-262.
Agreed. That would also offer the possibility to support promises
in syntax. In ES7 (latest), I would like to see somethi
high priority for ES7. Champions wanted. Alex, I'm calling on
> you!
I'm happy to assist with a strawman/spec for promises. I too would like to
see them standardized.
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
should cover this, too (right?)
Yes, since task.js essentially adds fulfillment and rejection handlers
everywhere automatically, it's impossible to be left with an unhandled
rejection.
(This assumes you use `yield` on all your promises, but then again, if you
don't, you are essentially si
://rauschma.de
Blog: http://2ality.com
On 07.11.2012, at 00:42, "Claus Reinke" wrote:
>> I agree that promises should be standardized in Ecma-262.
>
> Agreed. That would also offer the possibility to support promises
> in syntax. In ES7 (latest), I would like to s
I agree that promises should be standardized in Ecma-262.
Agreed. That would also offer the possibility to support promises
in syntax. In ES7 (latest), I would like to see something roughly like
{ ...;
let x <- promise;
...;
}
(read as "let x from promise"), de
As an interesting aside, I just wanted to highlight the section of Promises/A+
that Rick was referring to, because I think it uses a rather clever trick to
avoid discussing the event loop while still requiring the behavior we want:
"onFulfilled and onRejected must not be called before
having two compatibility modes for IO would not be beneficial to the ecosystem,
we can argue that on and on and i'll pull ry out of "retirement" before i
concede to it going to in to core :)
On Nov 6, 2012, at November 6, 201212:43 PM, Domenic Denicola
wrote:
> From: es-discuss-boun...@mozill
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Mikeal Rogers [mikeal.rog...@gmail.com]
Sent: Tuesday, November 06, 2012 15:33
> also, node.js won't adopt either a promise "API" or a promise syntax for it's
> core API. if it lands in the language then nothing i
On Nov 6, 2012, at November 6, 201211:35 AM, Rick Waldron
wrote:
> Based on a read through of https://github.com/promises-aplus/promises-spec,
> these things initially come to mind, please regard as a loose collection of
> varying thoughts that may or may not be completely relevan
On Tue, Nov 6, 2012 at 2:55 PM, David Herman wrote:
> I agree that promises should be standardized in Ecma-262.
Yes.
> - a way to create promises that don't expose their internal "resolve me"
> methods, etc. so they can be delivered to untrusted clients, e.g.:
&
I agree that promises should be standardized in Ecma-262. There are a number of
subtleties that'll need to be hashed out:
- the tension between the flexible structural ("duck") type and the desire to
have the semantics do different things based on dynamically testing "whet
Le 06/11/2012 20:35, Rick Waldron a écrit :
Based on a read through of
https://github.com/promises-aplus/promises-spec, these things
initially come to mind, please regard as a loose collection of varying
thoughts that may or may not be completely relevant:
1. The definition of a "promis
Based on a read through of https://github.com/promises-aplus/promises-spec,
these things initially come to mind, please regard as a loose collection of
varying thoughts that may or may not be completely relevant:
1. The definition of a "promise" is really just a plain object or functi
Le 06/11/2012 20:07, Axel Rauschmayer a écrit :
That’s at a weird intersection between HTML5 and ECMAScript, (...)
I think it's more historical than anything. The event loop,
setTimeout/Interval (and promises) belong to the language (ECMAScript),
not to a library (HTML5) in my op
callbacks (where input and output are clearly
separated) and promises when it comes to invocation mechanics
It might just be me “not getting it”, but there must be ways to make things
more elegant (on both accounts).
Axel
On Nov 6, 2012, at 19:47 , David Bruant wrote:
> Hi,
>
> In
I guess now is a good a time as any to pre-announce Promises/A+:
https://github.com/promises-aplus/promises-spec
It’s an attempt to improve significantly on the minimal-but-perhaps-too-minimal
Promises/A of CommonJS, making the language more rigorous and speccing several
important things
shelf. Also, the lack of a built-in Q.all really doesn't promote
good code when it comes to event synchronization.
Oh yes, of course, you can always build a promise library on top of the
current APIs, blablabla... and waste battery with these libraries [3].
I'm coming with the following
On 10/21/2011 11:01 AM, David Herman wrote:
[snip]
But there's more to it than just the interface. You fix a particular
scheduling semantics when you put deferred functions into the
language. I'm still learning about the difference between the Deferred
pattern and the Promises pa
On Oct 21, 2011, at 2:03 PM, Eric Jacobs wrote:
> As a language end-user, I'm not sure that I would (or should) be concerned
> about the distinction between a deep continuation and a chain of shallow
> continuations. After all, the stack is just a chain of frames, and the
> mechanism by which t
Brendan Eich wrote:
On Oct 21, 2011, at 12:49 PM, Eric Jacobs wrote:
The catch is, of course, that all code which either can yield, or can call other
functions which yield, must have the "yield" keyword there, to mark that
run-to-completion invariants will end at that point. This seems like a
On Fri, Oct 21, 2011 at 10:46 AM, Mark S. Miller wrote:
> On Fri, Oct 21, 2011 at 10:20 AM, John J Barton <
> johnjbar...@johnjbarton.com> wrote:
>
>>
>>
>> In particular, Q simplifies joining parallel async operations (XHR,
>> postMessages, 'load', 'progress' events). Of course it may well be th
On Oct 21, 2011, at 12:49 PM, Eric Jacobs wrote:
> The catch is, of course, that all code which either can yield, or can call
> other functions which yield, must have the "yield" keyword there, to mark
> that run-to-completion invariants will end at that point. This seems like a
> very reasonab
Jorge wrote:
> or some other creative way of statically encoding the "might suspend
execution" condition into the syntax?
Yes, of course, it would be fine. Why ?
Because this is the crux of the "run-to-completion" debate that we're
immersed in.
Right now, JS has run-to-completion, where com
On 21/10/2011, at 21:23, Dean Landolt wrote:
> On Fri, Oct 21, 2011 at 3:20 PM, Jorge > On 21/10/2011, at 17:40, Eric Jacobs wrote:
>>>
>>> Jorge,
>>>
>>> Would it still be satisfying to you if instead of writing the call
>>> expression like this:
>>> try {
>>>response = asyncFunction(req
On Fri, Oct 21, 2011 at 3:20 PM, Jorge wrote:
> On 21/10/2011, at 17:40, Eric Jacobs wrote:
>
> > Jorge,
> >
> > Would it still be satisfying to you if instead of writing the call
> expression like this:
> >> try {
> >> response = asyncFunction(request); //might suspend execution
> >> }
> >> ca
On 21/10/2011, at 17:40, Eric Jacobs wrote:
> Jorge,
>
> Would it still be satisfying to you if instead of writing the call expression
> like this:
>> try {
>> response = asyncFunction(request); //might suspend execution
>> }
>> catch (e) {
>> //whatever
>> }
>> //our code continues here
> w
On Oct 21, 2011, at 10:20 AM, John J Barton wrote:
> My comment is entirely subjective and intended to be positive about Q.
We like Q too. :-)
> The examples on the async-generators page cites above are clearer than the
> ones on the MDC generators page because they focus on "next()". The stro
On Fri, Oct 21, 2011 at 10:20 AM, John J Barton wrote:
>
>
> On Fri, Oct 21, 2011 at 9:41 AM, Brendan Eich wrote:
>
>> On Oct 21, 2011, at 9:34 AM, John J Barton wrote:
>>
>> Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp /
>> Mark Miller Q library:
>> https://github.co
On Fri, Oct 21, 2011 at 9:41 AM, Brendan Eich wrote:
> On Oct 21, 2011, at 9:34 AM, John J Barton wrote:
>
> Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp /
> Mark Miller Q library:
> https://github.com/kriskowal/q
>
>
> Did you see
> https://github.com/kriskowal/q/tree
ous code in direct style. And I agree with you and Alex and Arv that
there is a cost to not standardizing on those libraries. There are different
frameworks with similar but incompatible idioms for Deferred objects, Promises,
and the like, and they could be standardized.
> A couple years later,
On Oct 21, 2011, at 9:34 AM, John J Barton wrote:
> Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp /
> Mark Miller Q library:
> https://github.com/kriskowal/q
Did you see
https://github.com/kriskowal/q/tree/master/examples/async-generators yet?
> In my experience, re
Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp /
Mark Miller Q library:
https://github.com/kriskowal/q
In my experience, reasoning about the code was much easier with Q than
without Q. (Not something I found in trying generators). I found the
documentation hard to follo
Jorge,
Would it still be satisfying to you if instead of writing the call
expression like this:
> try {
>response = asyncFunction(request); //might suspend execution
> }
> catch (e) {
>//whatever
> }
> //our code continues here
we needed to write it with an explicit annotation, like this
You can disagree with anything if you're allowed to change the terms of the
discussion. :)
Brendan said JS is run-to-completion, which means that if you call a function
and control returns to you, no intervening threads of control have executed in
the meantime. But then you changed his example
On 21/10/2011, at 11:07, Jorge wrote:
>
> And this has several (valuable, imo) advantages:
>
> - We aren't trashing the call stack on every async call: we can finally debug
> properly!
> - We can (finally!) catch the exceptions where and when it matters.
> - We can loop and control flow in the u
On 20/10/2011, at 23:37, Brendan Eich wrote:
> On Oct 20, 2011, at 12:59 PM, Jorge wrote:
>
>> the assert_invariants() at the next line might run in another turn of the
>> event loop (when f() resumes), just as the callback does.
>
> No. Nothing in JS today, since it lacks coroutines or call/cc,
On Oct 20, 2011, at 12:59 PM, Jorge wrote:
>>> assert_invariants();
>>> f(); //might suspend execution
>>> assert_invariants(); // perhaps yes, perhaps no. There's no guarantee
>>> either.
>>> return;
(Please trim cited text -- I know gmail hides it, which is a bug, but most mail
user agents sh
On 20/10/2011, at 18:38, Brendan Eich wrote:
> On Oct 20, 2011, at 6:44 AM, Jorge wrote:
>> On 19/10/2011, at 23:34, Brendan Eich wrote:
>>>
>>> The other objection is that (ignoring some evil native APIs such as sync
>>> XHR) JS has run-to-completion execution model now. You can model
>>>
>>> a
On Oct 20, 2011, at 6:44 AM, Jorge wrote:
> On 19/10/2011, at 23:34, Brendan Eich wrote:
>>
>> The other objection is that (ignoring some evil native APIs such as sync
>> XHR) JS has run-to-completion execution model now. You can model
>>
>> assert_invariants();
>> f();
>> assert_invariants_not
On Thu, Oct 20, 2011 at 9:44 AM, Jorge wrote:
> On 19/10/2011, at 23:34, Brendan Eich wrote:
> >
> > The other objection is that (ignoring some evil native APIs such as sync
> XHR) JS has run-to-completion execution model now. You can model
> >
> > assert_invariants();
> > f();
> > assert_inva
On 19/10/2011, at 23:34, Brendan Eich wrote:
>
> The other objection is that (ignoring some evil native APIs such as sync XHR)
> JS has run-to-completion execution model now. You can model
>
> assert_invariants();
> f();
> assert_invariants_not_affected_by_f_etc();
>
> where "etc" means func
On Oct 19, 2011, at 2:34 PM, Brendan Eich wrote:
> The other objection is that (ignoring some evil native APIs such as sync XHR)
> JS has run-to-completion execution model now. You can model
>
> assert_invariants();
> f();
> assert_invariants_not_affected_by_f_etc();
Contrast with generators
ulfill the most wanted use cases
> seems like than ideal.
Yeah, batteries included languages such as Python win. We aspire to that.
But apart from your (or anyone else's) proposal, JS is not Python in particular
ways that make it hard to rush OOTB built-ins to do promises or deferred
func
On Oct 19, 2011, at 12:55 PM, Eric Jacobs wrote:
> Kris Zyp wrote:
>> I believe that the overwhelming need that is continually and
>> constantly expressed and felt in the JS community in terms of handling
>> asynchronous activity is fundamentally a cry for top-down controlled
>> single-frame co
}
}
}
IIUC you're proposing language-level support for promises, right?
There's no getting around it -- you're spec'ing an interface for the
unary yield operator to interact with. So why not go all out and have
the language stratify `then` for you
Kris Zyp wrote:
> I believe that the overwhelming need that is continually and
> constantly expressed and felt in the JS community in terms of handling
> asynchronous activity is fundamentally a cry for top-down controlled
> single-frame continuations (obviously not always stated in such terms,
the value is not an object with a "then" property that is a function,
> the operand value is the immediate result of the evaluation of the "yield"
> expression and execution is not suspended.
>
> Here is a simple example of usage:
> "use strict"
> func
ant commonality. Using one keyword means there is only a
single operator that can result in a suspension of execution within a
function body, making easier to spot such occurrences and look for
possible points where certain variants should not be anticipated. Of
course it is also nice to avo
fork of Kris's
q-comm where I prototyped de-sugared implementation of this proposal for
Mozilla Jetpack, where it will allow cross process async messaging.
https://github.com/Gozala/vats
>
>>
>> I do believe that having ES native promises could provide drastically
>> bet
On Fri, Jan 28, 2011 at 9:54 PM, Kam Kasravi wrote:
>
> Does this have some parallels with channel messaging (
> http://www.w3.org/TR/html5/comms.html#channel-messaging)?
>
On Sat, Jan 29, 2011 at 7:17 AM, Kris Zyp wrote:
>
> So Web Workers are the competition? You can build far references on
cs, this may just use event-loop
stacking to "wait" or yield.
>
> However, I think your comparisons show your missing the point of this
> strawman. AFAIK, all the systems you cite, including node-promise
> which implements CommonJS promises/A and your proposed use of s
experience is good.
>
> However, I think your comparisons show your missing the point of this
> strawman. AFAIK, all the systems you cite, including node-promise which
> implements CommonJS promises/A and your proposed use of shallow
> continuations, are all only for helping expre
d look up the address if
> desired.
>
Please do. More collective experience is good.
However, I think your comparisons show your missing the point of this
strawman. AFAIK, all the systems you cite, including node-promise which
implements CommonJS promises/A and your proposed use of shallow
c
come the dominate interface API, there are other approaches that
> have been found more use. While I certainly like and appreciate
> the Q API, I don't think it has proven itself worthy to be added
> to the language.
>
> The real pain point with promises isn't that i
On Thu, Jan 27, 2011 at 9:37 PM, Mark S. Miller wrote:
> I don't understand why single-frame continuations are not at least as
> vulnerable to the criticism you make above. They are even more unproven
> among JavaScript programmers than are the concurrency abstractions in the
> strawman. The main
on't think it has
> proven itself worthy to be added to the language.
>
> The real pain point with promises isn't that it takes too many characters
> to type Q.post. How many bytes does the average JavaScript program spend on
> promise API calls? It negligible, this prop
discussed and known about for a
number of years has not become the dominate interface API, there are
other approaches that have been found more use. While I certainly like
and appreciate the Q API, I don't think it has proven itself worthy to
be added to the language.
The real pain point with pro
m of the
strawman page.)
>
>
> I do believe that having ES native promises could provide drastically
> better alternative for writing async code in comparison to currently popular
> nested callback style. Also even though there are few implementations of Q
> API adoption is sti
Hi,
I was curious to know what is the state of the following proposal:
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
I do believe that having ES native promises could provide drastically better
alternative for writing async code in comparison to currently popular nested
callback
Ok, I see. So it's true that the current Proxy API doesn't support promises
that would throw on instanceof when unresolved and return a boolean when
resolved. The main reason is that we didn't want proxies to meddle with the
inheritance chain, in particular giving proxies the abili
s to be
delayed. Not prototype of Cat. It may be resolved to any number of different
prototype chains depending on how the future/promise is resolved.
Sebastian
On Fri, Nov 19, 2010 at 4:38 PM, Tom Van Cutsem wrote:
> Hi Sebastian,
>
> Could you clarify why trapping instanceof is req
Hi Sebastian,
Could you clarify why trapping instanceof is required for promises? It seems
your use case can be addressed already using the current Proxy API: if `FP`
is a function proxy, then `obj instanceof FP` will query `FP` for its
`prototype` property (as per the default algorithm) by
I thought I'd make the case for the "instanceof trap"
in strawman:proxy_extensions - beyond multiple inheritance. I'm sure this
point has been made before at some point.
This is useful to implement various forms of promises using proxies. The
prototype can be resolved at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just FYI, there has also been significant discussion on CommonJS
regarding the use promises [1] and concurrency [2] in JavaScript,
CommonJS is focused on standardizing library APIs for JavaScript, in
particular on the server. Obviously on the server
, we're looking at Promises (precedent from E) and Futures
> (differently, in MultiLisp and Alice-ML). At least one contributor on
> es-discuss has advocated lower-level components such as dataflow variables.
That was presumably me:
<https://mail.mozilla.org/pipermail/es5-discuss/2
301 - 371 of 371 matches
Mail list logo
