-
Notifications
You must be signed in to change notification settings - Fork 5
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
Futures/Promises thoughts #6
Comments
@rockymadden The issue in this case should be to find a straightforward way to deal with method chaining. |
The most common pattern to achieve methods chain in Ramda is to combine
|
I think there is a lot of things to discuss in this thread if you are still interested. The main idea behind RamdaScript is to use Ramda as a Lisp. So, to add another libraries to the core would mean move away from its le motif. You may notice that RamdaScript has some functions which are not part of Ramda, example: The translation from RamdaScript to JS is plain and straightforward because Ramda is very powerful. So, the hard work of the compiler is the semantic checker and the compilation of functions aiming JS interop to take advantage of the JavaScript ecosystem of which That said, we may conclude that it is possible to take advantage of
|
I apologize in advance that this is not an actual issue, but more of a conversation if you are willing to entertain/have the bandwidth. I am curious about your thoughts on how one might approach adding Future (https://github.com/fluture-js/Fluture), Promise, and/or async/await support to the core language. To the novice lisper/ramdascripter, it seems like a few items might be addressed/thought through first:
If going the Future route and you added Fluture functions to the core ramdascript language, like
fork
(https://github.com/fluture-js/Fluture#fork), you could then do it fairly easily in ramdascript right? Something akin to:The text was updated successfully, but these errors were encountered: