`await null` to stay in the same tick?

I'm not sure where's the best place to ask, but if I ``` await null ``` in an async function does that guarantee that the following code will execute immediately (control flow will not go anywhere else)? - Joe ___ es-discuss mailing list

Re: `await null` to stay in the same tick?

Await yields to the event loop unconditionally. This is useful for spreading CPU-bound work across multiple events. You can explicitly await conditionally. ``` if (guard) { await guard; } ``` On Sun, Feb 7, 2016 at 1:39 PM /#!/JoePea wrote: > I'm not sure where's the best

Re: `await null` to stay in the same tick?

On Sun, Feb 7, 2016 at 1:51 PM, Kris Kowal wrote: > Await yields to the event loop unconditionally. This is useful for > spreading CPU-bound work across multiple events. You can explicitly await > conditionally. > > ``` > if (guard) { await guard; } > ``` > Good example,

Re: monadic extension to do-notation

Why not just use await within `async do`? On 12:19PM, Sun, Feb 7, 2016 Rick Waldron wrote: > What does this do? > > > let finalPromise = do { > let a; > a <- b; > } > > > Currently, that's an expression that means "a less than negated b" > > Rick > > On Sun, Feb 7, 2016

Re: monadic extension to do-notation

Since the non-monadic way won, I don't know that it is worth arguing about why. But it is ergonomic issues much deeper than convenience, and much more important than compatibility with existing libraries -- even if those two were adequate considerations by themselves. The behavior of promises was

Re: monadic extension to do-notation

And draft ES6 tried for monadic, but compatibility with Promises libraries (more than "convenience") prevailed. /be On Sun, Feb 7, 2016 at 11:35 AM Raphael Mu wrote: > In theory it's possible, but Promise.resolve automatically joins Promises > for the sake of

Re: `await null` to stay in the same tick?

On Sun, Feb 7, 2016 at 1:38 PM, /#!/JoePea wrote: > I'm not sure where's the best place to ask, but if I > > ``` > await null > ``` > > in an async function does that guarantee that the following code will > execute immediately (control flow will not go anywhere else)? >

Re: monadic extension to do-notation

+1 to experience report from nodent, and +many to futures or eventual values. We've discussed before in terms of value types, value proxies, "become". See, e.g. https://twitter.com/brendaneich/status/585858406742786048 Also: Monadic for sure. Too late for promises. Sometimes you end up taking

Re: monadic extension to do-notation

What does this do? let finalPromise = do { let a; a <- b; } Currently, that's an expression that means "a less than negated b" Rick On Sun, Feb 7, 2016 at 12:07 PM Raphael Mu wrote: > The ES Promise is an instance of Monad, a property that implies a much > more

Re: monadic extension to do-notation

In theory it's possible, but Promise.resolve automatically joins Promises for the sake of ergonomics. On Sun, Feb 7, 2016 at 1:15 PM Jordan Harband wrote: > How is Promise an instance of Monad, if you can't ever have a Promise of a > Promise? > > On Sun, Feb 7, 2016 at 9:59

monadic extension to do-notation

The ES Promise is an instance of Monad, a property that implies a much more concise and expressive syntax for using Promise, by exploiting its monadic properties. I've seen a lot of people complain about Promises having too clumsy a syntax, and likewise for async/await. We now have the

Re: monadic extension to do-notation

The `a < -b` issue could be solved by using a different operator, like ` wrote: > Why not just use await within `async do`? > > On 12:19PM, Sun, Feb 7, 2016 Rick Waldron wrote: > >> What does this do? >> >> >> let finalPromise = do { >> let a; >> a <- b; >> } >> >> >>

RE: monadic extension to do-notation

The conflation of assignment and awaiting is a bad idea. It leads to lots of unnecessary temporary variables and makes anything but the simplest expression involving more than one await/promise very ugly - akin to the original syntax you're trying to avoid with inner variable declarations and

Re: monadic extension to do-notation

How is Promise an instance of Monad, if you can't ever have a Promise of a Promise? On Sun, Feb 7, 2016 at 9:59 AM, Raphael Mu wrote: > The `a < -b` issue could be solved by using a different operator, like > ` > On Sun, Feb 7, 2016 at 12:35 PM Kevin Smith

Re: Optional Chaining (aka Existential Operator, Null Propagation)

Claude Pache wrote: .? (?) [?] Yes, that syntax is possible. Whether it is preferable is a question of taste. Personally, I don’t like it: * I slightly prefer `?.` over `.?` for the following reason: The `?.` token may be conceptually separated in two, first the question mark which checks