Promises

classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Promises

David Bruant-5
Hi,

In a post to public-script-coord yesterday, Alex Russel wrote the
following [1]:
"[Web]IDL *is handy. *More to the point, it's the language of the specs
we have now, and the default mode for writing new ones is "copy/paste
some IDL from another spec that looks close to what I need and then hack
away until it's close". This M.O. is exacerbated by the reality that
most of the folks writing these specs are C++ hackers, not JS
developers. For many, WebIDL becomes a safety blanket that keeps them
from having to ever think about the operational JS semantics or be
confronted with the mismatches."

I wasn't aware of this and then read through about a dozen WebAPIs [2]
between yesterday and today and... discovered it's the case. In my
opinion, one of the most absurd example is the DOMRequest thing which
looks like:
{
    readonly attribute DOMString readyState; // "processing" or "done"
    readonly attribute DOMError? error;
    attribute EventListener      onsuccess;
    attribute EventListener      onerror;
    attribute readonly any?      result;
  };

Read it carefully and you'll realize this is actually a promise... 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.
Also, these APIs and JavaScript as it they are won't support promise
chainability and the excellent error forwarding that comes with it
off-the-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 plan:
1) get promises in ECMAScript
2) get WebIDL to support ECMAScript promises
3) get browser APIs to use WebIDL promises

About the first step, there is a strawman [4] that contains promises and
it requires to define the event loop, so that's probably too much for
ES6. Yet, it doesn't prevent to agree on a promise API that will be
adopted in ES7.
Besides the strawman, promises have run a long way from CommonJS [5] to
jQuery [6] to Q [7] to Irakli's excellent post [8] to Domenic's recent
rant [9] and I've missed a lot of other examples probably. The JS
community is ready for promises. The idea has been used a lot.
Different libraries have different APIs and I have no preference. The
only things I really care about is chaining (with error forwarding) and
a promise-joining function à la Q.all. I'll let people who care about
naming fight.

I'm sure TC39 can come to an agreement *before* ES7 standardization,
agreement that can be used by WebIDL and browser APIs (why not
implemented long before ES7 work has even started).
If you're a JS dev and care about promises, please show some support to
this proposal :-)

David

[1]
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0122.html
[2] https://wiki.mozilla.org/WebAPI#APIs
[3]
http://assets.en.oreilly.com/1/event/79/Who%20Killed%20My%20Battery_%20Analyzing%20Mobile%20Browser%20Energy%20Consumption%20Presentation.pdf
[4] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
[5] http://wiki.commonjs.org/wiki/Promises
[6] http://api.jquery.com/category/deferred-object/
[7] https://github.com/kriskowal/q
[8] http://jeditoolkit.com/2012/04/26/code-logic-not-mechanics.html
[9] https://gist.github.com/3889970
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Promises

Domenic Denicola-2
I guess now is a good a time as any to pre-announce Promises/A+:
 
 
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 Promises/A missed. Here’s a short summary of the differences:
 
 
The two most important ones, in my opinion, are:
  •  Cover the case of handlers returning a promise (chaining)
  • Require asynchronous resolution
 
Promises/A+ is a collaborative effort led by Brian Cavalier (when.js) with help from myself and Kris Kowal (Q), as well as Yehuda Katz (rsvp.js, TC39) and others with whom I am less personally familiar with but have also been very helpful.
 
---
 
I say “pre-announce” because there are a number of bookkeeping issues we want to take care of before saying it’s truly done:
 
 
But everything important is already in the repo. We also have a (again, preliminary) conformance test suite at
 
 
---
 
I hope this is helpful to TC39 or others considering promise standardization. My ideal vision is that the community experiments with promises + generators (a la taskjs) in the ES6 timeframe, then in ES7 we standardize on something like the concurrency strawman or a C#-like async/await pattern based on promises.
 
We welcome feedback from TC39 and others, preferably as GitHub issues in the repo (and thus we can avoid derailing this thread). We’d especially love the eyes of spec-experienced folks such as those that frequent this list.
 
From: David Bruant
Sent: ‎November‎ ‎6‎, ‎2012 ‎13‎:‎47
To: EcmaScript
Subject: Promises
 
Hi,

