4 ms·

Completely agree! This isn't a new thihg anyway, there are currently a lot of implementations, I even wrote one myself[1]. By the way, most (sane) libraries t

Completely agree! This isn't a new thihg anyway, there are currently a lot of implementations, I even wrote one myself[1]. By the way, most (sane) libraries that use yield/await perfom a lot better, than vanilla promises. Because when you do .then() on already resolved promise you have to wait for the next tick, or setImmediate or whatewer. Yield-based implementations can continue right away in this case. [1]: https://github.com/omgtehlion/asjs https://github.com/omgtehlion/asjs

esailija 13y ago
That is not true at all about Promises/A+. The requirement is to always calls handlers with an empty stack and in a certain order. In practice only naivest implementations would call platform scheduler for every `.then()`. Implementations can in all cases call the handlers synchronously when it would matter.
- quarterto 13y ago
  > In practice, this requirement ensures that onFulfilled and onRejected execute asynchronously, after the event loop turn in which then is called, and with a fresh stack. http://promises-aplus.github.io/promises-spec/#notes http://promises-aplus.github.io/promises-spec/#notes (emphasis mine)
  - esailija 13y ago
    That's just the specification. Doing exactly what the spec says is the definition of a naive implementation.
    - delian66 13y ago
      What is the point of having a specification, if everyone decides not to follow it ?
      - esailija 13y ago
        I did not say that one should not to comply to a specification. There is a big difference between implementations complying to specification and implementations where the source code is basically just duplication of the spec (which obviously runs very slowly). So my point is that even if the spec might say that "Do A, then B and then C", that's not what an implementation has to do EXACTLY as long as the outcome is exactly the same in both cases. For example a property load is a hugely complex operation in the ECMAScript spec that would take thousands of instructions to implement naively. In practice e.g. V8 will in many cases get away literally with one machine instruction in best case. None of the specified property load steps are obviously happening but yet somehow V8 is spec compliant.
  - domenicd 13y ago
    Notice that's in the explanatory Notes section, not the normative Requirements section.
danabramov 13y ago
>Because when you do .then() on already resolved promise you have to wait for the next tick, or setImmediate or whatewer. Yield-based implementations can continue right away in this case. Actually I learned to embrace next-tickness of promises in Q because I don't have to think twice about different possible execution order depending on promise's current state. I would honestly prefer immediate continuation to be opt-in. This worked well in .NET (its Task's ContinueWith has a flag called TaskContinuationOptions.ExecuteSynchronously that tells the scheduler “you can run me right away if you like”).
- omgtehlion 13y ago
  If you use yield in JS you don’t have to think about execition order too. Because execution sequence will always be the same, and JS lacks real threading, so you won’t notice it anyway.
  - danabramov 13y ago
    What about this kind of code? var x; promise().then(function (result) { x = result; }).done(); x.doStuff(); This is a contrived example, and pretty stupid too. Still, if promises are always resolved on next tick, it will always fail. If promises may be resolved in the same tick, then you may miss the mistake. A more real-world example is synchronization code like this[1]. Can you say at a glance if this code works fine both with resolved and pending promises? You'd have to check every `then`. You don't get this kind of problem with always-asynchronous promises. In other words, it's a tradeoff between performance and introducing possibility of several different code paths, and it gets messier with non-trivial code. [1]: https://gist.github.com/gaearon/7930162

esailija 13y ago

That is not true at all about Promises/A+. The requirement is to always calls handlers with an empty stack and in a certain order. In practice only naivest implementations would call platform scheduler for every `.then()`. Implementations can in all cases call the handlers synchronously when it would matter.

quarterto 13y ago
> In practice, this requirement ensures that onFulfilled and onRejected execute asynchronously, after the event loop turn in which then is called, and with a fresh stack. http://promises-aplus.github.io/promises-spec/#notes http://promises-aplus.github.io/promises-spec/#notes (emphasis mine)
- esailija 13y ago
  That's just the specification. Doing exactly what the spec says is the definition of a naive implementation.
  - delian66 13y ago
    What is the point of having a specification, if everyone decides not to follow it ?
    - esailija 13y ago
      I did not say that one should not to comply to a specification. There is a big difference between implementations complying to specification and implementations where the source code is basically just duplication of the spec (which obviously runs very slowly). So my point is that even if the spec might say that "Do A, then B and then C", that's not what an implementation has to do EXACTLY as long as the outcome is exactly the same in both cases. For example a property load is a hugely complex operation in the ECMAScript spec that would take thousands of instructions to implement naively. In practice e.g. V8 will in many cases get away literally with one machine instruction in best case. None of the specified property load steps are obviously happening but yet somehow V8 is spec compliant.
- domenicd 13y ago
  Notice that's in the explanatory Notes section, not the normative Requirements section.

danabramov 13y ago

>Because when you do .then() on already resolved promise you have to wait for the next tick, or setImmediate or whatewer. Yield-based implementations can continue right away in this case. Actually I learned to embrace next-tickness of promises in Q because I don't have to think twice about different possible execution order depending on promise's current state. I would honestly prefer immediate continuation to be opt-in. This worked well in .NET (its Task's ContinueWith has a flag called TaskContinuationOptions.ExecuteSynchronously that tells the scheduler “you can run me right away if you like”).

omgtehlion 13y ago
If you use yield in JS you don’t have to think about execition order too. Because execution sequence will always be the same, and JS lacks real threading, so you won’t notice it anyway.
- danabramov 13y ago
  What about this kind of code? var x; promise().then(function (result) { x = result; }).done(); x.doStuff(); This is a contrived example, and pretty stupid too. Still, if promises are always resolved on next tick, it will always fail. If promises may be resolved in the same tick, then you may miss the mistake. A more real-world example is synchronization code like this[1]. Can you say at a glance if this code works fine both with resolved and pending promises? You'd have to check every `then`. You don't get this kind of problem with always-asynchronous promises. In other words, it's a tradeoff between performance and introducing possibility of several different code paths, and it gets messier with non-trivial code. [1]: https://gist.github.com/gaearon/7930162