Ontology

Ontology

LOVE-LANG’s semantics are grounded in a formal ontology — a set of invariant truths about what the language is, what it can do, and what it must never do.

---

The Superautology

“There is officially no syntax for Love, but there is an invariant that all variant autologies must follow.”

The Superautology is the master invariant of LOVE-LANG. It is the rule that cannot be broken without ceasing to be LOVE. Every programme, every extension, every new language variant built on top of LOVE must satisfy the Superautology.

Think of it as the constitution of the language. It does not prescribe every law — but nothing can contradict it.

---

Expression Rings (L0–L5)

The five levels correspond to concentric rings of trust and capability:

Level	Ring	Description
L0	Base	The lowest level — closest to the metal. Primitive memory.
L1	Data	Lists and primitive references.
L2	Operations	Pure functions and math.
L3	Contracts	Type schemas and structural validators.
L4	Directives	Compiler macros and code generation.
L5	Kernel	FFI, I/O, and system-level side effects.

Note

L0 is not directly writeable by user programmes. It is the internal representation used by the LOVE evaluator itself — a linear array of memory that contains data in the same order it appears in the source, plus pointers for easy access.

---

TENET & SATOR

Two special meta-directives govern the extended behaviour of LOVE programmes:

@TENET

TENET enforces the Liskov Substitution Principle (LSP) at the programme level. A @TENET block defines invariant truths — expected state changes that the programme must produce. If the programme runs but does not satisfy its TENET, the evaluation is considered a failure.

@TENET
[expected_state]
db_table        = "users"
inserted_keys   = "name, hash"
hash_matches_raw = false

@SATOR

SATOR is the master rotor — a compile-time directive that maps logical intent through the five SOLID principles before generating code. Named after the ancient palindromic magic square, SATOR enforces bidirectional correctness: the programme must work in both forward and backward directions.

@SATOR
[compile_strategy]
opera  = "draft-intent"
arepo  = "constrain-effectors"
rotas  = "materialize-ast"
tenet  = "verify-invariants"

---

SATOR/SOLID Synthesis

LOVE-LANG maps the SOLID principles onto its compilation pipeline:

SOLID	LOVE Principle	Phase
S — Single Responsibility	Each ring handles one semantic level	All levels
O — Open/Closed	Extend the language via new effectors, never modify the Superautology	L4
L — Liskov Substitution	@TENET verifies substitutability of values	Simulation phase
I — Interface Segregation	@AREPO — only use declared effectors	L5
D — Dependency Inversion	@OPERA — draft logic before syntax	L1 draft

---

The Three-Phase Compilation Pipeline

Every LOVE programme goes through three phases:

Phase 1 — OPERA (Draft)

File: /logic/[name].love

Draft the intent in pseudo-lisp. Focus on logical causality. Do not worry about bracket depths.

/logic/auth_flow.love

(def raw_pass "password123")
(def user_name "alice")

(let [hashed_pass (@hash_pass raw_pass)
      payload     (UserPayload user_name hashed_pass)]
  (@sql_write "users" payload))

Phase 2 — MATERIALIZE (AST)

File: /programmes/[name].edn

Translate the draft into strict LOVE-LANG EDN with correct bracket depths.

/programmes/auth_flow.edn

{:type :programme
 :body
 [raw_pass  . "password123"
  user_name . "alice"
  hashed_pass . [[ @hash_pass [raw_pass] ]]

  [[[[[ @sql_write
    "users"
    [[[ UserPayload ]]] { :name [user_name] :hash [hashed_pass] }
  ]]]]]]}

Phase 3 — SIMULATE (Invariants)

File: /simulations/[name].ini

Define the expected outputs. These are verified by the @TENET checker.

/simulations/auth_flow.ini

[expected_state]
db_table         = "users"
inserted_keys    = "name, hash"
hash_matches_raw = false

---

Managed Stochastics

LOVE-LANG introduces the concept of Managed Stochastics — treating LLMs and other non-deterministic systems as multi-pass compilers rather than conversational agents.

The LOVE ontology forces fuzzy natural language intent through a rigorous, multi-stage pipeline, ultimately materializing strict, executable Abstract Syntax Trees in .edn format.

This is not metaphor. It is a practical architectural pattern for constrained AI-assisted development.