In a post to public-script-coord yesterday, Alex Russel wrote the
following [1]:
"[Web]IDL *is handy. *More to the point, it's the language of the specs
we have now, and the default mode for writing new ones is "copy/paste
some IDL from another spec that looks close to what I need and then hack
away until it's close". This M.O. is exacerbated by the reality that
most of the folks writing these specs are C++ hackers, not JS
developers. For many, WebIDL becomes a safety blanket that keeps them
from having to ever think about the operational JS semantics or be
confronted with the mismatches."

I wasn't aware of this and then read through about a dozen WebAPIs [2]
between yesterday and today and... discovered it's the case. In my
opinion, one of the most absurd example is the DOMRequest thing which
looks like:
{
    readonly attribute DOMString readyState; // "processing" or "done"
    readonly attribute DOMError? error;
    attribute EventListener      onsuccess;
    attribute EventListener      onerror;
    attribute readonly any?      result;
  };

Read it carefully and you'll realize this is actually a promise... 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.
Also, these APIs and JavaScript as it they are won't support promise
chainability and the excellent error forwarding that comes with it
off-the-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 plan:
1) get promises in ECMAScript
2) get WebIDL to support ECMAScript promises
3) get browser APIs to use WebIDL promises

About the first step, there is a strawman [4] that contains promises and
it requires to define the event loop, so that's probably too much for
ES6. Yet, it doesn't prevent to agree on a promise API that will be
adopted in ES7.
Besides the strawman, promises have run a long way from CommonJS [5] to
jQuery [6] to Q [7] to Irakli's excellent post [8] to Domenic's recent
rant [9] and I've missed a lot of other examples probably. The JS
community is ready for promises. The idea has been used a lot.
Different libraries have different APIs and I have no preference. The
only things I really care about is chaining (with error forwarding) and
a promise-joining function à la Q.all. I'll let people who care about
naming fight.

I'm sure TC39 can come to an agreement *before* ES7 standardization,
agreement that can be used by WebIDL and browser APIs (why not
implemented long before ES7 work has even started).
If you're a JS dev and care about promises, please show some support to
this proposal :-)

David

[1]
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0122.html
[2] https://wiki.mozilla.org/WebAPI#APIs
[3]
http://assets.en.oreilly.com/1/event/79/Who%20Killed%20My%20Battery_%20Analyzing%20Mobile%20Browser%20Energy%20Consumption%20Presentation.pdf
[4] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
[5] http://wiki.commonjs.org/wiki/Promises
[6] http://api.jquery.com/category/deferred-object/
[7] https://github.com/kriskowal/q
[8] http://jeditoolkit.com/2012/04/26/code-logic-not-mechanics.html
[9] https://gist.github.com/3889970
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Axel Rauschmayer
In reply to this post by David Bruant-5
That’s at a weird intersection between HTML5 and ECMAScript, but it would be great to have!

I recently played a little more with IndexedDB and found it complicated to use:

1. In contrast to the Web SQL database API and the MongoDB API when it comes to functionality

2. In contrast to Node.js 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 <[hidden email]> wrote:

Hi,

In a post to public-script-coord yesterday, Alex Russel wrote the following [1]:
"[Web]IDL *is handy. *More to the point, it's the language of the specs we have now, and the default mode for writing new ones is "copy/paste some IDL from another spec that looks close to what I need and then hack away until it's close". This M.O. is exacerbated by the reality that most of the folks writing these specs are C++ hackers, not JS developers. For many, WebIDL becomes a safety blanket that keeps them from having to ever think about the operational JS semantics or be confronted with the mismatches."

I wasn't aware of this and then read through about a dozen WebAPIs [2] between yesterday and today and... discovered it's the case. In my opinion, one of the most absurd example is the DOMRequest thing which looks like:
{
  readonly attribute DOMString readyState; // "processing" or "done"
  readonly attribute DOMError? error;
  attribute EventListener      onsuccess;
  attribute EventListener      onerror;
  attribute readonly any?      result;
};

Read it carefully and you'll realize this is actually a promise... 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.
Also, these APIs and JavaScript as it they are won't support promise chainability and the excellent error forwarding that comes with it off-the-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 plan:
1) get promises in ECMAScript
2) get WebIDL to support ECMAScript promises
3) get browser APIs to use WebIDL promises

