What do you feel is more beneficial for OCaml programmers based on its usage right now?
Do you feel any of these could be useful for people programming in OCaml? or are there already tools which can do this that I just haven’t discovered yet?
(post deleted by author)
One tool I would like to have available is a tool to automatically rewrite large codebases to apply API updates to libraries that are being used, using semantic patches à la Coccinelle. I think it could change the way we consider compatibility for libraries: instead of being afraid to break compatibility in principle, library authors could provide semantic patches to reduce upgrade cost for users.
(I have discussed this in the past with various people. In theory it’s not too hard to do. One of the issues is that I think the action of the tool should be easy to review in standard version-control systems, and that requires either:
)
I don’t know if you know about this tool, but GitHub - v-gb/ocamlmig I believe does check some of the boxes you describe. It’s a very cool tool!
The ergonomics seems very well thought of in my opinion: It does support rewrite annotations that you add to your mlis, and once the annotations are in opam, users simply call ocamlmig migrate after installing the new packages, and then … voila : auto-migration happens in your tree. I tried to be an early adopter and released a few ocamlmig annotations in actual opam packages. Very fun. Do check it out!
Thanks for the reference! I haven’t found a high-level description of the implementation to find out how it deals with (re)formatting, but based on this comment it seems to assume that ocamlformat is being used.
(cc @v-gb)
Clearly, it’s easiest to refactor ocamlformatted code (although even then, I ran into a number of assertion failures and undesirable formattings due to ocamlformat essentially assuming that the ast is unchanged).
But from ocamlmig/doc/using.md at main · v-gb/ocamlmig · GitHub :
If your repo isn’t configured to use ocamlformat, ocamlmig will print code in a way that tries to preserve the initial formatting. This is more experimental, so if you observe issues, you may want to try
ocamlmig migrate -format ocamlformatto see if it makes a difference.
Concretely, the printing compares ast before and after rewrite (shallowly), and so long as they agree, the printing recurses into the children asts. When they disagree, the new ast is ocamlformated and plonked into the section of the source file where the old ast was. This kind of string splicing can result in code that doesn’t lex/parse as intended, so the code detects such situations to avoid them.
Long story short, there is little or no reformatting when changing ast leaves (renaming things, adding parameters, etc).
From inside the library, it’s also possible to build a change by surgically adding strings to the input source file, rather than building a new ast. This works ok for simple changes (although you tend to end up with excessive parens because it’s hard to know for sure you won’t need them), but doesn’t really for complicated changes.
Not that I would not love to have the tool you describe but I think that this:
is a bit misguided. Any maintenance work you have to do has a cost whether you have a semantic patch or not.
People create something and then move on. For example I don’t think that those issues I (automatically) opened for cmdliner 2.0.0 a couple of months ago that are still open are because of the concrete migration cost (which are tiny).
So no, as far as I’m concerned, I don’t think that if I had such a tool it would change the way consider compatibility for the libraries I distribute. Breaking backward compatbility for “done” or in maintenance software is always annoying and costly.
I think making perf work better with OCaml code would be a worthwhile goal. Then that opens up using all the tooling around perf, particularly flamegraphs.
In my experience perf works fine with frame-pointers enabled. For more focused profiling though let-def/perfctl might be useful.
Did you have anything specific in mind as to what kind of improvements could be made?
perf should work well with frame pointers, there’s even a section for the manual coming in 5.4 release. The two remaining issues I’ve got are name mangling makes it difficult to map symbols in perf back to source locations and DWARF information produced by the compiler isn’t always enough to do things like perf annonate . Then also frame pointers not being available on some architectures but we do cover AMD64 and ARM64 with OCaml 5.4.
Apart from that, what kind of improvements are you thinking of? @rwmjones