Cplus2ASP: Causal Action Language to ASP Compiler

• Cplus2ASP is a compiler that transforms high-level causal descriptions in C+ and related action languages into answer set programs interpretative by modern ASP solvers.
• It employs a multi-stage translation pipeline that parses, normalizes, and compiles causal laws into time-indexed ASP rules with well-defined formal semantics.
• Its support for incremental execution with iclingo and extensible multi-modal translations offers significant performance gains and modeling flexibility in transition-system reasoning.

Cplus2ASP is a compiler and execution-engine that takes a high-level causal description written in an action language and turns it into an Answer Set Program (ASP), which is then solved by modern ASP engines such as clingo or its incremental variant iclingo. In Version 2, the system implements the definite fragment of action language C+, its input language is fully compatible with the language of the Causal Calculator Version 2, and the system supports extensible multi-modal translations for other action languages, such as B and BC, as well (Babb et al., 10 May 2026). In later work on Action Language BC+, computational methods available in ASP solvers are described as readily applicable to compute BC+, which led to an implementation of the language by extending system cplus2asp (Babb et al., 22 Jun 2025).

1. Origins, scope, and supported action languages

Cplus2ASP is presented as Version 2 of a system that implements the definite fragment of action language C+. Rather than reducing C+ to SAT, as the original Causal Calculator does, Cplus2ASP v2 composes several translations and uses ASP-based solving. Its input language is fully compatible with the language of the Causal Calculator Version 2, and the new system is described as significantly faster thanks to modern answer set solving techniques (Babb et al., 10 May 2026).

The system is not restricted to C+ alone. Version 2 supports extensible multi-modal translations for other action languages, such as B and BC, and its modular front end can be extended to other action languages. The data specifically names Language B (Gelfond & Lifschitz 1998) and Language BC (Lee, Lifschitz & Yang 2013), with BC characterized as merging features of B and C+ and admitting Prolog-style recursive definitions (Babb et al., 10 May 2026). In the BC+ work, the language BC+ is described as closing the gap between action languages and the modern ASP language, and the implementation is stated to arise by extending system cplus2asp (Babb et al., 22 Jun 2025).

This placement is significant because Cplus2ASP occupies an intermediate layer between high-level action description languages and solver-oriented ASP encodings. A plausible implication is that the system serves both as an execution platform for transition-system reasoning and as a vehicle for importing new semantic developments in action languages into modern ASP workflows.

2. Translation pipeline and system architecture

At a top level, Cplus2ASP v2 orchestrates four major components: a front-end translator (cplus2asp.bin) that reads a C+ (or B, BC) description in CCalc-style syntax and emits a “meta” ASP program whose rules contain nested expressions; the f2lp system, which compiles first-order formulas with nested connectives into a groundable form acceptable to the gringo grounder; clingo or its incremental counterpart iclingo, which performs grounding and answer-set solving; and as2transition, a post-processor that takes raw answer sets and reifies them as transition-system traces, plans, or other readable output (Babb et al., 10 May 2026).

The BC+ description of the extended translator gives a more fine-grained architecture. It identifies a front-end parser based on the CCalc-style concrete syntax, a semantic projector that collates constant-domain information and classifies causal laws, a time-unfolder that clones each law for each time point, an ASP encoder that turns time-stamped laws into ASP integrity constraints, normal rules, choice constructs, aggregates, and constraints, an output module that emits a single .lp file in Clingo-compatible syntax, a solver invocation stage, and a result interpreter that maps atoms like c(v)@i back to c=v in state i and prints sequences of 0…m states and actions (Babb et al., 22 Jun 2025).

These descriptions show a stable architectural pattern. High-level causal laws are first parsed into an internal representation, then normalized into time-indexed formulas, then compiled into ASP constructs that modern solvers can process directly. This suggests that Cplus2ASP is best understood not as a single translator pass but as a staged compilation pipeline whose intermediate forms are semantically motivated.

3. Formal semantics and the ASP correspondence

For definite C+, the formal semantics is given through a multi-valued propositional theory cplus2mvpf(D,m) interpreted under stable-model semantics. To find models over a horizon 0…m, time-indexed copies i : c of each fluent—or action when i<m—are introduced, sharing the same domain. Static laws, action-dynamic laws, and fluent-dynamic laws are translated into time-indexed rules, and for each simple fluent c and value v in Dom(c), the system asserts at time 0 the rule 0 : c=v not not (0 : c=v). Under the multi-valued SM semantics identified with Bartholomew & Lee 2012, an interpretation I is a stable model of this theory iff it describes a valid transition-system execution of D up to time m (Babb et al., 10 May 2026).

