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 <encryptedre...@gmail.com>
Date: 7 Feb, 17:07
To: es-discuss@mozilla.org

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 <waldron.r...@gmail.com>
Date: 7 Feb, 17:19
To: Raphael Mu <encryptedre...@gmail.com>, es-discuss@mozilla.org

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 <encryptedre...@gmail.com> 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss




----------
Re: monadic extension to do-notation
From: Kevin Smith <zenpars...@gmail.com>
Date: 7 Feb, 17:35
To: Rick Waldron <waldron.r...@gmail.com>, Raphael Mu <encryptedre...@gmail.com>, es-discuss@mozilla.org

Why not just use await within `async do`?

On 12:19PM, Sun, Feb 7, 2016 Rick Waldron <waldron.r...@gmail.com> 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 <encryptedre...@gmail.com>
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss




----------
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to