Rescript-compiler: ppx support for promise

[bobzhang]

instead of providing a generic syntax extension for monad, we will provide a specialized syntax extension for promise

[little-arhat]

What about https://github.com/janestreet/ppx_let ? This way, one can perhaps use Lwt, Async or whatever monadic io they want using the same syntax extension.

[bobzhang]

We would think about if this could be done on the user level without sacrificing the user experience. (promise will become pervasive in es6 and forthcoming es7 & 8, it makes sense to provide the best user experience)
The tricky part is error handling, they are not exactly the same, I will do more research

[little-arhat]

Why do you want promises in bs? It seems, that we, being able to write code in good language, have more powerful tools to deal with async stuff. So, I think it makes sense to only support promises for interop, but write code inside your app or library using some monadic io library.

This way, we can:

• have good, familiar API inside app/library;
• easily port/use existing libraries that use lwt/async.

So, I think, it would make sense to provide way to convert to/from promises from/to one's favourite monadic IO libraryr.

[bobzhang]

we should prioritize the bindings for promises
maybe we can put it here (https://github.com/bloomberg/bucklescript-addons) before we finalize the API
CC @abhirmathur
Also see if we could simplify the NodeJS callback style without promise

[bobzhang]

this is a design problem, delayed when we have enough experience

[bobzhang]

note that we already have some bindings for promise:
https://github.com/bloomberg/bucklescript-addons/blob/master/bindings/bs-promise/src/bs_promise.mli

About syntactic sugar:

Options:

let [@bs] v = promise in ...

let v [@bs] = promise

let%bs v = promise in

Janestreet's ppx bind does not work for promise, since the callback expect an uncurried function

[ghost]

I agree that it's probably better to wait a while on adding syntax sugar. Having to use explicit combinators for Promises is really not that bad.

let [@bs] v = ...

I think this one is better than the other because it follows the same pattern as

fun [@bs] v -> …

One thing that would be nice is if we could have a syntax that worked with async and await. I use those when possible instead of Promise explicitly and the code is so much cleaner looking.

[bobzhang]

@freebroccolo Indeed, I am still doing research on how JS async work. My impression is that async await is slow syntactic sugar, is it more capable than Promise?

[ghost]

@bobzhang Currently I am using async/await with babel, translating down to standard es6. There are several available translations as babel plugins that have different performance characteristics but I've mostly just used transform-async-to-generator. I think it should be reasonably efficient. (Note that babel doesn't do any optimizations by default, so if you want to test that specifically I'd suggest combining it with babel-minify or closure).

As far as being more capable, it depends. You should be able to express the same things, it's just that working directly with Promise is much more painful for some code. Here's a little example of a package I made where I think the async approach is nicer.

[bobzhang]

closed as a duplication of #1214