The next stage replaces each atom c=v by a Boolean atom c(v) and adds “existence and uniqueness constraints” (UEC): ⊥ ← c(v), c(v′) for all v≠v′, and ⊥ ← not \vee_{v\in Dom(c)} c(v). By Theorem 1, described as a corollary of Bartholomew & Lee’s results, the stable models of F under the multi-valued SM semantics correspond exactly—via I↦I^{prop}—to the propositional stable models of F^{prop} ∧ UEC (Babb et al., 10 May 2026).

The BC+ work generalizes the semantic basis further by defining the semantics of BC+ in terms of general stable model semantics for propositional formulas. A BC+ signature σ is a finite set of propositional atoms of the form c=v, where c ranges over regular fluent constants, statically determined fluent constants, and action constants; each constant has a finite domain Dom(c); static, action dynamic, and fluent dynamic laws are time-stamped into a propositional formula _m(D); and stable models are defined reductively in the sense of Ferraris 05 (Babb et al., 22 Jun 2025). The transition system T(D) then has states as nodes and labeled edges e for each transition.

Taken together, these formulations make Cplus2ASP a semantically explicit system rather than a purely operational compiler. Its compilation steps are justified by stable-model correspondences, and the move from multi-valued action descriptions to Boolean ASP is mediated by UEC rather than by an ad hoc encoding.

4. Incremental execution and correctness guarantees

To exploit iclingo’s incremental grounding, the translation for definite C+ is refactored into three parameterized components ⟨B,P[t],Q[t]⟩. The base component B describes time 0 static laws and initial-value constraints. The cumulative component P[t] for t≥1 describes UEC constraints at time t, static laws at t, action dynamics at t−1, and fluent dynamics for transition from t−1 to t. The volatile query Q[t] encodes the planning goal or propositional constraint at the final step (Babb et al., 10 May 2026).

Gebser et al. (2011) define acyclicity for such triples so that iclingo can ground and solve them incrementally, reusing the grounding of B and P[1…t−1] when going to step t and instantiating only the new rules P[t] and Q[t]. Babb & Lee (2012) extended the module theorem to cover programs with nested expressions, proving that if ⟨B,P[t],Q[t]⟩ is acyclic then its incremental fixpoint semantics coincides with the standard one; the incremental run by iclingo is therefore sound and complete with respect to the original C+ semantics (Babb et al., 10 May 2026).

In practice, step k corresponds to fixing a plan length or transition-system depth k. iclingo first grounds and solves B∪P[1]∪Q[1]; if no answer set meets the goal, it incrementally adds P[2] and re-grounds only new rules, while previous ground rules, learned nogoods, and heuristics are reused. The process continues until either a model is found at step k or k exceeds a user-supplied maximum (Babb et al., 10 May 2026).

This aspect is central to the identity of Cplus2ASP v2. The system does not merely call an ASP solver; it restructures the generated program so that incremental grounding and solving are semantically justified. A common misconception is to treat incremental execution as an implementation optimization detached from formal semantics. The module-theorem account shows that, in this setting, incrementalization is tied directly to a correctness theorem.

5. BC+ extension and compilation into modern ASP

Action Language BC+ is introduced as a language that closes the gap between action languages and the modern ASP language. The main idea is to define the semantics of BC+ in terms of general stable model semantics for propositional formulas, under which many modern ASP language constructs can be identified with shorthands for propositional formulas. BC+ is described as sufficiently expressive to encompass the best features of other action languages, such as languages B, C, C+, and BC, and its implementation is obtained by extending system cplus2asp (Babb et al., 22 Jun 2025).

Within this extension, the ASP encoder translates each time-stamped static law F→G into an ASP integrity constraint :- not G@i, F@i., each fluent-dynamic law i:F ∧ H@i → G@(i+1) into a normal rule G@(i+1) :- F@i, H@i., choice initialization of regular fluents into rules such as { c(v)@0 } :- Dom(c,v)., and UEC into cardinality-constraint aggregates such as :- 2 { c(v)@i : Dom(c,v) }; and :- 1 { c(v)@i : Dom(c,v) }. The translator can also emit #program step(t). blocks for incremental or online solving support via OClingo, and attribute declarations such as attribute(location*) of move are compiled into auxiliary Boolean or finite-domain fluents with additional linking laws (Babb et al., 22 Jun 2025).

The BC+ summary also identifies optimizations and extensions: aggregates for UEC and global constraints avoid quadratic grounding of pairwise inequalities; choice-rule syntax ({…}=1) uses Clingo’s native constructs for defaults and inertia; and grounding-minimization groups identical schema rules across time points, exploiting Clingo’s parameterized programs (Babb et al., 22 Jun 2025).

