In such case since you want to use ReasonML, I am confused why you’re posting the issues here. The language semantics are the same, but the parser is different and so is the tooling. Yes, there are a few people using ReasonML here as well but you will probably find a lot more in the ReasonML Forums and they will be more capable of helping you with the Reason tooling.
I find myself disappointed at this comment. I have experienced that OCaml and ReasonML are two different communities, and I have publicly wished for them to work closer together (I’ve made a library to help too). It makes me sad to see people here tell people – a newcomer trying to improve tooling, no less – to go to “the other community”.
Would love to see people working to allow these two communities to be one, including welcoming people with a ReasonML background into this forum.
If someone asked for F# help here, an answer like “sure we can try but you will probably find better help with F# in the dedicated F# community” would’ve been probably fair, right?
In the case of ReasonML, the syntax is different, the build system is different, the deployment is different (often using a different OCaml compiler), the package management is different (there are very few ReasonML packages on OPAM, it for sure is possible but uncommon), the standard library used is different, the main usecase is different (a much stronger focus on Web and integration with JS) and the community is different (coming mostly from JavaScript, whereas OCaml programmers seem to come from a more academic context). I don’t mean this as a judgement of any kind, I am just saying that the divergence in the ecosystem is big enough that for practical purposes it is not just an alternative syntax, even if the core language semantics are the exact same.
I do welcome people with ReasonML background here (apologies to @mbernat if it sounded otherwise), though to me it seemed like OP wanted OCaml and ReasonML to work using the same tooling, which is quite difficult (e.g. Merlin works, and dune supposedly too but there is very little first party documentation on how to get started). My impression is that this is probably more trouble than it is worth, since there are probably few people who use both, so setting up the environments separately is easier.
I think everyone here is perfectly happy with sharing how they set up their OCaml tooling and how that can be improved to be better for newcomers, which — I definitely agree — is currently rather on the difficult side when it comes to setting it up (and also w.r.t. best practices; even for experienced OCaml developers).
I do welcome people with ReasonML background here (apologies to @mbernat if it sounded otherwise),
I do feel welcome and an apology is not necessary. I have to say the lukewarm-to-negative responses I got were a bit disheartening but I understand people have different views and priorities.
You seem to have two concerns, one with respect to tooling and the other with respect to people’s backgrounds.
The tooling is split, but there’s no reason for this to be so. As an example: esy works with both opam and npm packages. They also could’ve chosen to ignore opam and it would have been a terrible mistake. Other projects should follow suit. There’s a tiny additional cost for supporting both OCaml and ReasonML, whereas the gains are huge (enabling two sets of people to talk to each other).
People always have different backgrounds. I’m certain no two people in the current OCaml community share it. Some will work on purely academic stuff, others on unikernels, yet others on machine learning, blockchain, webapps, etc. So background is a very poor excuse in splitting what should be a single community. Even more so when OCaml is an extremely niche language and would benefit from growing, not creating silos.
Finally, the way you talk about ReasonML it’s clear you mean the Bucklescript ecosystem and don’t acknowledge there are people (such as myself) using Reason for native projects. For these people Reason really is just syntax, nothing else, and so it should be on equal footing with Ocaml syntax when it comes to standard tooling. Note that I’m saying should, I don’t expect this to happen immediately, but it certainly should be a long-term goal.
I do agree it’s a good goal for there to be solid support for Reason-the-syntax in the “standard” set of tools. Dune already supports it, as far as I understand. I guess editor support is the primary missing piece, and hopefully having a high quality language server will mostly take care of that part of the puzzle.
So I think the things you’re looking for are in the planning stage, but I agree the current situation isn’t ideal.
This is my view as well. From a tooling perspective, we’ve got three major communities (at least) all extending core OCaml today: ReasonML, MirageOS and Coq. So we want to make sure that the inner tools that are layered onto the compiler are as extensible as possible to avoid baking in domain-specific knowledge too much. Sometimes though, the technical cost is reasonable. So far we have:
dune-release: supports opam, mirage, could be extended to reason/npm with contribution
As you can see, the OCaml Platform support matrix for our diverse communities is already pretty good. Where there are technical barriers (for example due to the complexity of the Bucklescript integration), it takes time to make the architectures match, and we’re not rushing to do that until both sides settle down.
As a concrete next step, the LSP developers have reached consensus to build a general OCaml version (that acts as a frontend to the OCaml build, formatting, debugging and documentation tools instead of going solely through merlin). I’ve created that repository at https://github.com/ocaml/ocaml-lsp, and @rgrinberg@let-def@trefis@andreypopp will populate it shortly.
Keep the Reason->OCaml contributions coming please. I’d be delighted to see more Reason libraries released into opam, and efforts to help us release some of our pure OCaml libraries (e.g. Mirage ones like ipaddr, uri, tcpip) into Reason are also welcome.
Since it’s going to be new anyway, I would love for ocaml-lsp to have a separate library that handles only the LSP protocole (ie wire protocole+json messages encoding/decoding) in a way that is agnostic to what language is analyzed.
OCaml is so often used to implement interpreters and compilers and proof assistants, that it would be very helpful to help build good tooling for these too (ie lower the barrier for writing a LSP server for your language by just requiring a library).
That already exists, even if not really properly packaged; I’ll let more knowledgeable people to point to the most up-to-date version.
The LSP protocol is pretty simple tho, with a bit of YOJSON I’ve bootstrapped a couple of servers.
The biggest challenge for me was actually that my server needed some kind of interruptible threading as to do heavy computations, that’s still not super well solved in OCaml and required us to implement a custom server protocol. [advice on that would be great]
I agree that the wire protocol isn’t that hard (I wrote a jsonrpc impl) but there’s a ton of json types to define, so that’s a bit annoying. It would be much better to have a central library that everyone can build upon.
Note, that two more LSP-like things can be beneficial too:
DAP (Debug Adapter Protocol) - abstracting the way how the debugging support of development tools communicates with debuggers or runtimes into a protocol. Since majority of OCaml developers use either VS Code (which has DAP) or Emacs - see the Emacs DAP Mode example.
LSIF (Language Server Index Format) - a standard format for language servers or other programming tools to dump their knowledge about a workspace. This dump can later be used to answer language server LSP requests for the same workspace without running the language server itself.
As someone that invests efforts in improving the OCaml user experience, one should that I think is worth realizing in the OCaml/Reason discussion is that, to the best my knowlege, the various Reason communities do not currently seem very interested in contributing back to the core OCaml implementation or tooling ecosystem. (Please let me know if I missed something!)
There are some efforts for core OCaml tools to accomodate Reason and/or new tooling, or at least to turn their tooling suggestions into long-term features – for example, the convenience of caching in esy encouraged us to reconsider once again the relocatability issues in the compiler, and @dra27 now has a plan that may bring relocatability in the short/medium-term. In the other direction, the Reason people are very friendly and have interesting ideas and suggestions, but they seem too busy with their own ecosystem to contribute regularly to the core compiler or tools.
(One interesting cross-community contribution is the ocamlformat tool that was developed within Facebook.)
This is not a criticism (I think it’s perfectly fine that people have different priorities to direct the use of their limited time), but it may also partly explain why crossing the two ecosystems is not always as smooth as we would like.