Views, Program Transformations, and the Evolutivity Problem in a Functional Language

We report on an experience to support multiple views of programs to solve the tyranny of the dominant decomposition in a functional setting. We consider two possible architectures in Haskell for the classical example of the expression problem. We show how the Haskell Refactorer can be used to transform one view into the other, and the other way back. That transformation is automated and we discuss how the Haskell Refactorer has been adapted to be able to support this automated transformation. Finally, we compare our implementation of views with some of the literature.

💡 Research Summary

The paper tackles a long‑standing software‑design dilemma known as the “tyranny of the dominant decomposition” within the context of a purely functional language, Haskell. The dominant decomposition problem arises when a program is organized around a single axis—typically either data types or operations—so that extending the program along the orthogonal axis becomes cumbersome. In object‑oriented languages this issue has been addressed through patterns such as Visitor, multiple dispatch, or mix‑ins, but functional languages have lacked a systematic counterpart.

To overcome this, the authors introduce the notion of views: multiple, mutually consistent structural representations of the same program. In their setting two complementary views are defined: a data‑centric view, where algebraic data types (ADTs) are primary and operations are expressed as separate pattern‑matching functions; and an operation‑centric view, where a type‑class hierarchy captures the operations and the ADTs appear as parameters to those type classes. Both views must preserve the same semantics, and any modification in one view should be automatically reflected in the other.

The core technical contribution is an automated transformation pipeline built on top of the Haskell Refactorer (HR). While HR already supports a range of refactorings, it does not natively handle the systematic restructuring required to switch between views. The authors therefore extend HR with a set of view‑mapping rules that describe a bijective correspondence between constructs in the data‑centric and operation‑centric representations. These rules drive an AST‑level transformation that (1) restructures type declarations, (2) rewrites function definitions into type‑class instances (or vice‑versa), (3) resolves naming conflicts, and (4) updates module imports to maintain a compilable program. The transformation is pure and deterministic; after conversion the program passes the same test suite, guaranteeing semantic equivalence.

The experimental vehicle is the classic “Expression Problem” example. The base ADT Expr includes literals, variables, addition, and multiplication. In the data‑centric view each operation—evaluation, pretty‑printing, type‑checking—is implemented as a separate recursive function over Expr. In the operation‑centric view a type class Eval, ShowExpr, Check etc. is defined, and each constructor of Expr yields an instance of those classes. The authors demonstrate two typical extension scenarios: (a) adding a new operation (e.g., symbolic differentiation) and (b) adding a new data constructor (e.g., logarithm). In both cases the programmer edits only the view that is most natural for the extension; the automated transformation instantly produces the corresponding code in the other view, eliminating manual duplication and reducing the risk of inconsistencies.

A comparative analysis positions this work against related approaches. Visitor‑based solutions in C++ require modifications to the visitor interface whenever a new data type is introduced, leading to invasive changes. Scala’s mix‑in and implicit‑class techniques allow more flexible extension but suffer from complex type inference and potential binary compatibility issues. Recent “programming view” research proposes IDE‑driven visual transformations, yet those systems are often language‑specific and lack full automation. By contrast, the Haskell‑centric solution preserves the language’s pure functional semantics, leverages an existing refactoring infrastructure, and achieves a fully automated, declarative transformation pipeline.

The authors acknowledge limitations. Defining the view‑mapping rules can be non‑trivial for large codebases, and the transformation incurs measurable time and memory overhead on very large projects. Moreover, the current implementation is tightly coupled to the specific version of the Haskell Refactorer, so porting to other functional languages or newer Haskell toolchains would require additional engineering effort.

In conclusion, the paper provides a concrete demonstration that multiple, interchangeable structural views are feasible in a functional setting and that automated refactoring tools can keep those views synchronized. This contributes a novel paradigm for managing evolvability and maintainability in functional software, opening avenues for future work on scaling the transformation, generating view‑mapping specifications automatically, and extending the approach to other functional languages such as OCaml or F#.