nela-foundations
Provides the formal mathematical framework for NELA language development, prioritizing Interaction Net theory and Linear Logic over outdated cellular automata models.
Install
mkdir -p .claude/skills/nela-foundations && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14963" && unzip -o skill.zip -d .claude/skills/nela-foundations && rm skill.zipInstalls to .claude/skills/nela-foundations
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Mathematical foundations for NELA language design. Primary theory: Interaction Nets (Lafont 1990) — local graph rewriting, NOT automata theory. Supporting theories: Linear Logic (resource semantics), Dependent Type Theory (verification). Von Neumann CA is historical background only — do not use it to guide language design decisions. Load this skill before designing any NELA language construct, rewrite rule, or type system component.Key capabilities
- →Design NELA language constructs based on Interaction Nets
- →Apply Linear Logic for resource semantics
- →Use Dependent Type Theory for program verification
- →Ensure language rewrites follow cut-elimination
- →Define NELA-S (surface language) grammar
- →Distinguish NELA-S from NELA-C (core language)
How it works
The skill applies Interaction Net theory as the computational model, Linear Logic for resource semantics, and Dependent Type Theory for verification to guide NELA language design. It distinguishes between a surface language (NELA-S) for LLMs and a core language (NELA-C) for formal verification.
Inputs & outputs
When to use nela-foundations
- →Define new NELA language constructs using Interaction Net graph rewriting
- →Validate type system components against Linear Logic principles
- →Ensure language rewrites follow cut-elimination reduction rules
- →Verify that proposed language features maintain local graph properties
About this skill
NELA Mathematical Foundations
ORIENTATION — READ FIRST. Despite the word "Automaton" in the name, NELA is not an automata-theory language. The name is historical (kept for brand continuity). The actual computational model is Interaction Net theory (Lafont, 1990): local graph rewriting over typed nodes.
Theory priority (read the parts below in this order):
Priority Part Theory Role in NELA 1 Part 1 Interaction Nets The computation model. Every NELA-C program IS an interaction net. 2 Part 2 Linear Logic Resource semantics. Types are LL formulas. Cut elimination = reduction. 3 Part 3 Dependent Type Theory Programs = proofs. Ill-typed nets are unrepresentable. 4 Part 4 Von Neumann CA Historical ancestor. Contributed locality + quiescence metaphors only. When extending the language: use Parts 1–3. Do not reach for CA concepts. If Parts 1–3 and Part 4 conflict, Parts 1–3 win.
Critical Architecture Decision: Two-Layer Design
Lesson from implementation (v0.1 → v0.2): Hand-writing interaction nets at the Lam/App/Dup/Fix grain is NOT the right surface language for LLMs. Quicksort required 17 nodes and 24 wired edges vs. 4 lines in Python — worse, not better, for LLM comprehension. The v0.1 runtime produced zero reductions because principal-port wiring conventions were ambiguous at that grain.
The correct design is a two-layer architecture:
Layer Name What LLMs do Representation Surface NELA-S Read, write, reason ML/Haskell-like syntax (.nela files); parsed to typed expression DAG Core NELA-C Never touch directly Interaction net graph LLMs write NELA-S. A compiler lowers NELA-S → NELA-C for formal verification and optimal parallel execution. The interaction net layer is the semantic foundation, not the working medium. This is the same relation as: Haskell → GHC Core → STG → machine code.
NELA Surface Language (NELA-S) — What LLMs Write
A NELA-S program is an ML/Haskell-like source file (.nela). nela_parser.py parses it
into the typed expression DAG dict consumed by the runtime.
- One or more
def name param ... = bodyforms - Each body is an
Expr(see grammar below)
Expr grammar (ML/Haskell-like surface form)
-- Program
def name param ... = body
-- Expr
INT | name -- literals / variables
(-INT) -- negative literal in arg position
[] -- nil
[a, b, c] -- list literal (sugar for a :: b :: c :: [])
e :: e -- cons (right-associative)
e ++ e -- append
(e, e) -- pair
[x <- list | pred] -- list comprehension (filter)
match e | pat = body | pat = body -- exhaustive pattern match
let x = e in body -- local binding
let (a, b) = e in body -- tuple destructuring
if e then e else e -- conditional
e + e | e - e | e * e | e / e | e % e -- arithmetic (/ = int div, % = mod)
-e -- unary negation
e == e | e < e | e <= e | e > e | e >= e -- comparison
e && e | e || e | not e -- boolean
f e e ... -- function application
-- Pattern (inside match cases)
[] -- nil
[h] -- singleton
h :: t -- cons
h :: h2 :: t -- nested cons (3-spine)
(p1, p2) -- tuple decomposition
_ -- wildcard
name -- catch-all variable
Runtime dict ops (for reference / compiler output)
Expr :=
| {"op": "var", "n": name} -- variable
| {"op": "int", "v": number} -- integer literal
| {"op": "bool", "v": bool} -- boolean literal
| {"op": "nil"} -- empty list []
| {"op": "cons", "head": Expr, "tail": Expr} -- list cons x : xs
| {"op": "match", "e": Expr, "cases": [Case]} -- exhaustive pattern match
| {"op": "call", "fn": name, "a": [Expr]} -- call (single or multi-arg; recursive ok)
| {"op": "let", "x": name, "e": Expr, "in": Expr} -- local binding
| {"op": "if", "cond": Expr, "then": Expr, "else_": Expr} -- conditional
-- Pair ADT (return two values from a single function)
| {"op": "pair", "l": Expr, "r": Expr} -- construct (a, b)
| {"op": "fst", "e": Expr} -- project first
| {"op": "snd", "e": Expr} -- project second
-- List accessors
| {"op": "head", "e": Expr} -- unsafe head (non-empty only)
| {"op": "tail", "e": Expr} -- unsafe tail
| {"op": "take", "n": Expr, "e": Expr} -- first n elements
| {"op": "drop", "n": Expr, "e": Expr} -- drop first n
-- Arithmetic & comparison
| {"op": "add"|"sub"|"mul"|"div"|"mod", "l": Expr, "r": Expr}
-- div = integer division, mod = remainder
| {"op": "neg", "e": Expr} -- unary negation (-e)
| {"op": "eq"|"lt"|"le"|"gt"|"ge", "l": Expr, "r": Expr}
-- Boolean combinators
| {"op": "and"|"or", "l": Expr, "r": Expr}
| {"op": "not", "e": Expr}
-- List combinators (prefer over hand-written recursion where applicable)
| {"op": "append", "l": Expr, "r": Expr} -- list concat (++)
| {"op": "filter", "pred": str, "pivot": Expr, "list": Expr} -- [x <- list | pred pivot]
Token cost comparison (quicksort)
| Representation | Tokens (approx) |
|---|---|
| NELA-S v0.4 ML syntax | ~25 tokens |
| NELA-S v0.3 S-expression | ~35 tokens |
| NELA-S v0.2 JSON DAG | ~70 tokens |
| NELA-C interaction nets (v0.1) | ~250 tokens |
| Python quicksort | ~45 tokens |
Part 1 — Interaction Nets (Lafont, 1990/1997)
This is the primary theory of NELA. Every NELA-C program is an interaction net. Strong confluence = free parallelism. 3 combinators are Turing-complete. This theory fully supersedes Von Neumann CA for language design.
1.1 Signature and Agents
Definition 2.1 (Signature). A signature $\Sigma$ is a set of agent names $\alpha$ each equipped with an arity $ar(\alpha) \in \mathbb{N}$.
An agent $\alpha$ of arity $n$ is drawn as a node with:
- 1 principal port (marked with a dot
•) - $n$ auxiliary ports $x_1, \ldots, x_n$ (ordered)
Total ports per agent: $ar(\alpha) + 1$.
1.2 Nets
Definition 1.2 (Net). A net $N$ over $\Sigma$ is a graph where:
- Nodes are agents from $\Sigma$ (each occurrence is distinct)
- Edges connect ports; each port is connected to at most one other port
- Ports with no connection are free ports forming the interface $\text{Int}(N)$
- No edge connects two auxiliary ports of the same agent
A net is closed if $\text{Int}(N) = \emptyset$.
1.3 Active Pairs
Definition 1.3 (Active pair). Two agents $\alpha, \beta$ form an active pair (or redex) when their principal ports are connected:
$$\alpha \bowtie \beta$$
This is the ONLY location where computation can occur.
1.4 Interaction Rules
Definition 1.4 (Rule). An interaction rule for the pair $(\alpha, \beta)$ is:
$$\alpha \bowtie \beta ;\longrightarrow; N_{\alpha\beta}$$
where $N_{\alpha\beta}$ is a net whose free ports are exactly the auxiliary ports of $\alpha$ and $\beta$.
Determinism constraint: Each pair $(\alpha, \beta)$ has at most one rule (commutativity: $(\alpha,\beta)$ and $(\beta,\alpha)$ share the same rule).
Locality: A rule application affects only the active pair and the net $N_{\alpha\beta}$; the rest of the net is untouched.
1.5 Strong Confluence
Theorem 1.1 (Strong Confluence, Lafont 1990). For any interaction system $(\Sigma, R)$, if $N \rightarrow_R N_1$ and $N \rightarrow_R N_2$ arise from different active pairs, then there exists $N_3$ such that:
$$N_1 \rightarrow_R N_3 \quad \text{and} \quad N_2 \rightarrow_R N_3$$
in exactly one step each.
Corollary: All reduction strategies (sequential, parallel, random) reach the same normal form. Parallelism is free.
Proof sketch: Different active pairs share no ports (by locality). Thus their reductions are completely independent; the resulting nets can be composed to yield $N_3$.
1.6 Symmetric Interaction Combinators
Definition 1.5. The Symmetric Interaction Combinators use signature:
$$\Sigma_{SIC} = {\gamma,; \delta,; \varepsilon}$$
with arities $ar(\gamma) = 2$, $ar(\delta) = 2$, $ar(\varepsilon) = 0$.
The six interaction rules:
| Active pair | Rule name | Effect |
|---|---|---|
| $\gamma \bowtie \gamma$ | Annihilation | Aux ports connected crosswise: $x_1 \leftrightarrow y_1$, $x_2 \leftrightarrow y_2$ |
| $\delta \bowtie \delta$ | Annihilation | Same structure |
| $\varepsilon \bowtie \varepsilon$ | Annihilation | Both nodes deleted, no new net |
| $\gamma \bowtie \delta$ | Commutation | Each $\gamma$ copies $\delta$, each $\delta$ copies $\gamma$; 4 nodes created |
| $\gamma \bowtie \varepsilon$ | Erasure | $\varepsilon$ erases $\gamma$; $\gamma$'s aux ports each get their own $\varepsilon$ |
| $\delta \bowtie \varepsilon$ | Erasure | Same as above for $\delta$ |
Theorem 1.2 (Universality, Lafont 1997). The symmetric combinators $(\Sigma_{SIC}, R_{SIC})$ are computationally universal: any interaction system can be translated into $(\Sigma_{SIC}, R_{SIC})$.
Corollary: Any algorithm expressible in lambda calculus (or equivalently
Content truncated.
When not to use it
- →When using Von Neumann CA concepts to guide language design
- →When extending the language without considering Interaction Nets, Linear Logic, or Dependent Type Theory
- →When directly manipulating the NELA-C interaction net graph
Limitations
- →NELA is not an automata-theory language
- →Von Neumann CA is historical background only
- →LLMs should not directly touch NELA-C
How it compares
This skill provides a formal, theory-driven approach to language design based on Interaction Nets, Linear Logic, and Dependent Type Theory, which is distinct from ad-hoc language development or approaches based on automata theory.
Compared to similar skills
nela-foundations side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| nela-foundations (this skill) | 0 | 3mo | Review | Advanced |
| when-stuck-problem-solving-dispatch | 8 | 9mo | No flags | Beginner |
| value-stream-mapping | 0 | 7mo | No flags | Intermediate |
| windsurf-cascade-context | 1 | 2mo | No flags | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
when-stuck-problem-solving-dispatch
mrgoonie
Dispatch to the right problem-solving technique based on how you're stuck
value-stream-mapping
Prorise-cool
Lean value stream mapping for identifying waste and optimization opportunities. Creates current/future state maps with cycle time analysis and improvement recommendations.
windsurf-cascade-context
jeremylongshore
Manage Cascade context window and memory for complex projects. Activate when users mention "cascade context", "ai memory", "context management", "large codebase navigation", or "multi-session development". Handles context optimization and persistence. Use when working with windsurf cascade context functionality. Trigger with phrases like "windsurf cascade context", "windsurf context", "windsurf".
maintain
Alan-Jowett
>
discipline-governance
cyberAlchemyAI
Use when: formalizing, routing, validating, promoting, or retiring an Arcanum discipline so a recurring cross-capability practice gets a card, catalog entry, and a hardening route without claiming sigil or spell authority.
claude
yuiseki
|