act: Technical report

Alexis Terry; Anja Petkovi\'c Komel; Lefteris Lazaropoulos; Sophie Rain; Zoe Paraskevopoulou

arxiv: 2604.02955 · v1 · submitted 2026-04-03 · 💻 cs.PL · cs.LO

act: Technical report

Zoe Paraskevopoulou , Anja Petkovi\'c Komel , Sophie Rain , Lefteris Lazaropoulos , Alexis Terry This is my paper

Pith reviewed 2026-05-13 18:29 UTC · model grok-4.3

classification 💻 cs.PL cs.LO

keywords type safetyoperational semanticspointer semanticsACT languagemetatheorytype systemspecification languageverification language

0 comments

The pith

The ACT language is type-safe, meaning well-typed programs do not get stuck in its operational pointer semantics.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This technical report defines the syntax, operational pointer semantics, and type system for the ACT specification and verification language. It establishes type safety as the key metatheoretic result, showing that well-typed programs execute without becoming stuck. A reader would care because this provides a reliable foundation for building specification and verification tools that avoid certain runtime errors in their memory model. The proof relies on progress and preservation properties linking the type rules to the semantics.

Core claim

The ACT language is type-safe: well-typed programs do not get stuck according to the operational pointer semantics. The report documents the formal syntax, the pointer-based operational semantics, the type system rules, and proves the main results of type safety through metatheory.

What carries the argument

The type safety theorem, which connects the type system to the operational pointer semantics to ensure no stuck states.

Load-bearing premise

The operational semantics and type rules are correctly stated and the metatheoretic proof covers all cases without hidden assumptions about memory or aliasing.

What would settle it

Finding a well-typed ACT program that, when executed step by step according to the operational semantics, reaches a stuck state where no further reduction is possible.

read the original abstract

This technical report contains the formal definitions and metatheory for the act specification and verification language. It documents the syntax, the operational pointer semantics, the type system and the main metatheoretic results (type-safety).

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

This technical report formalizes the ACT language with standard type safety for pointer semantics, providing a solid but incremental reference.

read the letter

The main takeaway is that this technical report presents the formal definitions for the ACT language, including its syntax, the operational semantics defined over pointers, the type system, and the proof of type safety. The key result is that well-typed programs do not get stuck under the given semantics. What the paper does well is to supply a complete, self-contained formalization. Having all the pieces—syntax, semantics, types, and metatheory—in one document is helpful for reference purposes. It allows readers to see exactly how the pointer semantics are modeled and how the type rules ensure safety. This kind of detailed documentation is valuable in the programming languages field where precise definitions matter. The soft spots are relatively minor given the nature of the work. The type-safety claim follows the classic pattern of proving progress and preservation, which is standard for languages with mutable state and pointers. The abstract indicates that the full details are in the report, and no obvious holes like unhandled aliasing cases or circular reasoning appear in the summary. However, without the actual proof text in front of us, it's not possible to confirm every case is covered, though the provided material suggests it's handled properly. This kind of paper is for specialists in formal semantics and language design. A reader who needs a concrete example of formalizing a verification language or who is working on similar pointer-based systems will find it useful as a starting point or comparison. I would recommend putting it through peer review. The work is formally grounded enough that referees can provide useful feedback on the proof structure and any potential improvements to the presentation.

Referee Report

0 major / 2 minor

Summary. This technical report documents the syntax, operational pointer semantics, type system, and metatheoretic results for the ACT specification and verification language. The central claim is that the language is type-safe: well-typed programs do not get stuck according to the defined operational semantics (progress and preservation).

Significance. If the type-safety result holds, the work supplies a standard but essential metatheoretic foundation for a verification language whose semantics are defined over pointers. Explicit documentation of syntax, semantics, and type rules enables independent scrutiny and supports reliable use in specification tasks.

minor comments (2)

The abstract could explicitly indicate whether the metatheoretic proofs are machine-checked or pen-and-paper, as this affects reproducibility and verification effort.
Notation for pointer operations and memory aliasing in the operational semantics should be cross-referenced to the type rules to aid readability.

Simulated Author's Rebuttal

0 responses · 0 unresolved

We thank the referee for their positive review and recommendation to accept the technical report. The summary accurately captures the document's scope: formal syntax, pointer-based operational semantics, type system, and the type-safety metatheory (progress and preservation) for the ACT language.

Circularity Check

0 steps flagged

No significant circularity in the metatheoretic derivation

full rationale

The paper supplies explicit syntax, pointer-based operational semantics, type rules, and a standard progress+preservation proof for type safety. These are self-contained formal definitions and case analysis with no fitted parameters, no predictions that reduce to inputs by construction, and no load-bearing self-citations or imported uniqueness theorems. The central claim is a conventional metatheoretic result whose validity rests on the stated rules rather than any circular reduction.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The central claim rests on the standard mathematical background of operational semantics and type theory; no free parameters, invented entities, or ad-hoc axioms are visible from the abstract.

pith-pipeline@v0.9.0 · 5323 in / 944 out tokens · 22015 ms · 2026-05-13T18:29:05.455258+00:00 · methodology

discussion (0)

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

IndisputableMonolith/Foundation/RealityFromDistinction.lean reality_from_one_distinction unclear

?

unclear
Relation between the paper passage and the cited Recognition theorem.

The main metatheoretic results (type-safety). ... Lemma 10.3 (Expression Type Safety (Untimed)) ... Lemma 10.10 (Type Safety).
IndisputableMonolith/Foundation/AlexanderDuality.lean alexander_duality_circle_linking unclear

?

unclear
Relation between the paper passage and the cited Recognition theorem.

Pointer Semantics ... E-Storage, E-Field, E-RefMapping ... Determinism lemmas (8.2-8.11)

What do these tags mean?

matches: The paper's claim is directly supported by a theorem in the formal canon.
supports: The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends: The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses: The paper appears to rely on the theorem as machinery.
contradicts: The paper's claim conflicts with a theorem or certificate in the canon.
unclear: Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

1 extracted references · 1 canonical work pages

[1]

[1] Lawrence C. Paulson. 1986. Constructing recursion operators in intuitionistic type theory.J. Symb. Comput.2, 4 (Dec. 1986), 325–355. doi:10.1016/S0747-7171(86)80002-5 46 Zoe Paraskevopoulou, Anja Petković Komel, Sophie Rain, Lefteris Lazaropoulos, and Alexis Terry List of Theorems 6.1 Definition (Well-typedΣ) 15 6.2 Lemma (ExtendingΣPreserves Well-Typ...

work page doi:10.1016/s0747-7171(86)80002-5 1986

[1] [1]

[1] Lawrence C. Paulson. 1986. Constructing recursion operators in intuitionistic type theory.J. Symb. Comput.2, 4 (Dec. 1986), 325–355. doi:10.1016/S0747-7171(86)80002-5 46 Zoe Paraskevopoulou, Anja Petković Komel, Sophie Rain, Lefteris Lazaropoulos, and Alexis Terry List of Theorems 6.1 Definition (Well-typedΣ) 15 6.2 Lemma (ExtendingΣPreserves Well-Typ...

work page doi:10.1016/s0747-7171(86)80002-5 1986