Map

Typed De Bruijn indices for LLMs

Wiki conceptlanguage-designcoding-agentstype-system โ†ณ show in map Markdown
title
Typed De Bruijn indices for LLMs
type
concept
summary
Replace variable names with typed slot references (@Type.n) so naming-related LLM error modes โ€” misleading names, reused names, lost references โ€” become impossible
tags
language-design, coding-agents, type-system
created
2026-04-30
updated
2026-04-30

Classical De Bruijn indices replace named variables with positional references (ฮปx.ฮปy.x becomes ฮป.ฮป.1). Vera's variant types each binding and references it by type plus reverse-position: @Int.0 is the most recent Int in scope, @Int.1 is the previous one, @String.0 is the most recent String. There are no shadow concerns because the slot is identified by type โ€” adding a new Int doesn't shift what @String.0 refers to.

The motivation is empirical. The Vera README cites work showing LLMs are particularly vulnerable to naming-related errors: choosing misleading names, reusing names incorrectly, losing track of which name refers to which value (see arXiv:2307.12488). All three failure modes go away in a language where names don't exist. The model doesn't need to remember what it called the user input โ€” there's only one @String in scope, or two, and the reference is positional.

What you give up

  • Reading commutative operations. @Int.0 + @Int.1 and @Int.1 + @Int.0 are the same value but visually distinct, and a human reviewer has to mentally bind a name to each slot to follow non-trivial arithmetic. Vera's DE_BRUIJN.md calls this "the commutative-operations trap."
  • The cognitive crutch of self-documenting names. A human reader of userBalance / pricePerToken sees the domain meaning at a glance. @Int.0 / @Int.1 doesn't carry that information โ€” it has to come from the contract, the function name, or comments.

The bet is that the trade is worth it for the LLM-as-author case, because the noise-reduction wins more than the loss of human readability costs (humans review the contract, not the slot expression).

Where else it might apply

The idea isn't tied to Vera. Any language designed to be primarily AI-authored has the same naming-failure-mode incentive. The same argument extends to:

  • Constructor field positions over named struct fields (some languages already allow positional construction).
  • Anonymous lambda arguments โ€” _1, _2 in some Scala/F# styles, the same idea narrower in scope.
  • Pipeline operators (|>) that thread a value through transformations without binding it to a name.

What Vera adds is making the slot system load-bearing throughout the language rather than offering it as a stylistic alternative.

Cross-references

  • vera โ€” the toolbox entry for the language.
  • vamp-ai-frontend โ€” adjacent: framework implicitness (VDOM, hooks, reconciliation) is the enemy of AI-generated code, and explicit pipelines win for the same reason names lose here.
  • clippy-stricter-config โ€” opposite axis: instead of rebuilding the language to be agent-friendly, ratchet a conventional language with lints.
  • clean-code-coding-agents โ€” context-window economics that put pressure on languages to be cheap-to-orient-in.