About the first step, there is a strawman [4] that contains promises and it requires to define the event loop, so that's probably too much for ES6. Yet, it doesn't prevent to agree on a promise API that will be adopted in ES7.
Besides the strawman, promises have run a long way from CommonJS [5] to jQuery [6] to Q [7] to Irakli's excellent post [8] to Domenic's recent rant [9] and I've missed a lot of other examples probably. The JS community is ready for promises. The idea has been used a lot.
Different libraries have different APIs and I have no preference. The only things I really care about is chaining (with error forwarding) and a promise-joining function à la Q.all. I'll let people who care about naming fight.

I'm sure TC39 can come to an agreement *before* ES7 standardization, agreement that can be used by WebIDL and browser APIs (why not implemented long before ES7 work has even started).
If you're a JS dev and care about promises, please show some support to this proposal :-)

David

[1] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0122.html
[2] https://wiki.mozilla.org/WebAPI#APIs
[3] http://assets.en.oreilly.com/1/event/79/Who%20Killed%20My%20Battery_%20Analyzing%20Mobile%20Browser%20Energy%20Consumption%20Presentation.pdf
[4] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
[5] http://wiki.commonjs.org/wiki/Promises
[6] http://api.jquery.com/category/deferred-object/
[7] https://github.com/kriskowal/q
[8] http://jeditoolkit.com/2012/04/26/code-logic-not-mechanics.html
[9] https://gist.github.com/3889970
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

David Bruant-5
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 opinion.
ECMAScript 1-5 were concurrency-neutral. A pure ES5 programs has a start and an end and that's it. No concurrency whatsoever.
ES6 is going in that direction too.
ES7 opens a breach to event loop concurrency with async observers (object.observe)

David

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Rick Waldron
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 function with an expando property, I would think that a language level addition would require its own standard built-in object: Promise, which when invoked as a constructor initializes a new promise object which has a "then" method... Domenic has it covered from there.

2. The notes describe some excellent practical implementation points, but none of them are actually part of the ECMAScript standard, eg. setTimeout, process.nextTick. Should these be specified or left unspecified? Object.observe describes delivery as "Schedule change events to be delivered asynchronously 'at the end of the turn'", which is not very specific.

3. Does this belong in the language or would it make more sense to exist as a "standard module"?


Rick








On Tue, Nov 6, 2012 at 2:15 PM, David Bruant <[hidden email]> wrote:
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 opinion.
ECMAScript 1-5 were concurrency-neutral. A pure ES5 programs has a start and an end and that's it. No concurrency whatsoever.
ES6 is going in that direction too.
ES7 opens a breach to event loop concurrency with async observers (object.observe)

David

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

David Bruant-5
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 "promise" is really just a plain object or
> function with an expando property, I would think that a language level
> addition would require its own standard built-in object: Promise,
> which when invoked as a constructor initializes a new promise object
> which has a "then" method... Domenic has it covered from there.
I fully agree.

> 2. The notes describe some excellent practical implementation points,
> but none of them are actually part of the ECMAScript standard, eg.
> setTimeout, process.nextTick. Should these be specified or left
> unspecified? Object.observe describes delivery as "Schedule change
> events to be delivered asynchronously 'at the end of the turn'", which
> is not very specific.
As I suggested, Object.observe opens the breach and I think it means the
event loop (including the notion of "turn") will have to be fully
specified within ECMAScript.

> 3. Does this belong in the language or would it make more sense to
> exist as a "standard module"?
Are you referring to the event loop or promises?
event loop : the language
promises : arguably standard module

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Dave Herman
In reply to this post by David Bruant-5
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 "whether" something is a promise:
  * the common practice (sadly not at all spelled out in Promises/A) of treating a resolved value that is a promise as continuing to defer resolution
  * the `when` operation that either calls its callback synchronously or asynchronously depending on whether it's a promise

- whether it's a bad idea (*cough* it is *cough*) for `when` to do that

- whether promises ever call their callbacks synchronously

- every single corner case of when an error is thrown and where it is thrown

- the interaction with the event-loop semantics, which needs to be specified in ES6 but isn't yet written

- whether the `then` property name should be a symbol or a string

- 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();
    "resolve" in internalView // true
    "resolve" in externalView // false

I agree this is worth doing, though definitely post-ES6. Personally I would like to work on it but for me anyway it has to take a back seat to modules and binary data.

Dave

On Nov 6, 2012, at 10:47 AM, David Bruant <[hidden email]> wrote:

> Hi,
>
> In a post to public-script-coord yesterday, Alex Russel wrote the following [1]:
> "[Web]IDL *is handy. *More to the point, it's the language of the specs we have now, and the default mode for writing new ones is "copy/paste some IDL from another spec that looks close to what I need and then hack away until it's close". This M.O. is exacerbated by the reality that most of the folks writing these specs are C++ hackers, not JS developers. For many, WebIDL becomes a safety blanket that keeps them from having to ever think about the operational JS semantics or be confronted with the mismatches."
>
> I wasn't aware of this and then read through about a dozen WebAPIs [2] between yesterday and today and... discovered it's the case. In my opinion, one of the most absurd example is the DOMRequest thing which looks like:
> {
>   readonly attribute DOMString readyState; // "processing" or "done"
>   readonly attribute DOMError? error;
>   attribute EventListener      onsuccess;
>   attribute EventListener      onerror;
>   attribute readonly any?      result;
> };
>
> Read it carefully and you'll realize this is actually a promise... 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.
> Also, these APIs and JavaScript as it they are won't support promise chainability and the excellent error forwarding that comes with it off-the-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 plan:
> 1) get promises in ECMAScript
> 2) get WebIDL to support ECMAScript promises
> 3) get browser APIs to use WebIDL promises
>
> About the first step, there is a strawman [4] that contains promises and it requires to define the event loop, so that's probably too much for ES6. Yet, it doesn't prevent to agree on a promise API that will be adopted in ES7.
> Besides the strawman, promises have run a long way from CommonJS [5] to jQuery [6] to Q [7] to Irakli's excellent post [8] to Domenic's recent rant [9] and I've missed a lot of other examples probably. The JS community is ready for promises. The idea has been used a lot.
> Different libraries have different APIs and I have no preference. The only things I really care about is chaining (with error forwarding) and a promise-joining function à la Q.all. I'll let people who care about naming fight.
>
> I'm sure TC39 can come to an agreement *before* ES7 standardization, agreement that can be used by WebIDL and browser APIs (why not implemented long before ES7 work has even started).
> If you're a JS dev and care about promises, please show some support to this proposal :-)
>
> David
>
> [1] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0122.html
> [2] https://wiki.mozilla.org/WebAPI#APIs
> [3] http://assets.en.oreilly.com/1/event/79/Who%20Killed%20My%20Battery_%20Analyzing%20Mobile%20Browser%20Energy%20Consumption%20Presentation.pdf
> [4] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
> [5] http://wiki.commonjs.org/wiki/Promises
> [6] http://api.jquery.com/category/deferred-object/
> [7] https://github.com/kriskowal/q
> [8] http://jeditoolkit.com/2012/04/26/code-logic-not-mechanics.html
> [9] https://gist.github.com/3889970
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Erik Arvidsson
On Tue, Nov 6, 2012 at 2:55 PM, David Herman <[hidden email]> 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.:
>
>     var [internalView, externalView] = Promise.makePair();
>     "resolve" in internalView // true
>     "resolve" in externalView // false

This is very important. You don't want the consumer, of XHR for
example, to resolve the promise. It is not only about trusted clients,
it is also about keeping the API clean.

> I agree this is worth doing, though definitely post-ES6. Personally I would like to work on it but for me anyway it has to take a back seat to modules and binary data.

I would say high priority for ES7. Champions wanted. Alex, I'm calling on you!

--
erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Mikeal Rogers-3
In reply to this post by Rick Waldron

On Nov 6, 2012, at November 6, 201211:35 AM, Rick Waldron <[hidden email]> 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 relevant:

1. The definition of a "promise" is really just a plain object or function with an expando property, I would think that a language level addition would require its own standard built-in object: Promise, which when invoked as a constructor initializes a new promise object which has a "then" method... Domenic has it covered from there.

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 is stopping people from using it but the ecosystem is highly unlikely to adopt it either since it's not uniform across node.

we've had great success using function (err, result) {} across core and across the ecosystem, it's been widely successful as you can see by the number of modules created, the breath of functionality those modules provide, and their seamless compatibility with each other.


2. The notes describe some excellent practical implementation points, but none of them are actually part of the ECMAScript standard, eg. setTimeout, process.nextTick. Should these be specified or left unspecified? Object.observe describes delivery as "Schedule change events to be delivered asynchronously 'at the end of the turn'", which is not very specific.