These points clarify the relation between Cplus2ASP and modern ASP practice. The translator is not limited to a minimal normal-rule fragment; rather, it uses choice rules, aggregates, and related constructs as first-class compilation targets. This suggests that the BC+ extension is as much about enlarging the representational envelope of the system as about adding a new front-end language.

6. Input language, interaction model, and illustrative workflow

Cplus2ASP’s parser fully supports CCalc2’s input syntax, including multi-valued, defined, additive, defeasible causal laws, macros, implicit sort-declarations, and external atoms via embedded Lua calls. External atoms are evaluated at grounding time in gringo via Lua code. The data gives the example move(B,L) causes loc(B)=L where @roll(1,2)., with a separate .lua file providing the corresponding roll(a,n) function. During grounding, each candidate instantiation invokes roll(1,2), dynamically filtering out transitions (Babb et al., 10 May 2026).

Users may invoke Cplus2ASP either as a single command-line tool or via an interactive shell. The interactive shell allows users to inspect available queries, adjust minstep and maxstep, choose static versus incremental modes, and inspect intermediate translations (Babb et al., 10 May 2026). In the BC+ workflow, the sequence is given explicitly: a user writes a BC+ description in the CCalc-style input; cplus2asp parses and checks domains, sorts, and declarations; the tool asks for a maxstep=m and optional query or state constraints; time-unfolding instantiates each causal law for the relevant time points; per-rule translation yields ASP rules, choice constructs, aggregates, and constraints; the system assembles a single .lp program, possibly in incremental modules; Clingo or OClingo is invoked to ground and solve; and answer sets are mapped back to BC+ states and transitions for presentation (Babb et al., 22 Jun 2025).

The “two-switch” running example in the BC+ summary makes this workflow concrete. The domain description introduces sorts switch and status, objects s1,s2::switch; up,down::status, constants swStat(switch)::inertialFluent(status) and flip(switch)::exogenousAction, and laws including flip(S) causes swStat(S)=X if swStat(S)=Y & X≠Y, caused swStat(S1)=X if swStat(S2)=Y & S1≠S2 & X≠Y, inertial swStat(S), and exogenous flip(S). For m=1, the translator produces time 0 choices and UEC constraints, dynamics for the 0→1 transition, inertia rules, and UEC at t=1; invocation in BC+-mode is shown as cplus2asp -l bc+ two_switches maxstep=1 find=all, which internally generates the .lp, calls clingo, and prints all answer sets, each corresponding to a transition ⟨s₀,e₀,s₁⟩ (Babb et al., 22 Jun 2025).

This operational presentation shows that Cplus2ASP is designed not only for batch compilation but also for exploratory model inspection, query-oriented execution, and transition-level output reconstruction.

7. Performance profile and research significance

In extensive experiments on domains such as Traffic World, Blocks World with costs, Spacecraft, Towers of Hanoi, and the Ferryman puzzle, Cplus2ASP v2’s incremental mode outperformed the original Cplus2ASP v1 by roughly an order of magnitude, the static mode of Cplus2ASP v2 by factors of 3–10, the coala compiler in both its static and incremental variants, and the SAT-based Causal Calculator v2 (CCalc+relsat) (Babb et al., 10 May 2026).

The data gives two concrete illustrations. In a “Ferryman 120/4” long-horizon test, the static modes suffered super-linear groundings per step, whereas iclingo’s incremental run remained near-constant per step, saving hundreds of seconds over 100 steps. On moderate-sized benchmarks such as Blocks World with 15 blocks, the incremental Cplus2ASP v2 solved in under 5 s where others needed tens or hundreds of seconds (Babb et al., 10 May 2026).

The research significance of Cplus2ASP lies in the combination of a CCalc-compatible high-level input language, a formally well-founded translation pipeline, support for nested-expression compilation through f2lp, correctness results for incremental execution via the module theorem for nested expressions, and an extensible architecture that also serves as a substrate for BC+ (Babb et al., 10 May 2026). The later BC+ work strengthens this significance by situating the system in a setting where action descriptions with defaults, aggregates, multi-valued fluents, action attributes, and constraints are encoded into the full power of modern ASP and handled automatically by cplus2asp (Babb et al., 22 Jun 2025).

A plausible implication is that Cplus2ASP occupies a distinctive role among action-language tools: it is simultaneously a semantic bridge from causal formalisms to stable-model computation and an implementation framework through which advances in ASP language design can be imported into action reasoning.