jordi baylina schrieb:
I propose that all the calls to any async function will be implicit
(without the need of the await keyword). And precede it with a nowait only
when you want a promise.
This way, the code will not have the async clutter in the logic of the
function, but will be need to be
I propose that all the calls to any async function will be implicit
(without the need of the await keyword). And precede it with a nowait only
when you want a promise.
See this snipped proposal:
https://gist.github.com/jbaylina/692d4e43329c8c0d22dd
This way, the code will not have the async clut
On Fri, Sep 12, 2014 at 8:14 AM, C. Scott Ananian wrote:
> On Fri, Sep 12, 2014 at 2:24 AM, Florian Bösch wrote:
>> It's often the case that the code which uses the async code, uses other
>> code, which isn't authored by the author, and isn't documented for await
>> compatibility. For instance:
>
On Fri, Sep 12, 2014 at 2:24 AM, Florian Bösch wrote:
> It's often the case that the code which uses the async code, uses other
> code, which isn't authored by the author, and isn't documented for await
> compatibility. For instance:
>
> $.each(somelist, async function(item){
> await Foobar(it
>
> Arguably, the fact that a function may suspend in mid-flight should be
> part of its documentation (i.e. function signature), as it directly affects
> the caller.
>
It does. With async/await the function signature must be marked with
'async' if the function body contains 'await'.
> As an an
On Fri, Sep 12, 2014 at 8:00 AM, Tom Van Cutsem wrote:
>
> While this refactoring may be tedious (no disagreement there), it forces
> you to review all affected code, which is good, because the dependencies of
> that code may have changed (i.e. side-effect the client previously thought
> would exe
2014-09-11 16:22 GMT+02:00 Florian Bösch :
> A -> B -> C -> D -> E changes to
>
> A -> B -> C -> D -> async E and causes
>
> A await -> B await -> C await -> D await -> async E
>
> And of course if A, B, C or D is used anywhere else it percolates trough
> the entire call graph.
>
> Trying to prote
On Thu, Sep 11, 2014 at 5:27 PM, Bruno Jouhier wrote:
> If async/await is baked into the language VM implementers will be able to
> choose between different strategies: callbacks, single frame continuations,
> deep continuations, ...
...and transactional speculation. Or at least, that was the pr
I forgot to mention performance.
streamline has been an interesting playground to test performance because
it supports 3 different backends:
- pure callbacks with a sophisticated CPS transform
- fibers (much simpler transform)
- generators (transform is similar to fibers, runtime is a bi
On Thu, Sep 11, 2014 at 4:41 PM, Bruno Jouhier wrote:
> I think that Mark Miller nails it really well:
>>
>> The cost of making atomicity cheap is that interleaving points must be
>> made explicit. With callbacks, this cost is quite high. Promises reduce this
>> cost substantially. async/await fur
I'd like to inject my own experience into this discussion.
I am the author of streamline.js, a smalll extension to JavaScript which
adds async/await semantics to the language. I developed this language
extension in January 2011 and we have been using it since then in a large
project (new web stack
On 9/11/14, 10:22 AM, Florian Bösch wrote:
A -> B -> C -> D -> E changes to
A -> B -> C -> D -> async E and causes
A await -> B await -> C await -> D await -> async E
And of course if A, B, C or D is used anywhere else it percolates
trough the entire call graph.
Sort of true, but this is no
The problem of code interleaving isn't on a fundamental level (like with
threads). Threads are a very different best, that interlave at random
points in time, and hence require some heavy lifting by the environmnet/OS
to not immediately fall flat.
Cooperative multitasking between I/O primitives is
On Thu, Sep 11, 2014 at 7:22 AM, Florian Bösch wrote:
> A -> B -> C -> D -> E changes to
>
> A -> B -> C -> D -> async E and causes
>
> A await -> B await -> C await -> D await -> async E
>
> And of course if A, B, C or D is used anywhere else it percolates trough
> the entire call graph.
>
> Try
Furthermore, since await is call graph infectious, for those really wanting
to use it, it means that before long, await is written before every single
function call. Which makes no sense.
On Thu, Sep 11, 2014 at 4:22 PM, Florian Bösch wrote:
> A -> B -> C -> D -> E changes to
>
> A -> B -> C ->
A -> B -> C -> D -> E changes to
A -> B -> C -> D -> async E and causes
A await -> B await -> C await -> D await -> async E
And of course if A, B, C or D is used anywhere else it percolates trough
the entire call graph.
Trying to protect people from interlaved code execution effects is noble.
B
On Thu, Sep 11, 2014 at 6:20 AM, Florian Bösch wrote:
> await has also another problem in that if somewhere, deep down the call
> stack, something is intending to do async, then up the entire call stack
> everywhere you've got to insert await. It's a bit of a headache for code
> maintenance (hell
await has also another problem in that if somewhere, deep down the call
stack, something is intending to do async, then up the entire call stack
everywhere you've got to insert await. It's a bit of a headache for code
maintenance (hello bicycle repair man jam session), and it's also fairly
unfriend
Also, see https://github.com/lukehoban/ecmascript-asyncawait/issues/14 for
previous discussion.
On Thu, Sep 11, 2014 at 8:42 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> There are several problems solved by async/await instead of twisting
> generators:
>
> 1. What if you wanted to
There are several problems solved by async/await instead of twisting generators:
1. What if you wanted to use generators for lazy sequences (iterables), instead
of asynchronicity? If your framework assumes all generators are for async, you
lose the original use case of generators.
2. Say what y
Yes, async/await solves one problem in particular that generators alone
cannot—the ability to `await` some asynchronous value from within a true
generator (one yielding actual values, not a coroutine yielding promises or
thunks into a trampoline). These coro trampolines are a clever hack, but
the a
21 matches
Mail list logo
