+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 two steps. /be On Sun, Feb 7, 2016 at 10:19 AM Mat At Bread <[email protected]> wrote: > 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 > <- operations. > > A very similar syntax was used by nodent until v1 when it was replaced > with async and await. > > I'd be much more interested in a VM extension that performed auto > boxing/unboxing on Promises, achieving a similar result without the need > for additional syntactic constructions > > > ---------- > > monadic extension to do-notation > > From: Raphael Mu <[email protected]> > > Date: 7 Feb, 17:07 > > To: [email protected] > > > > > > 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 do-notation proposal ( > > http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions), and > > monadic assignment would fit well into the syntax. > > > > The extension would allow use of `<-` within a do-expression for binding > > Promise values to variables, and the computation would behave most > > similarly to the Either monad in Haskell (in the following code, if > > promiseA or promiseB reject, the result of the entire expression would > be a > > rejected Promise). > > > > (monadic extension) > > ```javascript > > let finalPromise = do { > > let a <- promiseA; > > let b <- promiseB; > > let c = f(a, b); > > g(a, b, c) > > } > > ``` > > > > (desugared to async/await) > > ```javascript > > let finalPromise = (async () => { > > let a = await promiseA; > > let b = await promiseB; > > let c = f(a, b); > > return g(a, b, c); > > })(); > > ``` > > > > (desugared to ES6) > > ```javascript > > let finalPromise = promiseA.then(a => > > promiseB.then(b => { > > let c = f(a, b); > > return g(a, b, c); > > }) > > ); > > ``` > > > > The do-notation would apply Promise.resolve to the last expression (like > > async and Promise#then), effectively returning another Promise. The > current > > proposal doesn't specify this behavior, but there are two ways about this > > collision: > > > > 1. use an explicit version of do-notation, e.g. `async do { ... }` or > `do* > > { ... }` > > 2. revise the do-notation proposal to always apply Promise.resolve to the > > last expression > > > > Both choices give us a new Promise literal for free: `do* { x }` (1) or > `do > > { x }` (2) would be functionally equivalent to `Promise.resolve(x)`. > > > > The idea was briefly mentioned several years ago, but didn't attract much > > attention ( > > https://mail.mozilla.org/pipermail/es-discuss/2012-March/021624.html). > > > > This is an earlier draft of this proposal: > > https://github.com/edge/es-monadic > > > > > > > > > ---------- > > Re: monadic extension to do-notation > > From: Rick Waldron <[email protected]> > > Date: 7 Feb, 17:19 > > To: Raphael Mu <[email protected]>, [email protected] > > > > > > 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 <[email protected]> > wrote: > > > >> 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 do-notation proposal ( > >> http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions), and > >> monadic assignment would fit well into the syntax. > >> > >> The extension would allow use of `<-` within a do-expression for binding > >> Promise values to variables, and the computation would behave most > >> similarly to the Either monad in Haskell (in the following code, if > >> promiseA or promiseB reject, the result of the entire expression would > be a > >> rejected Promise). > >> > >> (monadic extension) > >> ```javascript > >> let finalPromise = do { > >> let a <- promiseA; > >> let b <- promiseB; > >> let c = f(a, b); > >> g(a, b, c) > >> } > >> ``` > >> > >> (desugared to async/await) > >> ```javascript > >> let finalPromise = (async () => { > >> let a = await promiseA; > >> let b = await promiseB; > >> let c = f(a, b); > >> return g(a, b, c); > >> })(); > >> ``` > >> > >> (desugared to ES6) > >> ```javascript > >> let finalPromise = promiseA.then(a => > >> promiseB.then(b => { > >> let c = f(a, b); > >> return g(a, b, c); > >> }) > >> ); > >> ``` > >> > >> The do-notation would apply Promise.resolve to the last expression (like > >> async and Promise#then), effectively returning another Promise. The > current > >> proposal doesn't specify this behavior, but there are two ways about > this > >> collision: > >> > >> 1. use an explicit version of do-notation, e.g. `async do { ... }` or > `do* > >> { ... }` > >> 2. revise the do-notation proposal to always apply Promise.resolve to > the > >> last expression > >> > >> Both choices give us a new Promise literal for free: `do* { x }` (1) or > >> `do { x }` (2) would be functionally equivalent to `Promise.resolve(x)`. > >> > >> The idea was briefly mentioned several years ago, but didn't attract > much > >> attention ( > >> https://mail.mozilla.org/pipermail/es-discuss/2012-March/021624.html). > >> > >> This is an earlier draft of this proposal: > >> https://github.com/edge/es-monadic > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > > > > > > > > ---------- > > Re: monadic extension to do-notation > > From: Kevin Smith <[email protected]> > > Date: 7 Feb, 17:35 > > To: Rick Waldron <[email protected]>, Raphael Mu < > [email protected]>, [email protected] > > > > > > Why not just use await within `async do`? > > > > On 12:19PM, Sun, Feb 7, 2016 Rick Waldron <[email protected]> > 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 at 12:07 PM Raphael Mu <[email protected]> > >> wrote: > >> > >>> 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 do-notation proposal ( > >>> http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions), and > >>> monadic assignment would fit well into the syntax. > >>> > >>> The extension would allow use of `<-` within a do-expression for > binding > >>> Promise values to variables, and the computation would behave most > >>> similarly to the Either monad in Haskell (in the following code, if > >>> promiseA or promiseB reject, the result of the entire expression would > be a > >>> rejected Promise). > >>> > >>> (monadic extension) > >>> ```javascript > >>> let finalPromise = do { > >>> let a <- promiseA; > >>> let b <- promiseB; > >>> let c = f(a, b); > >>> g(a, b, c) > >>> } > >>> ``` > >>> > >>> (desugared to async/await) > >>> ```javascript > >>> let finalPromise = (async () => { > >>> let a = await promiseA; > >>> let b = await promiseB; > >>> let c = f(a, b); > >>> return g(a, b, c); > >>> })(); > >>> ``` > >>> > >>> (desugared to ES6) > >>> ```javascript > >>> let finalPromise = promiseA.then(a => > >>> promiseB.then(b => { > >>> let c = f(a, b); > >>> return g(a, b, c); > >>> }) > >>> ); > >>> ``` > >>> > >>> The do-notation would apply Promise.resolve to the last expression > (like > >>> async and Promise#then), effectively returning another Promise. The > current > >>> proposal doesn't specify this behavior, but there are two ways about > this > >>> collision: > >>> > >>> 1. use an explicit version of do-notation, e.g. `async do { ... }` or > >>> `do* { ... }` > >>> 2. revise the do-notation proposal to always apply Promise.resolve to > the > >>> last expression > >>> > >>> Both choices give us a new Promise literal for free: `do* { x }` (1) or > >>> `do { x }` (2) would be functionally equivalent to > `Promise.resolve(x)`. > >>> > >>> The idea was briefly mentioned several years ago, but didn't attract > much > >>> attention ( > >>> https://mail.mozilla.org/pipermail/es-discuss/2012-March/021624.html). > >>> > >>> This is an earlier draft of this proposal: > >>> https://github.com/edge/es-monadic > >>> _______________________________________________ > >>> es-discuss mailing list > >>> [email protected] > >>> https://mail.mozilla.org/listinfo/es-discuss > >>> > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > > > > > > > > ---------- > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
