comby-tools/comby

Comby support for OCaml?

gasche opened this issue · 3 comments

gasche commented

Comby does not list OCaml in the list of supported languages in its documentation. I am opening this issue to ask:

  1. Whether @rvantonder already considered adding OCaml support, and has an estimate of the amount/difficulty of work included.
  2. Whether @rvantonder would possibly be interested in working on this, or one should find a contributor willing to do it.

Note: it might be possible to financially support work on this issue (I contribute to the OCaml Software Foundation, which has provided financial support for open source work of similar nature in the past; please send me an email if you would be interested in exploring this option).

rvantonder commented

Hi @gasche!

  1. It's a doc oversight, comby -list has a matcher for .ml / OCaml, so I will update the doc site.

  2. The current level of support, i.e., the fidelity at which OCaml syntax can be manipulated and refactored can't really be improved markedly beyond what it currently supports. Which is, in essence, a coarse syntactic representation of the parse tree (and much coarser than what the compiler would spit out). So, there are known limitations here, it is ultimately a coarse syntactic manipulator.

That said, refactoring syntax while incorporating semantic / type information is something I've always wanted to expand to, especially in the context of languages like OCaml. Here is a post on the concept, based on Go and LSIF support: https://comby.dev/blog/2022/08/31/comby-with-types. This idea is maybe also a bit more relevant to the ideas in the Discuss chatter 😄.

I don't think I have the bandwidth to work on this in depth though, even if sponsored 😅 But thanks for mentioning the possibility!

gasche commented

Thanks for the information!

Your answer prompted me to look at your work on ocaml-lsif and merlin-with-lsif (I wondered if there is a vendor-agnostic way to help towards better SourceGraph support for OCaml, and this seems to be a partial answer). What follows is a brain dump on what I understood, not a request for changes -- your documentation change "fixed" my issue as far as I can tell, and I will close the issue.

I think that it would be possible to implement a better second version of ocaml-lsif if there was interest:

  • if I understand correctly, more compact formats than LSIF have been designed since
  • instead of running a Merlin query on each AST node, I think that one could dump LSIF information from the typedtree directly, resulting in major efficiency gains
  • there is ongoing work between Merlin and the OCaml compiler to support "list all occurrences of this definition" (see for example ocaml/ocaml#12508 ), and there may be some synergy between this work and the sort of indexing that you would need

I understand that you @rvantonder are focusing on other things now and don't have bandwith to contribute towards OCaml support. (It's a usual problem with more-niche languages that the tooling work to support them well is harder to justify, which unfortunately leads to a second-class feeling over time.) If you happen to have ideas/feedback/suggestions to improve OCaml support in "generic code intelligence" platforms (SourceGraph or others), I would of course be interested in hearing about them, here or by email (gabriel dot scherer at gmail).