agentleFS
rainoftimerainoftime/pl-skills/dependent-type-implementer/SKILL.md

dependent-type-implementer

Skill17 starsChanged 9 months agoApache-2.0View on GitHub

Implements dependently typed lambda calculus (Pi types). Use when: (1)

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 6 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Start from a minimal core (Var, Pi, Lam, App, universes)

    line 40
  2. Very specific:

    Add Sigma, naturals, and eliminators incrementally

    line 43
  3. Distinctive:

    Start with simple dependent types

    line 216
  4. Distinctive:

    Use de Bruijn for binding

    line 218
  5. Distinctive:

    For simple verification: Use refinement types instead (Liquid Haskell, F*)

    line 250
  6. Distinctive:

    For performance: Consider Haskell/OCaml with GADTs

    line 251
  7. Distinctive:

    For teaching: Start with System F or STLC

    line 252
  8. Distinctive:

    Universe levels: Must handle Level → Level max → etc.

    line 266

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Dependent Type Implementer

Implements dependent type theory (Type Theory, Π Types, Σ Types).

When to Use

  • Building proof assistants (Coq, Agda, Idris)
  • Formalizing mathematics
  • Verified programming
  • Type-level computation

What This Skill Does

  1. Implements Π types - Dependent functions τ → σ(x)
  2. Implements Σ types - Dependent pairs (x:τ) × σ(x)
  3. Type checking - With conversion and unification
  4. Proof elaboration - From surface to core syntax

How to Use

  1. Start from a minimal core (Var, Pi, Lam, App, universes)
  2. Implement normalization and definitional equality
  3. Type-check by synthesis/checking with conversion
  4. Add Sigma, naturals, and eliminators incrementally

Core Theory

Dependent Function (Π):
  Π(x:A). B  or  (x:A) → B
  
  When x not in B: A → B (non-dependent)

Dependent Pair (Σ):
  Σ(x:A). B  or  (x:A) × B
  
  When x not in B: A × B (product)

Type formation rules:
  Γ ⊢ A : s    Γ, x:A ⊢ B : s
  ------------------------------
  Γ ⊢ Π(x:A).B : s
  
  Γ ⊢ A : s    Γ, x:A ⊢ B : s
  ------------------------------
  Γ ⊢ Σ(x:A).B : s

Implementation

(* Core Syntax (conceptual) *)

Term types:
  - Type (universe)
  - Var (de Bruijn index)
  - Lam (abstraction with optional type annotation)
  - App (application)
  - Pi (dependent function type)
  - Sigma (dependent pair type)
  - Pair, Proj1, Proj2 (pair intro/elim)
  - Unit, Nat, Zero, Succ, NatElim (basic types)

Type formation rules:
  Γ ⊢ A : s    Γ, x:A ⊢ B : s
  ------------------------------
  Γ ⊢ Π(x:A).B : s

  Γ ⊢ A : s    Γ, x:A ⊢ B : s
  ------------------------------
  Γ ⊢ Σ(x:A).B : s

Typing rules (key cases):
  T_Abs:  Γ ⊢ A : s
          Γ, x:A ⊢ N : B
          ----------------
          Γ ⊢ λx:A. N : Π(x:A).B

  T_App:  Γ ⊢ M : Π(x:A).B
          Γ ⊢ N : A
          -----------------
          Γ ⊢ M N : B[x := N]

  T_Pair: Γ ⊢ M : A
          Γ ⊢ N : B[x := M]
          ------------------
          Γ ⊢ (M, N) : Σ(x:A).B

Elaboration

From surface syntax to core:

Surface: λ(x : A) => e
Core:    Lam A e

Elaboration algorithm:
1. Infer type of binding: A : s
2. Extend context with x : A
3. Elaborate body: e : B
4. Compute result type:
   - Non-dependent: Pi A (λx. B)
   - Dependent: Pi A (λx. B)

Pattern matching elaboration:
  match e return P with
  | c1 => e1
  | c2 => e2
  end

  becomes:
  NatElim P e (λ_. e1) (λn. λIH. e2)

Universe Polymorphism

(* Cumulative universes *)
Inductive universe : Type :=
  | Set0 : universe
  | Set1 : universe
  | Set2 : universe
  | ... (* Prop, SProp, etc. *)

(* Universe constraints *)
Check (Type@{i} -> Type@{j}).
(* i ≤ j required *)

(* Cumulative: Set@{i} ≤ Set@{i+1} *)

Implementation in OCaml

(* Core dependent type checker *)

type term =
  | Var of int
  | Lambda of term * term
  | App of term * term
  | Pi of term * term        (* Π x : A. B *)
  | Sigma of term * term     (* Σ x : A. B *)
  | Pair of term * term
  | Proj1 of term
  | Proj2 of term
  | Star                       (* unit *)
  | Nat | Zero | Succ of term
  | NatElim of term * term * term * term

type value =
  | VLambda of (value -> value)
  | VPi of value * (value -> value)
  | VSigma of value * value
  | VPair of value * value
  | VStar
  | VNat
  | VZero
  | VSucc of value

let rec eval (t : term) (ρ : value list) : value =
  match t with
  | Var i -> List.nth ρ i
  | Lambda (a, b) -> VLambda (fun v -> eval b (v :: ρ))
  | App (m, n) ->
      let vm = eval m ρ in
      let vn = eval n ρ in
      (match vm with
       | VLambda f -> f vn
       | _ -> failwith "apply non-function")
  | Pi (a, b) -> VPi (eval a ρ) (fun v -> eval b (v :: ρ))
  (* ... more cases *)

Key Concepts

ConceptDescription
Π typesDependent functions
Σ typesDependent pairs
UniversesType of types (Set, Type₀, ...)
Conversionβη-equivalence
ElaborationSurface → core

Advanced Features

FeatureDescription
MatchPattern matching (via NatElim)
Universe polymorphismGeneric over universes
CumulativitySubtyping between universes
IrrelevanceProp irrelevance (SProp)
Observational equalityUIP, univalence

Tips

  • Start with simple dependent types
  • Implement conversion checking carefully
  • Use de Bruijn for binding
  • Consider universe constraints
  • Handle definitional equality

Related Skills

  • system-f - Polymorphic lambda calculus
  • type-inference-engine - HM inference
  • coq-proof-assistant - Coq proofs

Canonical References

ReferenceWhy It Matters
Coq Reference ManualDefinitive implementation reference
Martin-Löf, "Intuitionistic Type Theory" (1984)Original dependent type theory
Harper & Pfenning, "On Equivalence and Canonical Forms in the LF Type Theory" (2005)Type-directed conversion checking
Abel, Coquand & Dybjer, "Normalization by Evaluation for Martin-Löf Type Theory" (2007)NbE for dependent types
Chapman, Altenkirch & McBride, "Epigram Reloaded: A Standalone Typechecker for ETT" (2006)Elaboration implementation

Tradeoffs and Limitations

Implementation Approach Tradeoffs

ApproachProsCons
Type checkingDecidable, simpleLess powerful inference
Type inferenceMore convenientComplex constraint solving
BidirectionalBalancedStill incomplete

When NOT to Implement Dependent Types

  • For simple verification: Use refinement types instead (Liquid Haskell, F*)
  • For performance: Consider Haskell/OCaml with GADTs
  • For teaching: Start with System F or STLC

Complexity Considerations

  • Undecidability: Full type checking is undecidable for dependent types
  • Universe constraints: Solving universe constraints is complex
  • Normalization: Required for conversion; expensive without NbE
  • Type inference: Principally undecidable; use bidirectional checking

Limitations

  • Performance: 10-100x slower than simple types
  • Error messages: Hard to make comprehensible
  • Termination checking: Required for soundness (or positivity)
  • Universe levels: Must handle Level → Level max → etc.
  • Normalization: Full β-reduction needed for conversion
  • Learning curve: Users need to understand type theory

Research Tools & Artifacts

Dependent type systems:

SystemLanguageWhat to Learn
CoqOCamlProduction proof assistant
AgdaHaskellDependently typed programming
IdrisIdrisType-driven development
LeanLeanModern proof assistant
NuPRLLispConstructive type theory

Key Papers

  • Martin-Löf - Original type theory
  • Coquand - Calculus of Constructions
  • Harper et al. - Syntactic theory

Research Frontiers

1. Homotopy Type Theory

  • Goal: Univalence, higher inductive types
  • Approach: Path types, identity types
  • Books: HoTT Book

2. Cubical Type Theory

  • Goal: Computational univalence
  • Approach: Kan operations, faces

Implementation Pitfalls

PitfallReal ConsequenceSolution
Universe inconsistencyParadoxesUniverse checking
Non-terminationUnsoundnessTermination check
Conversion inefficiencySlow checkingNbE

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.