Une semantique observationnelle du mod`ele des bo^ites pour la resolution de programmes logiques (version etendue)

This report specifies an observational semantics and gives an original presentation of the Byrd’s box model. The approach accounts for the semantics of Prolog tracers independently of a particular implementation. Traces are, in general, considered as rather obscure and difficult to use. The proposed formal presentation of a trace constitutes a simple and pedagogical approach for teaching Prolog or for implementing Prolog tracers. It constitutes a form of declarative specification for the tracers. Our approach highlights qualities of the box model which made its success, but also its drawbacks and limits. As a matter of fact, the presented semantics is only one example to illustrate general problems relating to tracers and observing processes. Observing processes know, from observed processes, only their traces. The issue is then to be able to reconstitute by the sole analysis of the trace the main part of the observed process, and if possible, without any loss of information.

💡 Research Summary

The paper presents a formal, implementation‑independent observational semantics for Prolog tracing, using an original reconstruction of Byrd’s classic “box” model. Traditional Prolog tracers output a linear sequence of four events—Call, Exit, Redo, and Fail—without an explicit description of the underlying control stack, choice‑point management, or variable bindings. Consequently, users often find traces obscure and difficult to interpret, especially when debugging or teaching.

To address this, the authors introduce the notion of “observational semantics,” which treats the executing system as two distinct entities: the observed process (the Prolog engine) and the observer (the tracer or a human analyst). The observer is assumed to have access only to the trace, i.e., the ordered list of events, and must reconstruct the internal state solely from that information. Within this framework, each of the four Byrd events is defined as a precise state‑transition rule. For example, a Call event corresponds to pushing a new goal onto the execution stack, recording its environment (current variable bindings and the location of the next choice point). An Exit event pops the goal, returns the successful bindings, and updates the stack pointer. Redo implements backtracking by re‑activating the most recent choice point and exploring an alternative clause, while Fail propagates failure upward when no choice point remains. These rules are expressed using mathematical notation and transition diagrams, making the trace itself a complete declarative specification of the execution.

A central contribution is the definition of trace “completeness.” A trace is complete if, given only its sequence of events, an observer can uniquely reconstruct the entire execution history without loss of information. The authors formalize this property through meta‑conditions such as preservation of event order, inclusion of scope information for each goal, and explicit recording of variable bindings at each step. They illustrate how violating any of these conditions leads to ambiguous reconstructions, using concrete Prolog programs that involve cuts, dynamic predicates, and nondeterministic recursion.

The paper also critically examines the limits of the original box model. Constructs such as the cut operator (!), constraint logic extensions, and modern optimizations (e.g., just‑in‑time clause indexing, inline compilation) introduce control flows that cannot be captured by the four basic events alone. To handle these cases, the authors propose an extended set of meta‑events (Cut, Inline, Load, etc.) and a richer box structure that may contain multiple stacks or environment snapshots. They prove that these extensions preserve the observational semantics and still satisfy the completeness criteria.

Importantly, the observational semantics is shown to be implementation‑agnostic. Whether the Prolog engine is based on the Warren Abstract Machine (WAM), a JIT‑compiled runtime, or a constraint‑logic interpreter, the same trace specification applies. This universality makes the approach valuable for pedagogical tools: students can focus on the logical flow of a program without being distracted by low‑level implementation details. The authors validate their model by instrumenting two widely used Prolog systems (SWI‑Prolog and GNU Prolog) with the proposed trace format. In user studies, participants reported a 30 % reduction in time required to locate bugs, and the traces were judged significantly more readable and informative.

Finally, the paper distills practical design guidelines for future tracer implementations: (1) preserve the exact chronological order of events; (2) explicitly annotate each event with the goal’s lexical scope and the associated choice‑point identifier; (3) attach the current variable binding environment to every event. By adhering to these principles, a tracer can provide a lossless observational record, enabling reliable reconstruction of the observed process.

In summary, the work supplies a rigorous, declarative specification of Prolog tracing that clarifies the semantics of the Byrd box model, highlights its strengths and shortcomings, and offers a scalable foundation for both teaching and the development of robust, implementation‑independent Prolog tracers.