3. Does this belong in the language or would it make more sense to exist as a "standard module"?


Rick








On Tue, Nov 6, 2012 at 2:15 PM, David Bruant <[hidden email]> wrote:
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 opinion.
ECMAScript 1-5 were concurrency-neutral. A pure ES5 programs has a start and an end and that's it. No concurrency whatsoever.
ES6 is going in that direction too.
ES7 opens a breach to event loop concurrency with async observers (object.observe)

David

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Promises

Domenic Denicola-2
From: [hidden email] [[hidden email]] on behalf of Mikeal Rogers [[hidden email]]
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 is stopping people from using it but the ecosystem is highly unlikely to adopt it either since it's not uniform across node.

Um:

https://twitter.com/izs/status/257634118320410624
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Mikeal Rogers-3
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 <[hidden email]> wrote:

> From: [hidden email] [[hidden email]] on behalf of Mikeal Rogers [[hidden email]]
> 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 is stopping people from using it but the ecosystem is highly unlikely to adopt it either since it's not uniform across node.
>
> Um:
>
> https://twitter.com/izs/status/257634118320410624

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Promises

Domenic Denicola-2
In reply to this post by David Bruant-5
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 then returns [1]."

This trick is borrowed from Kris Kowal's UncommonJS promises specification.
 

> -----Original Message-----
> From: [hidden email] [mailto:es-discuss-
> [hidden email]] On Behalf Of David Bruant
> Sent: Tuesday, November 6, 2012 14:43
> To: Rick Waldron
> Cc: EcmaScript
> Subject: Re: Promises
>
> 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 "promise" is really just a plain object or
> > function with an expando property, I would think that a language level
> > addition would require its own standard built-in object: Promise,
> > which when invoked as a constructor initializes a new promise object
> > which has a "then" method... Domenic has it covered from there.
> I fully agree.
>
> > 2. The notes describe some excellent practical implementation points,
> > but none of them are actually part of the ECMAScript standard, eg.
> > setTimeout, process.nextTick. Should these be specified or left
> > unspecified? Object.observe describes delivery as "Schedule change
> > events to be delivered asynchronously 'at the end of the turn'", which
> > is not very specific.
> As I suggested, Object.observe opens the breach and I think it means the
> event loop (including the notion of "turn") will have to be fully specified within
> ECMAScript.
>
> > 3. Does this belong in the language or would it make more sense to
> > exist as a "standard module"?
> Are you referring to the event loop or promises?
> event loop : the language
> promises : arguably standard module
>
> David
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Claus Reinke
In reply to this post by Dave Herman
> 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"), desugaring into

    { ...;
      promise.then( (x) => { ...; };
    }

Essentially, this is an even shallower continuation than generators
(only the remaining statements in the current statement list), but it
is already sufficient to avoid callback nesting issues in async code.
It also suffices to implement generators, but for syntax.

By relying on nothing but a '.then' method, this isn't tied to promises
in the narrow sense, but provides a reusable building block for other
control abstractions (to begin with, abstracting away the default
error handling in some APIs).

Claus
 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Axel Rauschmayer
Why not task.js, instead?

Different issue: do we already have a solution for a missing error handler causing silent failures? task.js should cover this, too (right?)


[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer
[hidden email]
Home: http://rauschma.de
Blog: http://2ality.com

On 07.11.2012, at 00:42, "Claus Reinke" <[hidden email]> 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 something roughly like
>
>   { ...;
>     let x <- promise;
>     ...;
>   }
>
> (read as "let x from promise"), desugaring into
>
>   { ...;
>     promise.then( (x) => { ...; };
>   }
>
> Essentially, this is an even shallower continuation than generators
> (only the remaining statements in the current statement list), but it
> is already sufficient to avoid callback nesting issues in async code. It also suffices to implement generators, but for syntax.
> By relying on nothing but a '.then' method, this isn't tied to promises
> in the narrow sense, but provides a reusable building block for other control abstractions (to begin with, abstracting away the default
> error handling in some APIs).
>
> Claus
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Promises

Domenic Denicola-2
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Axel Rauschmayer
Sent: Tuesday, November 6, 2012 19:07

> Different issue: do we already have a solution for a missing error handler causing silent failures? task.js 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 signaling that you don't care about the result.)
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Tom Van Cutsem-3
In reply to this post by Erik Arvidsson
2012/11/6 Erik Arvidsson <[hidden email]>
On Tue, Nov 6, 2012 at 2:55 PM, David Herman <[hidden email]> wrote:
> I agree this is worth doing, though definitely post-ES6. Personally I would like to work on it but for me anyway it has to take a back seat to modules and binary data.

I would say 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Claus Reinke
In reply to this post by Axel Rauschmayer
> Why not task.js, instead?

1. Implementation complexity

    let-from: trivial syntax transformation

    task.js+generators: non-trivial syntax transformation or
        -more likely- non-trivial runtime system manipulation

2. Usage complexity

    let-from: just another statement in the block,
        merely syntax for conventional promise/callback-style

    task.js+generators: spawn+function*+yield,
        complex rts + complex library

3. Usage granularity

    let-from: statement level

    task.js+generators: function level

Note that the trade-offs are not entirely against task.js: because JS
has so much non-overridable surface syntax, it is useful to have the
pre-packaged functionality of generators built-in, and it is useful to
reuse that functionality for async and co-routine code, via task.js.
As long as you use it to wrap non-trivial segments of code.

But when you don't want to deal with code that uses while/for/if/..,
or if you want to build up your code patterns from smaller
components, then let-from has advantages. For let-from to fully
replace task.js and generators, JS would need library-based
control structures or overridable control-structure syntax (eg,
Haskell monads or F# computation expressions).

Claus

> Different issue: do we already have a solution for a missing error handler causing silent
> failures? task.js should cover this, too (right?)
>
>
> [[[Sent from a mobile device. Please forgive brevity and typos.]]]
>
> Dr. Axel Rauschmayer
> [hidden email]
> Home: http://rauschma.de
> Blog: http://2ality.com
>
> On 07.11.2012, at 00:42, "Claus Reinke" <[hidden email]> 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 something roughly like
>>
>>   { ...;
>>     let x <- promise;
>>     ...;
>>   }
>>
>> (read as "let x from promise"), desugaring into
>>
>>   { ...;
>>     promise.then( (x) => { ...; };
>>   }
>>
>> Essentially, this is an even shallower continuation than generators
>> (only the remaining statements in the current statement list), but it
>> is already sufficient to avoid callback nesting issues in async code. It also suffices to
>> implement generators, but for syntax.
>> By relying on nothing but a '.then' method, this isn't tied to promises
>> in the narrow sense, but provides a reusable building block for other control abstractions (to
>> begin with, abstracting away the default
>> error handling in some APIs).
>>
>> Claus
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>

 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Andreas Rossberg-4
In reply to this post by Dave Herman
On 6 November 2012 20:55, David Herman <[hidden email]> 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();
>     "resolve" in internalView // true
>     "resolve" in externalView // false

Indeed. I think this is an issue where many promise/future libraries
are confused/broken. FWIW, when creating a concurrent language called
Alice ML some 15 years ago we thought about this quite extensively,
and ended up introducing the following separation of concepts:

* Futures are handles for (potentially) unresolved/asynchronous
values, on which you can wait and block -- but you cannot directly
resolve them.

* Promises are explicit resolvers for a future. More specifically,
creating a promise creates an associated future, which you can safely
pass to other parties. Only the promise itself provides the fulfill
method (and related functionality) that enables resolving that future.

In other words, futures provide synchronisation, while promises
provide resolution.

Incidentally, that's also exactly the model and naming that C++11 picked.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Alex Russell-4
In reply to this post by David Bruant-5
Sorry for ignoring the rest of this thread in my first reply, but I'll try to cover as much ground as I can here. Response inline:



On Tue, Nov 6, 2012 at 6:47 PM, David Bruant <[hidden email]> wrote:
Hi,

In a post to public-script-coord yesterday, Alex Russel wrote the following [1]:
"[Web]IDL *is handy. *More to the point, it's the language of the specs we have now, and the default mode for writing new ones is "copy/paste some IDL from another spec that looks close to what I need and then hack away until it's close". This M.O. is exacerbated by the reality that most of the folks writing these specs are C++ hackers, not JS developers. For many, WebIDL becomes a safety blanket that keeps them from having to ever think about the operational JS semantics or be confronted with the mismatches."

I wasn't aware of this and then read through about a dozen WebAPIs [2] between yesterday and today and... discovered it's the case. In my opinion, one of the most absurd example is the DOMRequest thing which looks like:
{
   readonly attribute DOMString readyState; // "processing" or "done"
   readonly attribute DOMError? error;
   attribute EventListener      onsuccess;
   attribute EventListener      onerror;
   attribute readonly any?      result;
 };

Read it carefully and you'll realize this is actually a promise... 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
  • geolocation APIs
  • window.onload, DOMContentLoaded, etc.
  • CSS OM measurement APIs.
I'm sure I'm missing some. I'm also aware of new APIs that could be re-cast in terms of Promises/Futures/whatevs to good effect.
 
Also, these APIs and JavaScript as it they are won't support promise chainability and the excellent error forwarding that comes with it off-the-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 plan:
1) get promises in ECMAScript
2) get WebIDL to support ECMAScript promises
3) get browser APIs to use WebIDL promises

From a "doability" perspective, I think this is backwards. Browser vendors are more likely to add ad-hoc APIs, and the large problem of DOM design is that Promises aren't in the WebIDL "toolchest". Further, this group is even more gunshy than many W3C WGs to make progress in important areas for fear of backwards compatibility burdens. It's also harder to iterate ES since it moves so slowly (in relative spec-org terms; all spec processes move slowly in human terms).

My plan, as a result, inverts yours:
  1. Get "DOMPromises" done in order to fix some busted proposed API. My current hope is WebCrypto who can both avoid a design catastrophe and introduce a new, widely implemented API on a relatively short timeframe
  2. Once we have DOMPromises implemented, we advocate broader use throughout DOM APIs.
  3. Introduce ES7 Promises as a compatible subset of DOMPromises 
In an ideal world we'd go your route (as we would have with Object.observe() vs. Mutation Observers), but TC39 isn't known for adding API quickly, no matter how popular or well-argued the case.

About the first step, there is a strawman [4] that contains promises and it requires to define the event loop, so that's probably too much for ES6. Yet, it doesn't prevent to agree on a promise API that will be adopted in ES7.
Besides the strawman, promises have run a long way from CommonJS [5] to jQuery [6] to Q [7] to Irakli's excellent post [8] to Domenic's recent rant [9] and I've missed a lot of other examples probably. The JS community is ready for promises. The idea has been used a lot.
Different libraries have different APIs and I have no preference. The only things I really care about is chaining (with error forwarding) and a promise-joining function à la Q.all. I'll let people who care about naming fight.

I'm sure TC39 can come to an agreement *before* ES7 standardization, agreement that can be used by WebIDL and browser APIs (why not implemented long before ES7 work has even started).
If you're a JS dev and care about promises, please show some support to this proposal :-)

I support getting Promises done where they'll make an impact and right now DOM is the squeeky wheel. Yes, we need them in JS, but getting the eyes around this particular table opened to that is a fight I don't want right now (as the rest of this thread is painful, painful proof). 
 
[1] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0122.html
[2] https://wiki.mozilla.org/WebAPI#APIs
[3] http://assets.en.oreilly.com/1/event/79/Who%20Killed%20My%20Battery_%20Analyzing%20Mobile%20Browser%20Energy%20Consumption%20Presentation.pdf
[4] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
[5] http://wiki.commonjs.org/wiki/Promises
[6] http://api.jquery.com/category/deferred-object/
[7] https://github.com/kriskowal/q
[8] http://jeditoolkit.com/2012/04/26/code-logic-not-mechanics.html
[9] https://gist.github.com/3889970
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promises

Kevin Smith-21
In reply to this post by Andreas Rossberg-4

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 get from calling defer():

    let { resolve, reject, promise } = Q.defer();

I think the nomenclature you've provided is superior.  Using those names we'd have an API that looks something more like this:

    let promise = new Promise();
    let future = promise.future;

    // Futures have a then method, ala Promises/A+
    future.then(val => { ... });

    // Promises are resolved using methods on the promise object:
    promise.resolve(val);
    promise.reject(val);

The aesthetic issue I have with Promises/A+ is that the error handling interface is ugly:

    future.then(val => {
      ...
    }, err => {
      ...
    });

In all of our APIs we try to avoid placing callbacks in non-terminating argument positions, which this violates.

The only hard part that isn't really addressed by currently library implementations is error handling.  I feel pretty strongly that 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.

In my usage of promises I have never wanted anything other than this behavior.

- Kevin


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
1234