Table of Contents
Fetching ...

Inversion by Partial Evaluation: A Reversible Interpreter Experiment

Robert Glück, Louis Marott Normann

TL;DR

This paper investigates inversion by partial evaluation in reversible computing, using an RTM-interpreter implemented in a reversible flowchart language (ARL) and an offline partial evaluator (PEARL). By comparing the two projection paths—specializing the interpreter with respect to an RTM and specializing the RTM (or its inverse) with respect to the interpreter—the authors demonstrate that the resulting residual programs can be textually equivalent for at least the inc RTM. The study provides insights into how interpreters, inverters, and partial evaluators interact and identifies conditions under which textual equivalence of residuals holds, arguing that both Futamura and inversion projections belong in the program-transformation toolbox. These results have implications for reversible and energy-efficient computing, suggesting practical avenues for composing transformations that preserve both semantics and syntax. The work also discusses limitations when extending to irreversible languages and outlines future work to generalize the findings across broader classes of reversible systems.

Abstract

A computational limit of combining partial evaluation and program inversion is investigated. Using a reversible Turing machine interpreter, we show that the first Futamura and inversion projections can produce not only functionally but also textually equivalent programs. The construction of the interpreter in a reversible flowchart language is shown in full. Insights are provided on the practical interplay between reversible interpreters, program inverters, and partial evaluators. We conclude that both projections must be included in the program transformation toolbox.

Inversion by Partial Evaluation: A Reversible Interpreter Experiment

TL;DR

This paper investigates inversion by partial evaluation in reversible computing, using an RTM-interpreter implemented in a reversible flowchart language (ARL) and an offline partial evaluator (PEARL). By comparing the two projection paths—specializing the interpreter with respect to an RTM and specializing the RTM (or its inverse) with respect to the interpreter—the authors demonstrate that the resulting residual programs can be textually equivalent for at least the inc RTM. The study provides insights into how interpreters, inverters, and partial evaluators interact and identifies conditions under which textual equivalence of residuals holds, arguing that both Futamura and inversion projections belong in the program-transformation toolbox. These results have implications for reversible and energy-efficient computing, suggesting practical avenues for composing transformations that preserve both semantics and syntax. The work also discusses limitations when extending to irreversible languages and outlines future work to generalize the findings across broader classes of reversible systems.

Abstract

A computational limit of combining partial evaluation and program inversion is investigated. Using a reversible Turing machine interpreter, we show that the first Futamura and inversion projections can produce not only functionally but also textually equivalent programs. The construction of the interpreter in a reversible flowchart language is shown in full. Insights are provided on the practical interplay between reversible interpreters, program inverters, and partial evaluators. We conclude that both projections must be included in the program transformation toolbox.

Paper Structure

This paper contains 13 sections, 3 equations, 7 figures.

Figures (7)

  • Figure 1: Experimental setup: the first Futamura projection vs. the first inversion projection
  • Figure 2: Transition diagrams of the RTMs for (a) binary increment inc and (b) binary decrement inc$^{-1}$
  • Figure 3: inc and inc$^{-1}$: RTM-program representation and example tapes for the RTM-interpreter (Fig. \ref{['fig:rtmcode']})
  • Figure 4: Control-flow diagram of the RTM-interpreter
  • Figure 5: RTM-interpreter written in ARL. Static operations (in blue) depend only on the static machine description (Start, Final, Rules); all other operations (in black) are residualized by the specializer.
  • ...and 2 more figures