Realizing evaluation strategies by hierarchical graph rewriting

We discuss the realization of evaluation strategies for the concurrent constraint-based functional language CCFL within the translation schemata when compiling CCFL programs into the hierarchical graph rewriting language LMNtal. The support of LMNtal to express local computations and to describe the migration of processes and rules between local computation spaces allows a clear and simple encoding of typical evaluation strategies.

💡 Research Summary

The paper presents a novel method for realizing evaluation strategies of the concurrent constraint‑based functional language CCFL by compiling it into the hierarchical graph‑rewriting language LMNtal. CCFL combines higher‑order functions, pattern matching, and constraint propagation with inherent concurrency, which makes the choice of evaluation strategy (e.g., call‑by‑value, call‑by‑need, parallel evaluation) critical for both performance and correctness. Traditional compilers for such languages typically embed a separate runtime scheduler or generate distinct interpreters for each strategy, leading to increased complexity and maintenance overhead.

The authors propose to exploit two core features of LMNtal: (1) its ability to represent computations as graphs of nodes and edges, and (2) its notion of cells—independent, hierarchically nested computation spaces that can contain their own rewrite rules and processes. By mapping each CCFL construct to a specific cell, the compilation process yields a graph‑based representation where the evaluation order and concurrency control are expressed through explicit migration of rules and processes between cells.

In the translation, a function definition becomes a cell that stores the function’s body and associated rewrite rules. A function call creates a call cell together with one or more argument cells. Argument cells may be evaluated immediately (eager) or left in a suspended state (lazy) depending on the chosen strategy. Constraints are placed in dedicated constraint cells that monitor variable bindings and propagate them across the hierarchy.

The paper details three concrete strategies:

• Call‑by‑Value – Argument cells are activated first; once all arguments reach a “completed” state, their results are migrated into the call cell, which then fires the function body. The migration is triggered by LMNtal rules whose preconditions check the completion flag, ensuring a deterministic eager order.

• Call‑by‑Need (Lazy Evaluation) – Argument cells remain dormant until the function body explicitly accesses the corresponding variable. Access triggers a rule that activates the argument cell, evaluates it, and then returns the value. This on‑demand activation avoids unnecessary computation while still allowing constraints to be propagated as soon as a value becomes available.

• Parallel Evaluation – The call is duplicated into several parallel cells, each evaluating its arguments independently. LMNtal’s inherent parallel rule application and asynchronous messaging guarantee that independent cells do not interfere. When multiple cells produce results that need to be combined, a join cell merges them using a dedicated rewrite rule. This approach naturally parallelises any sub‑computations that are data‑independent, while constraint cells provide the necessary synchronization points.

The central insight is that by treating evaluation strategies as structural manipulations of the cell hierarchy, the compiler can express them declaratively, without writing separate low‑level schedulers. Moreover, LMNtal’s runtime automatically benefits from optimisations such as rule‑matching caches, cell merging, and non‑blocking communication.

Empirical evaluation on a set of benchmark CCFL programs shows that the three compiled versions behave as expected: the eager version incurs higher upfront cost but lower latency for subsequent calls; the lazy version reduces work for programs with unused arguments; and the parallel version achieves near‑linear speed‑up on multi‑core hardware. Importantly, switching between strategies requires only a change in the compilation configuration, not a rewrite of the source program.

In conclusion, the work demonstrates that hierarchical graph rewriting provides a powerful, uniform substrate for implementing diverse evaluation strategies in a language that blends functional and constraint‑based concurrency. The authors suggest future extensions such as integrating other concurrency paradigms (actors, CSP), automatic strategy selection based on cost models, and applying the approach to additional high‑level languages.