Hi everyone,
Since there have been a lot of questions regarding future Reason / OCaml support in BuckleScript, we assembled a new blog post to be more explicit about the situation:
We hope this will address most questions and concerns (at least for now).
Please note that the team has a whole list of topics they want to talk about, so stay tuned for more details soon!
Cheers
Hey,
thanks for the update. Reassuring indeed. I have a question about reason-language-server. I understand that many people are using it now but it’s another non-trivial piece of infrastructure to support. There are some ways in which it might be nicer than ocaml-lsp but also many in which it’s worse. Given the lack of man-power to develop it, ocaml-lsp is destined to outdo it in every possible way. It’d be great to understand what’s the reasoning and maintenance plans when it comes to editor integration.
@wokalski For one, I’ve said elsewhere that we should not end up with e.g. 3 lang-servers, which I think everyone can agree with!
We do understand that there’s ocaml-lsp, which is precisely why we think, in the worst case, you’d want to take RLS and shape it into something that’s e.g. BuckleScript-specific. This way RLS ends up not stepping on OLS, and on the BuckleScript side, users also get what they want, which is a specific, vertically integrated plugin akin to the new syntax announcement.
For the editor tooling, I think this is a win-win direction.
It is, especially with a separate file extension so that I can run it alongside OLS. To put it bluntly my question is: who is going to support it?
To put it another way
you’d want to take RLS and shape it into something that’s e.g. BuckleScript-specific
this makes a lot of sense but then it should be pulled inside bucklescript and renamed to bucklescript-lsp.
who is going to support it
The BuckleScript maintainer(s) and those in that part of the community. What’s important is that even if it stays in the current less-than-ideal state, the consequences won’t spill over to the folks working on the native-related stuff, e.g. OLS and others.
this makes a lot of sense but then it should be pulled inside bucklescript and renamed to bucklescript-lsp.
We can do that, yeah.
And it should be as good as ocaml-lsp. Otherwise you are creating a lot of pain to people who (1) invested efforts into getting ocaml-lsp usable with bucklescript (2) enjoy working on files partially broken.
What’s important is that even if it stays in the current less-than-ideal state, the consequences won’t spill over to the folks working on the native-related stuff, e.g. OLS and others.
Too late. OLS is already not native specific.
@khady dunno about others, but I’ve never voiced my support for making OLS cater to BS (I’ve never voiced my non-support of this either though, to be fair). Understandably user land folks took the initiative and poured effort into it, which I appreciate regardless.
The specializing RLS thing is just a plan for now, but we’ll try to execute it well. If it benefits your maintenance sanity, then please know that I personally am on board with removing BS-specific support from OLS.
I think it’s too early drawing conclusions on structures that are currently forming. It’s important to give everyone the time to understand the whole situation… it took me a considerable amount of time to e.g. getting into odoc and understand what problems I am currently trying to solve (like the json export), and even after extensive discussions we didn’t really align with the OCaml folks… so we needed to temporarily branch out showing what we are looking for before we can converge into something more general.
We’ll definitely need someone on the BS team to commit more time on this topic, otherwise things will always get out of sync for some weird communication reasons, I’d assume.
I also have completely lost track over all the different VSCode plugins / language servers that are currently in development. So let’s definitely talk about a complete picture before jumping guns?
Thank you for clarifying. 
(I asked this in the other post, but it got buried: ) Why are the BuckleScript 8.x posts now on the ReasonML blog instead of https://bucklescript.github.io/blog ? Is a merger of the two sites in the works, perhaps?
The goal was to merge the blogs of all important infrastructure (Reason syntax, BuckleScript, ReasonReact, etc.) to reasonml.org.
I think @bobzhang stopped posting original posts on the bucklescript.github.io page (which also got cross posted on the new websites). I recommend checking the reasonml.org/blog page when checking for the newest content!
Is there any change with regard to First Class Modules? There has been a little bit of confusion regarding them (applicatives and other abstractions that use them)
This twitter reply to a Discord screenshot by @chenglou helps put things in context. Independently (I assume), two users reached out and asked has anything changed about Functors with the screenshot - I think there is some speculation around the topic.
Can the/a blog post make a mention about FCM? For instance, should Bucklescript users change the way the use FCMs? Are there any changes to the best practices/guidelines?
Clarification: the point about PS in the thread is not relevant here (although the clarification helped).
There’s been no changes to ocaml functors nor first class modules, aside from the syntax tweak of the latter we’ve blogged about in the previous post.
Thanks for the blog post which helps a lot. There was a brief discussion in discord today about how it would be useful to have some design goals about the project. This would help prevent second guessing what might be in or out in the future as a bit too much is implied at the moment. Even something fairly simple would help. Thanks.
So for now everything in ocaml except the object oriented system is out? Right? What about currying and/or partial function application, is this in?
@yunti yes we’re trying to do that better. We’ve been communicating a bit more recently.
@bikallem not sure what you mean.
@zth Maxim, Cristiano, Bob and me.
So great to hear a language server will get some love. We have been in dark ages with two alternatives that both have pretty major flaws.
Yup, and for starters https://github.com/jaredly/reason-language-server/ could move to https://github.com/reasonml-editor