Improvements to OCaml code editing: the basics of a refactor engine (opens in new tab)

(tarides.com)

99 pointsnukifw7mo ago18 comments

18 comments

Extract expression is such a common refactoring, happy to see support for it. I'm even more curious to see now if there are going to be more advanced refactoring possible. A List.map, to for loop, and back refactoring would be such a great thing to have in how I program.

Only thing that would go on my OCD nerve, is the lack of an empty newline when the show_markup function is extracted. Kind of "common sense" when writing top level bindings to leave some breathing room between them.

nukifwOP7mo ago

For the first point, you are right. We start by a common (but very useful) feature. Since OCaml allows an infinite level of nesting (and different kind of structure item) it was still a bit of a challenge, mostly for finding the right UX.

For the second point we delay the aeration convention to the formatter (ocamlformat). It can be configure in a different way :)

Thanks for your feedback!

panglesd7mo ago

Very cool!

Does it replace identical expressions in the same scope? Like:

    let tau = 3.14 +. 3.14

becomes

    let pi = 3.14
    let tau = pi +. pi

EDIT: Or even crazier with function:

    let _ = (x + 1) + (y + 1)

becomes

    let plus_one a = a + 1
    let _ = (plus_one x) + (plus_one y)

(I ask this just out of curiosity. Even the "simpler" version is very impressive!)

nukifwOP7mo ago

Nop, for the moment, we try to not "infer user usages"! But if you extract an expression with variable, there will be, obviously, not be repeated:

    let tau =
      let pi = 3.14 in 
      pi + pi

if we extract `pi + pi` it will lead (if you do not give any concrete name) to the following code:

    let fun_name1 pi = 
       pi + pi

    let tau = 
       let pi = 3.14 in 
       fun_name1 pi

ethan_smith7mo ago

Most refactoring engines don't automatically replace all identical expressions by default since it can change semantics (especially with side effects), but they typically offer a separate "introduce and replace all occurrences" option that you can explicitly choose.

greener_grass7mo ago

LLM generated variable names would be nice!

lemonwaterlime7mo ago

I’ve been working on similar refactoring and grepping utility functions for vim, though mine are meant to work in any language.

The most recent one I’ve made runs 'git grep' on the word under cursor or on the visual selection and puts everything into a quick fix list.

Since it is generic, it works on any phrases as well, and helps me find prose snippets and phrases in docs or other writings.

shortrounddev27mo ago

I feel that Ocaml could really use better VSCode integration more than literally anything else, but the community seems completely oriented around emacs

nukifwOP7mo ago

We try to invest equal time between the OCaml platform (on VSCode) and OCaml-eglot (for Emacs). In fact, I find the VSCode extension to be rich (and generally iso-features with Emacs mode).

However, I (as maintainer of OCaml-eglot) find Emacs easier to extend (the VSCode extension is surprisingly complex when you stray from the beaten path), which seemed perfect for incubating an experimental feature. Furthermore, as mentioned at the end of the article, the feature can also be invoked from a code action, which makes it de facto callable from VSCode once the various PRs have been merged :)

shortrounddev27mo ago

The LSP features, in my experience, work very well in VScode, no shade there. But debugging features like breakpoints still seem to be experimental? Whenever I ask others about it online they usually try to tell me that print debugging is superior anyways

StopDisinfo9107mo ago

My experience is that everything goes into Merlin, which is Ocaml tool for analysis and refactoring, and is then added to editor from there.

Here significant work was done to properly bridge the gap between Merlin and the LSP server so it should work fine in VSCode.

Generally speaking, the Ocaml community seems to spend a lot of time getting VSCode to work.

MutedEstate457mo ago

Great work! Definitely feels a lot more technical than the typical internship project.

amelius7mo ago

Anyone tried large codebase refactorings using AI?

Syzygies7mo ago

Tarides has an OCaml focus. Elsewhere on their site, with an interesting omission:

"Examples of functional programming languages include OCaml, Erlang, Clojure, Haskell, Scala, and Common Lisp."

F# and OCaml are close cousins, and for me F# is even cleaner syntax and twice as fast (M4 Mac Studio).

It was a struggle for me to overcome my partisan preference for OCaml.

StopDisinfo9107mo ago

