Lean 4 cubical-transport HoTT engine + Rust naga-IR FFI. The backend that powers topolei. Cells-spec implementation; the proof IS the implementation.
Find a file
Maximus Gorog 48b7326523
Some checks are pending
Lean Action CI / build (push) Waiting to run
Abstract the four ⚠️ tools into well-defined primitives
Per feedback "tooling possible, not tools — highly selective".
Each former opinionated wrapper either reduces to a Lean-standard
mechanism or splits into stated-contract primitives.

CubicalTransport/Question.lean:
- Drop the `cubical_simp` and `cubical_simp [..]` macros.  They
  baked in a fixed lemma list with a fixed expansion order.
- Drop the proposed `register_simp_attr question_simp` named-set
  too — strictly more curation than the foundation principle calls
  for.  Anyone wanting a named bundle can register one downstream.
- The genuinely-equational classifier-conditioned theorems remain
  `@[simp]`-tagged; existential-conclusion theorems
  (`ask_of_pi_line`, `ask_of_path_line`, HCompQ pi) lose their
  `@[simp]` tag (they don't rewrite goals — they produce
  witnesses).
- Examples now use Lean's standard `simp` against the `@[simp]`
  database — no special tactic involved.

CubicalTransport/Algebra/Methodology.lean:
- New foundation primitive `tryEntryAsClosed : MethodologyEntry →
  TacticM Bool` with stated contract: tries `exact` then `apply`,
  restores tactic state on failure, never throws, returns whether
  goal closed.  Order fixed to those two attempts in that sequence;
  alternative orders are user-side compositions of the primitive.
- `cubical_search` rewritten using `tryEntryAsClosed` +
  `findMethodologies` + `getMetaPaths` + `findMethodologies` (for
  source classifiers).  Docstring reframes it explicitly as a
  *reference-composition demonstrator* — exposes one obvious order
  for stages 1 (direct) and 2 (transport), with a "register your
  own dispatcher" pointer for users wanting different ordering /
  retry / failure shape.

CubicalTransport/Algebra/EngineMethodologies.lean:
- Drop the `cubical_close` macro entirely.  A `simp; (rfl |
  cubical_search)` composition is one line at the call site;
  baking it in imposed an opinionated default.

CubicalTransport/Algebra/Test.lean:
- Remove the three `cubical_close` examples (the macro is gone).
- Engine-bound methodologies remain (they exercise the @[methodology]
  registration mechanism).

AlgebraRestructure.lean:
- Docstring reframed as "thin labeled shell over `Algebra.print*`
  registry-printer functions, not a normative CLI."  The four
  subcommands are this demonstrator's choice; underlying printers
  accept any other shell equally.

93/93 tests pass.  No new functionality removed, just the opinion
layer between user code and the foundations.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-01 02:57:48 -06:00
.forgejo/workflows
CubicalTransport Abstract the four ⚠️ tools into well-defined primitives 2026-05-01 02:57:48 -06:00
docs
native/cubical
.gitignore
AlgebraRestructure.lean Abstract the four ⚠️ tools into well-defined primitives 2026-05-01 02:57:48 -06:00
build.sh
CubicalBench.lean
CubicalTest.lean
CubicalTransport.lean
lake-manifest.json
lakefile.toml
lean-toolchain
LICENSE
NOTICE
README.md

cubical-transport-hott-lean4

A Lean 4 implementation of cubical-transport homotopy type theory (CCHM-flavor), with a fast Rust kernel exposed through C ABI.

The Lean side defines the syntax, semantics, and soundness theorems. The Rust side discharges the per-step β-rules of the evaluator. Lean axioms are routed through @[implemented_by] to Rust functions that return Lean objects in the same shape Lean would have produced; the soundness layer (CubicalTransport/Soundness.lean) certifies the backend at the boundary, so the kernel speed of the Rust code preserves the Lean-level proofs.

What's here

  • CubicalTransport/ — 22 Lean modules for syntax, substitution, dimensional structure, faces, typing, evaluation (eval / value / readback), transport, Glue, composition, and the soundness theorems.
  • native/cubical/ — Rust kernel (#![no_std], dual-target native staticlib + cdylib, wasm32 cdylib).
  • CubicalTest.lean, CubicalBench.lean — engine smoke + property tests (62/62 passing) and microbenchmarks.

Consuming the engine (with permission)

This Software is proprietary. See LICENSE — no use is granted by virtue of the repository being public. The instructions below are for the copyright holder and any party with prior written consent from mgorog@gmail.com.

Add as a Lake dependency from another Lean 4 project:

[[require]]
name = "cubicalTransport"
path = "../cubical-transport-hott-lean4"   # or git = "..."

Then import CubicalTransport.Syntax, import CubicalTransport.Eval, etc. Link against native/cubical/target/release/libtopolei_cubical.a in your own moreLinkArgs so the FFI symbols resolve.

Build

(cd native/cubical && cargo build --release)
lake build
./.lake/build/bin/cubical-test    # 62/62 tests pass

Reference

  • docs/FFI_DESIGN.md — C ABI contract between Lean and the Rust kernel.
  • docs/FFI_COMPLETENESS.md — per-function axiom audit.
  • docs/KERNEL_BOUNDARY.md — what this delivers in unmodified Lean 4 vs. what would need upstream Lean kernel work.
  • docs/NUMERICAL.md — numerical implementation principles.
  • docs/PHASE1_HISTORY.md — original transport/composition formalisation plan (archived; Phase 1 closed; preserved as methodology template for future phases).
  • docs/ZIGZAG_PORT.md — step-by-step Lean port plan for the n-category combinatorial engine (Phase 2+ higher-cell backend). Lands here in the engine. Read the cascade caveat at the top before editing: changes in the ported zigzag layer cascade to the sibling topolei repo.
  • native/cubical/README.md — Rust crate build + dev guide.
  • native/cubical/WASM.md — wasm32 ABI integration contract.

Used by

  • max/topolei — the cells-spec workspace interface, built on this engine. See its docs/cells-spec.md and docs/STATUS.md for the application-side picture.