abstract
| - The functional programming paradigm presents its own unique challenges to refactoring. For the OCaml language in particular, the expressiveness of its module system makes this a highly non-trivial task and there is currently no automated support for large-scale refactoring in the OCaml language.
We present Rotor, a tool for automatically renaming top-level value definitions in OCaml's module system. To compute the effect of renaming, Rotor relies on a novel concept which we call a value extension. This is a collection of related declarations in a program that must all be renamed at once. In practice, this leads to a notion of dependency: renaming a function foo in module A (mutually) depends on renaming function foo in module B etc.
We describe important aspects of Rotor's design, implementation, and evaluation on two large codebases: Jane Street's core library and its dependencies, and the OCaml compiler itself. In these real-world settings we find that some cases involve a surprisingly complex network of dependencies, and that the use of the PPX preprocessor system presents significant challenges.
- The functional programming paradigm presents its own unique challenges to refactoring. For the OCaml language in particular, the expressiveness of its module system makes this a highly non-trivial task and there is currently no automated support for large-scale refactoring in the OCaml language.
We present Rotor, a tool for automatically renaming top-level value definitions in OCaml's module system. To compute the effect of renaming, Rotor relies on a novel concept which we call a value extension. This is a collection of related declarations in a program that must all be renamed at once. In practice, this leads to a notion of dependency: renaming a function foo in module A (mutually) depends on renaming function foo in module B etc.
We describe important aspects of Rotor's design, implementation, and evaluation on two large codebases: Jane Street's core library and its dependencies, and the OCaml compiler itself. In these real-world settings we find that some cases involve a surprisingly complex network of dependencies, and that the use of the PPX preprocessor system presents significant challenges.
|