Typed GLP: Typed Grassroots Logic Programming

• Typed GLP is a concurrent logic programming paradigm that integrates a regular, path-based type system to enforce precise communication protocols.
• It enforces single-reader single-writer and single-occurrence restrictions, ensuring that every variable appears only once in a clause for well-defined data flow.
• The semantic characterization via covariance and contravariance guarantees that well-typed programs produce only valid outputs and handle all permitted inputs.

Typed GLP (Grassroots Logic Programming) is a concurrent logic programming paradigm that extends an untyped GLP core with a regular path–based type system capable of expressing and enforcing sophisticated communication protocols. Typed GLP introduces a syntactic and semantic discipline that guarantees interactive correctness for partial, potentially non-terminating computations, supporting programs that communicate via logic variables partitioned into "writers" and paired "readers" under a single-reader single-writer (SRSW) and single-occurrence (SO) restriction. The formal system captures communication directionality (modes) and contains a semantic correspondence theorem equating well-typedness to a covariance/contravariance property on regular sets of moded paths, ensuring strong soundness guarantees for dynamically evolving logic processes (Shapiro, 25 Jan 2026).

1. Core Principles of GLP and Typing

GLP augments classical logic programming with explicit modeling of communication via logic variables, partitioned as writers (X) and paired readers (X?). Each variable, either writer or reader, occurs at most once in any term, goal, or clause (SO invariant). Additionally, the SRSW restriction mandates that every writer/reader pair appears together or not at all in any clause. This regime enables direct one-way binding—writers assign, readers consume—a structure that allows replacing unification with directed, single-use term-matching.

Typed GLP extends this with a type discipline. Types are defined as regular sets of moded paths, where each path specifies a sequence of function symbols and indices through a term tree, annotated with a communication mode: input (↓, “consume”) or output (↑, “produce”). This path-based view generalizes the classical treatment of types as regular sets of (unmoded) paths (Shapiro, 25 Jan 2026).

2. Modes, Moded Paths, and Path Automata

Typed GLP introduces modes to distinguish communication direction at each position of a term: every node in a term tree is labeled with a mode (↑ or ↓), recording the context as producing to or consuming from the environment. A moded path is a sequence of triples (i, m, f/n), describing at each step the argument index, mode, and function arity.

Types are specified as regular languages over these moded paths, constructed via a BNF grammar equipped with a duality operator (?): flipping all modes in its definition. The semantic content of a type is given as the set of moded paths accepted by its deterministic automaton. Fundamental type constructors include

• _ (any ↑-term)
• _? (any ↓-term)
• c (constant, inheriting mode)
• f(T₁,…,Tₙ) (producing with functor f)
• f?(T₁?,…,Tₙ?) (consuming duals)
• D? (duality)
• D;D (union)

This formalism enables uniform typing of interactive behaviors, including partial or deadlocked computations, by specifying the regular structure of permitted (mode-annotated) traversals through data using automata (Shapiro, 25 Jan 2026).

3. Syntactic Typing Judgments and Program Structure

A Typed GLP program consists of:

• A collection of SRSW clauses, each grouped into procedures p/n.
• A set of type declarations assigning a type vector to every procedure.
• Typed goals and bodies, syntactically decorated with modes.

The typing context Γ records type signatures for all procedures. The head of each clause is moded according to its declared type vector: output positions receive ↑, input positions (denoted as T_i? or via duality) receive ↓. Variable names are complemented (X ↦ X?) to maintain writer/reader distinction.

A clause is well-typed if:

1. Every path in the moded head is consistent with the declared type paths.
2. Every body goal produces a moded term whose paths are contained in the declared type for the target predicate.
3. For every writer/reader pair in the clause, their types are dual if both in head or body, equal if split between head and body.

A program is well-typed if all clauses are well-typed and input coverage holds: for every input path specified by a procedure type, some clause's moded head covers it. This ensures that all permitted forms of input are handled by the program, enforcing both output-conformance and input-coverage (Shapiro, 25 Jan 2026).

4. Semantics: Moded-Atoms and Path Abstraction

Execution semantics are given in terms of a transition system where configurations consist of a multiset of unit goals and a readers’ substitution. Reductions perform term-directed resolution using writer-only unification, while communication steps replace X? with the bound value of X when available.

For a run ending in a stable configuration, the outcome is the set of fully instantiated moded terms corresponding to the initial goals, with substitutions applied. The semantics of a program are the set of such outcomes across all well-typed initial goals, considered as sets of moded paths.

Projection functions output_paths(S) and input_paths(S) extract, respectively, the sets of output and input moded paths, facilitating the formal characterization of semantic correctness through regular languages (Shapiro, 25 Jan 2026).

5. Semantic Characterization: Covariance and Contravariance

Typed GLP’s central result establishes an equivalence between syntactic well-typedness and a semantic property on the path abstraction of program behaviors:

• Covariance: For every output path produced in any semantic outcome, there exists a corresponding path in the declared type.
• Contravariance: For every input path allowed by a type, there exists some semantic run that realizes a matching input path.

This theorem guarantees that programs do not produce outputs outside their type and are input-complete with respect to their declared types. A corollary shows this extends to a subtyping discipline, allowing dual body–body variable pairs to have a subtyping relationship rather than strict equality.

Additionally, type preservation holds: if the initial goal is well-typed, all intermediate results and final outcomes remain well-typed (Shapiro, 25 Jan 2026).

6. Illustrative Examples

Stream Merge

Given the type definition Stream ::= [] ; [_|Stream] and procedure declaration procedure merge(Stream?,Stream?,Stream), the first clause head merge([X|Xs],Ys,[X?|Zs?]) yields a moded head structure ensuring that the paths of the produced term lie in the type’s regular language. All possible input paths on the two input streams are covered by the program clauses.

Counter Monitor

With type CounterCall ::= add ; clear ; read(Integer?) and procedure procedure monitor(Stream(CounterCall)?.), the monitor processes interactive requests via input streams. Typing verifies that every request pattern (add, clear, read(n?)) is accepted, and all produced responses align with the specified type automaton (Shapiro, 25 Jan 2026).

7. Spec-Driven AI Programming and Application

Typed GLP serves as an effective contract for AI-powered code generation. In the reported Dart implementation, an LLM translated the paper’s mathematical specification into English, then English to code, with iterative corrections to satisfy the type system. The discipline of explicitly specifying types, procedure signatures, and English descriptions before code generation improves the reliability and correctness of programs written via AI assistance, enforcing the covariance and contravariance invariants at the level of both code and specification.

The broader methodological insight is that type-system specifications in Typed GLP guide both human and AI developers, preventing divergence and hallucination by grounding programming in mathematically verified contracts (Shapiro, 25 Jan 2026).

---

For foundational context, see also "Logic Programs as Types for Logic Programs" (LICS 1991) and follow-up work by Shapiro (Shapiro, 25 Jan 2026).