F# started as an Ocaml port to the CLR. In the end, they decided to port a subset of the language so you get mostly the same syntax, no parametrised modules which is a big part of Ocaml but in exchange you can call libraries from other languages using the CLR. Of course, that comes with the issue of being a second class citizen in the .Net family, albeit a very nice second class citizen.

F# have drifted a bit further since but not that much. It’s a nice language but it’s not really comparable to Ocaml at this point. At least, I don’t see many cases where people would have to chose one or the other. I think people know if they want the CLR or not.

Syzygies7mo ago

I make little use of .NET; my hand-coded atomic queue is faster than .NET work stealing for parallelism, for example. I like the slightly cleaner syntax and twice as fast for my applications.

I'm escaping the black hole of Haskell. If one can code in Chez Scheme, one can code without parametrized modules, as much as I admire them. And there are also F# additions OCaml could admire.

I held back for all of your reasons, and finally caved. I never saw myself in the .NET ecosystem, but prejudices are a funny thing.

1 more reply

j / k navigate · click thread line to collapse

18 comments

mhitza7mo ago

nukifwOP7mo ago

For the second point we delay the aeration convention to the formatter (ocamlformat). It can be configure in a different way :)

Thanks for your feedback!

panglesd7mo ago

Very cool!

Does it replace identical expressions in the same scope? Like:

    let tau = 3.14 +. 3.14

becomes

    let pi = 3.14
    let tau = pi +. pi

EDIT: Or even crazier with function:

    let _ = (x + 1) + (y + 1)

becomes

    let plus_one a = a + 1
    let _ = (plus_one x) + (plus_one y)

(I ask this just out of curiosity. Even the "simpler" version is very impressive!)

nukifwOP7mo ago

Nop, for the moment, we try to not "infer user usages"! But if you extract an expression with variable, there will be, obviously, not be repeated:

    let tau =
      let pi = 3.14 in 
      pi + pi

if we extract `pi + pi` it will lead (if you do not give any concrete name) to the following code:

    let fun_name1 pi = 
       pi + pi

    let tau = 
       let pi = 3.14 in 
       fun_name1 pi

ethan_smith7mo ago

greener_grass7mo ago

LLM generated variable names would be nice!

lemonwaterlime7mo ago

I’ve been working on similar refactoring and grepping utility functions for vim, though mine are meant to work in any language.

The most recent one I’ve made runs 'git grep' on the word under cursor or on the visual selection and puts everything into a quick fix list.

Since it is generic, it works on any phrases as well, and helps me find prose snippets and phrases in docs or other writings.

shortrounddev27mo ago

I feel that Ocaml could really use better VSCode integration more than literally anything else, but the community seems completely oriented around emacs

nukifwOP7mo ago

We try to invest equal time between the OCaml platform (on VSCode) and OCaml-eglot (for Emacs). In fact, I find the VSCode extension to be rich (and generally iso-features with Emacs mode).

shortrounddev27mo ago

StopDisinfo9107mo ago

My experience is that everything goes into Merlin, which is Ocaml tool for analysis and refactoring, and is then added to editor from there.

Here significant work was done to properly bridge the gap between Merlin and the LSP server so it should work fine in VSCode.

Generally speaking, the Ocaml community seems to spend a lot of time getting VSCode to work.

MutedEstate457mo ago

Great work! Definitely feels a lot more technical than the typical internship project.

amelius7mo ago

Anyone tried large codebase refactorings using AI?

Syzygies7mo ago

Tarides has an OCaml focus. Elsewhere on their site, with an interesting omission:

"Examples of functional programming languages include OCaml, Erlang, Clojure, Haskell, Scala, and Common Lisp."

F# and OCaml are close cousins, and for me F# is even cleaner syntax and twice as fast (M4 Mac Studio).

It was a struggle for me to overcome my partisan preference for OCaml.

StopDisinfo9107mo ago

Syzygies7mo ago

I make little use of .NET; my hand-coded atomic queue is faster than .NET work stealing for parallelism, for example. I like the slightly cleaner syntax and twice as fast for my applications.

I'm escaping the black hole of Haskell. If one can code in Chez Scheme, one can code without parametrized modules, as much as I admire them. And there are also F# additions OCaml could admire.

I held back for all of your reasons, and finally caved. I never saw myself in the .NET ecosystem, but prejudices are a funny thing.

1 more reply

j / k navigate · click thread line to collapse