New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future of js-promises branch #647

Closed
osener opened this Issue Jan 5, 2019 · 7 comments

Comments

Projects
None yet
2 participants
@osener
Copy link

osener commented Jan 5, 2019

I'm using Lwt in a project which uses Native OCaml compiler & BuckleScript together with some code sharing, and having a pretty good experience with the js-promises branch. Are there any plans to move BuckleScript support forward?

@aantron

This comment has been minimized.

Copy link
Collaborator

aantron commented Jan 5, 2019

@osener, js-promises is based on JS promises in a naive way, the same way as Js.Promise from BuckleScript, and is susceptible to this problem: https://aantron.github.io/repromise/docs/DesignFAQ#why-are-js-promises-not-type-safe. I recommend using Repromise instead (which I think you are already trying), because it is meant to address that issue.

There are some plans for being able to run Lwt and Repromise in one process on the native side in the future, to be able to take advantage of all the native libraries based on Lwt.

One way is by basing Repromise on existing Lwt. A POC for this is Repromise_lwt, here is some sample code.

The other way is by binding to libuv, which is the C library that implements Node's I/O, and then having that binding drive both Lwt and Repromise. Here is such a binding, and sample code showing Lwt and Repromise being used together.

The js-promise branch itself probably has no future for the above reasons. It was mostly useful for discovering the exact semantic differences between Lwt and JS promises by trying to substitute one with the other, so that the two could be integrated intelligently.

@osener

This comment has been minimized.

Copy link

osener commented Jan 5, 2019

Indeed, I'm having a great time using Repromise in some front-end projects (in Reason). But another project I'm building entirely in OCaml has a large native codebase that heavily relies on Uwt and Lwt, in which I'm sharing code between front-end and backend.

I'm aware of the unsoundness of JS promises, what I'm after are the semantics of the Lwt library itself which I like and built many utilities around. I also rely heavily on modules such as Lwt_mvar.

I'd be interested in, and would love to help with, an approach that goes the other way around, if js-promises has no future. Instead of using Repromise on native side, I'd prefer to use Lwt on top of sound Repromises with BuckleScript. Does this make sense?

@aantron

This comment has been minimized.

Copy link
Collaborator

aantron commented Jan 5, 2019

That should be possible, too. It would still be missing some of the other Lwt features that js-promises is missing, like cancellation, but most of these are "discouraged" anyway.

@aantron

This comment has been minimized.

Copy link
Collaborator

aantron commented Jan 5, 2019

Note that some of the semantics of js-promises are different, both now, and if built (directly) over Repromise. For example, js-promises always defers callback calls to the next tick, while Lwt sometimes runs callbacks immediately.

@osener

This comment has been minimized.

Copy link

osener commented Jan 5, 2019

Note that some of the semantics of js-promises are different,

Wouldn't expect to be otherwise, wrong word choice.

@osener osener closed this Jan 5, 2019

@osener

This comment has been minimized.

Copy link

osener commented Jan 5, 2019

I'll give a repromise-based Lwt a chance when I have the time!

@aantron

This comment has been minimized.

Copy link
Collaborator

aantron commented Jan 6, 2019

Ok, great :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment