monadic extension to do-notation

Raphael Mu encryptedredux at gmail.com
Sun Feb 7 19:34:42 UTC 2016


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 <ljharb at gmail.com> 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 AM, Raphael Mu <encryptedredux at gmail.com>
> wrote:
>
>> The `a < -b` issue could be solved by using a different operator, like
>> `</` or `<#`.
>>
>> On Sun, Feb 7, 2016 at 12:35 PM Kevin Smith <zenparsing at gmail.com> wrote:
>>
>>> Why not just use await within `async do`?
>>>
>>> On 12:19PM, Sun, Feb 7, 2016 Rick Waldron <waldron.rick at 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 <encryptedredux at 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 at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160207/0b82e09c/attachment.html>


More information about the es-discuss mailing list