-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
Wrap lwt and Async? #19
Comments
I think this would definitely make sense :) My original plan was to implement the "core" of the wrapping in Repromise and/or Lwt/Async, and leave more specific things, like isomorphic HTTP clients, to other libraries that would then build over that core (for example, I think having strong native/node/(partially browser) ecosystem compatibility would make Reason a uniquely powerful language. It should save an enormous amount of learning and development time for users. |
Hey @bobpoekert @aantron ! I'm working on these at the moment all built with reason
At the moment these use |
@kennetpostigo How are you implementing your cross-platform fetch? Do you have converters/wrappers from bucklescript promises to lwt promises and a stripped-down version of lwt that runs on bucklescript? Or do you have some other promise type that wraps both? |
@bobpoekert js side uses what bucklescript exposes, but native side uses unix pipes |
@kennetpostigo but what's the common abstraction that cross-platform consumer code uses? |
@bobpoekert |
@kennetpostigo @bobpoekert is asking, I believe, what is the underlying synchronization primitive (e.g. promise implementation) that is being compiled to native and js, that lwt-node would build its isomorphic API over. The answer to that is, I think, that lwt-node is not there yet. Repromise has isomorphic native/js promises, but it is not yet compatible with Lwt (or Async). lwt-node uses Lwt right now, and so presumably is native-only for the time being. |
oh right, like I said before, right now for js we're using what bucklescript offers and for native we are using unix pipes. Theres no code sharing tho for the http client(fetch) |
There is now a super basic POC of Repromise/Lwt interop here. Basically, Lwt_unix (the I/O part of Lwt) drives the process I/O loop, and calls into Repromise when I/O resolves a promise and triggers a callback. There are also two functions for converting Lwt and Repromise promises between each other. The test case has a simple wrapper around |
Hey @aantron, this looks like a super-promising library, are there still plans for this? Perhaps this would also be interesting from the previous discussion's perspective? https://github.com/anuragsoni/fetch/ |
Yep, still planning to look into this in great detail :) From the other end, there is also https://github.com/aantron/luv, for rewriting Lwt over libuv (what's used by Node internally for I/O). That's what I've spent the most time on recently. Most recently, though, I went on a small hiatus, but planning to come back to all this soon. |
Oh, very interesting, there's lots of potential for making the community more approachable here! Thanks for all your hard work, excited to follow the progress on these! 🙏 |
I'm going to close this issue to keep the repo tidy, because progress needs to be tracked in other repos that would drive Repromise:
Even though this issue is closed, further discussion is welcome! |
Most native reason code is going to be wrapping opam libraries for doing things like http requests and database queries, and those native libraries are going to be using either lwt or Async. It would be great if you could, for example, have an http client library that used either bs-fetch or cohttp under the hood, depending on the platform, and exposed a common api for both. Is this something that it would make sense for repromise to do, or would it make more sense for that to be a separate library?
The text was updated successfully, but these errors were encountered: