Functional Logic Program Transformations

Michael Hanus; Steven Libby

Home/Archive/arXiv

arXiv · 2601.13224

Functional Logic Program Transformations

Michael Hanus·Steven Libby

View original source ↗Read source document ↗Export metadata ↓

Abstract

Many tools used to process programs, like compilers, analyzers, or verifiers, perform transformations on their intermediate program representation, like abstract syntax trees. Implementing such program transformations is a non-trivial task, since it is necessary to iterate over the complete syntax tree and apply various transformations at nodes in a tree. In this paper we show how the features of functional logic programming are useful to implement program transformations in a compact and comprehensible manner. For this purpose, we propose to write program transformations as partially defined and non-deterministic operations. Since the implementation of non-determinism usually causes some overhead compared to deterministically defined operations, we compare our approach to a deterministic transformation method. We evaluate these alternatives for the functional logic language Curry and its intermediate representation FlatCurry which is used in various analysis and verification tools and compilers.

Explore related subjects

cs.PL

Keep this discovery

Explore connections, maps & timelines

BibTeX RIS

Michael Hanus, Steven Libby. 2026-01-19. Functional Logic Program Transformations. https://arxiv.org/abs/2601.13224

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

arXiv2026

LLVM Translation Validation Automated with Large Language Models and Lean

LLVM is the cornerstone of modern compilers, but its subtle intermediate representation (IR) semantics make transformations error-prone and necessitate formal verification. Alive2, a state-of-the-art translation validator based on satisfiability modulo theories, has achieved substantial success in automating the validation of LLVM transformations. However, it still faces scalability limitations, does not support symbolic bitwidths, and offers only bounded guarantees for loops. In contrast, interactive theorem provers such as Lean can address these cases but require substantial proof engineering. In this paper, we present Trivet, a framework combining large language models (LLMs) and Lean for automated translation validation of LLVM transformations. Trivet generates structured proof scaffolds based on source and target functions, automatically discharges obligations amenable to deterministic reasoning, and delegates transformationspecific obligations to LLMs. It produces refinement proofs or counterexample-based refutations, with every successful verdict checked by the Lean kernel. On 148 LLVM transformations, Trivet verifies or refutes 147, leaving one invalid case unresolved. Successful cases include 60 loop-free transformations with symbolic bitwidths, 27 cases from a restricted class of loop-containing transformations, and 10 complex valid fixed-bitwidth cases on which Alive2 times out. Compared with an unscaffolded baseline, scaffolding enables 26 additional proofs. On cases solved by both configurations, it reduces mean proof time by 75.9% and mean monetary cost by 88%.

cs.PL↗

arXiv2026

Theories of Mind as Domain-Specific Languages of Thought

What kind of thing is a ``theory of mind''? We propose to formalize theories of mind as domain-specialized programming languages, which can be used to reason about the mental states of other agents. Our proposal builds on the longstanding idea that thinking is akin to programming in an internal ``language of thought.'' But rather than positing a single general-purpose language for all of thought, we posit a collection of domain-specific languages of thought, whose respective syntaxes and semantices encode the theories of various domains. We make this idea concrete in the domain of intuitive psychology using a real-world programming language called memo, which is specialized for theory-of-mind reasoning via domain-specialized syntactic constructs like ``knows,'' ``wants,'' and ``thinks.'' In our view, using one's theory-of-mind to think about a social situation is analogous to using memo to write a program that models that situation. Through a series of worked examples, we show how formally representing a theory of mind as a memo-like programming language can lend insight into a variety of theoretical issues in theory-of-mind research: (1) how a single, fixed intuitive theory can be used to reason about social situations with unbounded structural variation; (2) how a modular, domain-specialized, and informationally-encapsulated system for social cognition might interface with external world knowledge, as well as other cognitive systems like intuitive physics; and (3) how different theories of mind, such as those of children and adults, differ, what exactly is gained as theories grow over the course of development, and how that growth might occur.

cs.PL↗

arXiv2026

The Output-Space Hypothesis: Enumerative Equivalence Checking for Tensor Programs

Tensor programs, as used in deep learning models, are a prime target for optimization, as small performance improvements can have a large impact across training or inference workloads. However, such optimizations are complicated and can produce subtle bugs. Traditionally, correctness is assumed when differential testing against a reference on random inputs fails to reveal bugs. However, the inputs to these programs are massive tensors, and finding bugs can require generating extremely low likelihood inputs with precise relationships among their values. We propose a novel way to find bugs more consistently by flipping the quantifiers. Rather than generating a single input and checking all output tensor locations for equivalence, what if you could check a single output tensor location's equivalence for all inputs? We implement this idea in a system, \dirigo, by using a novel symbolic execution strategy. We demonstrate that \dirigo can find bugs effectively in a public dataset of 6,988 AI-written CUDA kernels that are all marked correct by differential testing. Of these, \dirigo finds 600 kernels that are actually buggy, and finds 97.3\% of those bugs within two minutes.

cs.PL↗