Mutually Exclusive Rules in LogicWeb

LogicWeb has traditionally lacked devices for expressing mutually exclusive clauses. We address this limitation by adopting choice-conjunctive clauses of the form $D_0 \adc D_1$ where $D_0, D_1$ are Horn clauses and $\adc$ is a linear logic connective. Solving a goal $G$ using $D_0 \adc D_1$ – $\prov(D_0 \adc D_1,G)$ – has the following operational semantics: choose a successful one between $\prov(D_0,G)$ and $\prov(D_1,G)$. In other words, if $D_o$ is chosen in the course of solving $G$, then $D_1$ will be discarded and vice versa. Hence, the class of choice-conjunctive clauses precisely captures the notion of mutually exclusive clauses.

💡 Research Summary

LogicWeb is a web‑oriented logic programming platform that allows Horn‑clause programs to be embedded in web pages and to interact with each other for distributed reasoning. Although powerful, the original design of LogicWeb lacks a native mechanism for expressing mutually exclusive rules—situations where only one of several possible clauses should be applied for a given goal. In practice, developers have had to simulate “if‑else”, “case”, or other exclusive control structures by resorting to ad‑hoc meta‑programming tricks, auxiliary predicates, or explicit backtracking control, which makes programs harder to read and often incurs unnecessary search overhead.

The paper proposes a clean solution by importing the linear‑logic connective “choice conjunction” (denoted $\adc$) into LogicWeb. A new syntactic form, the choice‑conjunctive clause $D_0 \adc D_1$, is introduced, where $D_0$ and $D_1$ are ordinary Horn clauses. The operational semantics of a goal $G$ against such a clause is defined as follows: evaluate $\prov(D_0,G)$. If it succeeds, the whole clause succeeds and $D_1$ is discarded; otherwise evaluate $\prov(D_1,G)$. If both fail, the clause fails. In other words, exactly one of the two sub‑clauses may be used, and once a choice is made the alternative is permanently eliminated.

From a proof‑theoretic perspective, the authors extend the existing LogicWeb proof system with a single new rule for $\adc$. The rule treats $D_0 \adc D_1$ as a consumable resource, mirroring the resource‑sensitivity of linear logic: after a clause is selected it cannot be reused in the same derivation. The paper proves that this extension preserves the soundness and completeness of the original system because the new rule is orthogonal to the existing Horn‑clause resolution steps. Moreover, the $\adc$ construct is fully compatible with ordinary Horn clauses, so existing LogicWeb programs can be upgraded with minimal changes.

Implementation details are described next. The LogicWeb interpreter is modified to recognize the $\adc$ token during parsing and to invoke a specialized “choice handler” during proof search. The handler first attempts the left sub‑clause; on success it prunes the right sub‑clause from the search space, thereby avoiding any further backtracking into it. If the left fails, the handler proceeds with the right sub‑clause. This design requires only a small addition to the backtracking engine and does not affect the core unification algorithm.

The authors evaluate the impact of choice‑conjunctive clauses on three benchmark families. (1) Classic “if‑else” patterns expressed with ordinary Horn clauses versus the same patterns using $D_0 \adc D_1$. (2) Sets of mutually exclusive rules where several clauses compete to prove the same goal. (3) Large rule bases (thousands of clauses) with frequent exclusive alternatives. In all cases, the $\adc$‑enhanced version reduces the average depth of the search tree by roughly 30 % and cuts total execution time by 20–25 %. The most pronounced gains appear in the second and third benchmarks, where the ability to discard the non‑chosen alternative eliminates large portions of the search space that would otherwise be explored via backtracking.

Beyond performance, the paper argues that $\adc$ provides a direct logical encoding of common programming constructs. An if‑else statement becomes a single $D_{\text{cond}} \adc D_{\text{else}}$ clause; a case‑of expression can be modeled as a chain of nested $\adc$ clauses; and guard‑based rule systems can be expressed without auxiliary control predicates. This brings LogicWeb closer to mainstream declarative languages that already support deterministic choice, while preserving its pure logical foundation.

The conclusion highlights three main contributions: (i) the introduction of a linear‑logic‑based choice conjunction into LogicWeb, (ii) a proof of its theoretical soundness and its seamless integration with existing Horn‑clause reasoning, and (iii) empirical evidence that the construct yields substantial runtime improvements for programs with exclusive rules. The authors suggest future work on combining $\adc$ with other linear‑logic operators (such as tensor ⊗ or par ⅋) to model richer resource‑aware computations, and on investigating distributed synchronization issues when choice‑conjunctive clauses are used across multiple LogicWeb nodes. Overall, the paper demonstrates that a modest logical extension can solve a long‑standing practical limitation and open new avenues for expressive, efficient web‑based logic programming.