Please feel free to comment with specifics.
Please feel free to comment with specifics.
May I ask, since async/await is only beneficial for JS-compiled Reason due to the built-in Promise, what about the Ocaml-compiled ones? I doubt there is an A+ implementation for that
Let me clarify. There is a new OCaml syntax that can handle the async/await style of programming, called ‘let+ syntax’: http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-syntax.html
Of course, that’s not to say that ReasonML would adopt that syntax as well, but I think at least there’s a good chance that it might happen.
I think you misunderstood me. I am referring about the internals. Syntax is not a problem, what I am asking is how does Ocaml implement or support A+ ( I have never used Ocaml before, so I am curious about that)
favor async functions and await over hand-written promise code, and
to benefit from the shortcuts, i.e. avoiding two microticks for await.
– V8 Blog
I’m not sure what you mean now are you asking about ‘let+ syntax’? OCaml now supports that natively (in version 4.08 onwards), with no preprocessors needed. The mechanism from a user’s perspective is explained in the article I linked. From an implementation perspective, I don’t know the details, but if you’re interested here is the PR for the new syntax: https://github.com/ocaml/ocaml/pull/1947
I am not referring to the syntax, I am referring to Promise itself (A+ is the Promise specification: https://promisesaplus.com/), which is why I need clarification on how does Ocaml support or implement A+ (Promise, in case you are confused).
so with this syntax proposal, you are only planning to target support for BuckleScript-compiled (JS) ReasonML?
No, this (already-existing) syntax can support any platform as long as it is ported to it. It will essentially desugar into chains of
.then(...) or similar calls depending on the exact platform and exact data type. Currently it exists natively on OCaml 4.08, and has been backported to earlier OCaml versions but only using the Dune build system. I’m saying that it’s a good candidate for including in Reason to get support for a wide range of use-cases, including async/await.
Edit: see the article I posted for details.
Absolutely yes for web/JS as a target platform. In the conference, I got the feeling that because the vast majority of Reason devs work with React, and that because Promises are not important or necessary in React (I’m not a React dev, so apologies if I misunderstood), async/await therefore is not important/necessary as well.
No opinion for native.
Promises are built-in for non-blocking processes for functions such as fetch. I don’t know how would they say “Promises are not necessary”.
I haven’t kept up with the let+ syntax in OCaml, so don’t assume I know anything about the details here.
Specifically on the topic of async/await syntax for JS promises, I’d prefer not having language-level sugar that is specific to an FFI feature (particularly one as flawed as JS promises).
If anything, as a Reason/OCaml/FP newbie I’d like to hear more about what does the Reason team recommends instead of async/await, or, at least, what’s their considerations. IIRC, Cheng Lou mentioned they’re very cautious with async patterns in Reason and kind of waiting for the community to experiment with them some more.
(He also mentioned the React team had some issues with async data fetching, I wonder what those are.)
As a tangential, as someone planning to introduce Reason to a React/Redux project or two, I’m also curious about the Redux middleware story. I take it that Reason doesn’t support generators, so Redux-saga is out of the question, and, anyway, maybe something like Redux-cycles is a better functional approach?
Hi hoichi, the official recommendation from the Reason team is here: https://reasonml.github.io/docs/en/faq#what-s-bucklescript-s-async-story
Part of the community experimentation around an async syntax sugar has been projects like Jared Forsyth’s let-anything which actually is pretty close to OCaml 4.08’s new ‘let+’ syntax. I think there is a question with these syntaxes of how to do error-handling in an elegant and idiomatic way (i.e. something that will compile down to
Regarding the Redux middleware question, I recommend a new thread for that
Thank you! And you’re right about the new thread, of course.