Lumen Binary

A small compiler for one quiet idea: that a great deal of mathematics can be made from a single binary operation, and that the path from a human-shaped intention to an executable signal is short enough to read.

eml(x, y) = exp(x) − ln(y)

Lumen translates a phrase like “make a wave” into a chain of typed artifacts — an attractor, a target, a tree, a graph, a sampled signal — each carrying its own provenance, its own decision policy, and its own trace. The grammar above is the entire instruction set. Everything else is composition.

intent  →  attractor  →  form  →  EML tree  →  DAG  →  signal  →  interpretation

At a glance

npm install
npm test
npm run lumen "make a wave"
npm run lumen run examples/wave.lumen

A .lumen file is a compile specification, not a program:

intent "make a wave"

world {
  domain: [-3.14159, 3.14159]
  precision: 0.01
  max_depth: 3
  sample_count: 64
  backend: "typescript"
  visual: "waveform"
  mode: "education"
  medium: "digital"
}

policy {
  accuracy: 0.45
  simplicity: 0.20
  interpretability: 0.10
}

target sin(x)

compile eml { search: "enumerative" }

run
explain

What the compiler emits is not just an answer; it is a typed lineage. You can ask it explain and watch each transformation name itself.

What it actually does well

exp(x) falls out of the search exactly as a three-node tree:

exp(x)  ≡  eml(x, 1)

Verified at five points to machine precision (see scripts/verify-identities.ts). Other identities the primitive carries cleanly:

expression	value
eml(0, 1)	1
eml(1, 1)	e
eml(2, 1)	e²
eml(0, e)	0
eml(ln 2, 1)	2

For deeper targets — sin(x), cos(x), π — the depth-3 enumerative search returns the best tree it can within its budget, along with an honest loss number. That is the contract: a tree, a score, and the reasoning by which it won.

Architecture

src/
  core/            EML primitive, tree, eval, loss, DAG
  protocol/        COP-1 entity packets, plugin interface, router
  ontology/        LFO categories, cross-ontology mappings, applications
  plugins/         intent, semantic, math-form, search, optimizer, runtime, viz, interpretation
  language/        .lumen tokenizer, parser, lowering
  compiler/        pipeline + entrypoint + plugin registry
  sustainability/  per-compile trace
  cli/             CLI entry

Every plugin declares which EntityKind it accepts and produces. The router picks the first plugin that can speak to the current packet. Adding a stage means adding one file; nothing else has to change.

What it does not claim

Lumen is a compiler playground. It does not prove anything about consciousness, quantum mechanics, or new physics. The poetic frame in docs/manifesto.md is motivation, not a load-bearing claim. The code is defensible without it.

Documentation

• Manifesto — what the project is and is not
• Language — .lumen syntax and semantics
• Protocol — the COP-1 packet and the plugin contract
• Ontology — LFO categories and cross-ontology mappings
• Sustainability — what every compile records
• Applications — where Lumen is genuinely useful
• Contributing — how to add a plugin

Status

Pre-1.0. The pipeline shape, the COP-1 packet, and the EML primitive are stable. The DSL grammar will gain keys and may tighten the target block before 1.0; breaking changes will be announced in CHANGELOG.md.

License

MIT — see LICENSE.