A general-purpose, cross-platform, functional scripting language and document processing engine in a single ~20 MB executable, built from scratch in C/C++.
Lambda is designed for two things at once:
- an expressive functional language for transforming data and documents, and
- an end-to-end document pipeline (parse → validate/transform → layout → render/view).
Internally, Lambda treats documents as structured data. Different input formats (Markdown, Wiki, HTML/XML, JSON/YAML/TOML/CSV, LaTeX, PDF, …) are parsed into a unified Lambda/Mark node tree, transformed with Lambda scripts, validated with schemas, and then rendered via the Radiant HTML/CSS/SVG/JS layout engine.
Note: Lambda Script is still evolving — syntax/semantics and implementation details may change. A stable subset of the literal data model is separately formalised and released as Mark Notation.
See all supported document types in the demo gallery.
Try it: download the Lambda binary from the Releases page, unzip, and run:
lambda demoLambda script (pure functional runtime)
- Pure-functional core with immutable data structures (arrays, maps, elements) and first-class functions and types.
- Expressive pipe operator (
|>, with the filter stage|:) for fluent set-oriented data transformation pipelines with inline mapping and filtering. - Vector arithmetic with automatic broadcasting — apply scalar operations to entire collections.
- Powerful for-expressions with
where,order by,limit,offsetclauses for SQL-like data querying. - Interactive REPL for exploration and debugging.
Markup input parsing & formatting
- Multi-format parsing: JSON, XML, HTML, Markdown, Wiki, YAML/TOML/INI, CSV, LaTeX, PDF, and more.
- Wiki dialects: MediaWiki, DokuWiki, TikiWiki, TWiki, Vimwiki, XWiki, ZimWiki, Creole, Jira and Confluence static profiles, with Lambda Script writers in
lambda.doc.wiki; see coverage and limits. - One universal representation: parse disparate syntaxes into a common Lambda/Mark node tree.
- Conversion pipeline: convert between formats using
lambda convert(auto-detect input formats when possible). - DOM-centric tooling: designed to treat "documents as data/objects", not just as text.
Type system & schema validation
- Rich type system with type inference and explicit type annotations, similar to and beyond that of TypeScript.
- Schema-based validation for structured data and document trees (including element schemas for HTML/XML-like structures).
Radiant HTML/CSS/SVG/JS layout, rendering & viewer
- Browser-compatible layout engine supporting html block, inline, flex, grid, and tables.
- Unified interactive viewer via
lambda view:- HTML/CSS/SVG with JavaScript — the embedded LambdaJS engine covers ES2024 (test262), the browser DOM and a Node.js compatibility layer
- XML (treated as HTML with CSS styling)
- Markdown / Wiki (rendered with styling)
- LaTeX (
.tex) via conversion to HTML - Lambda script (
.ls) evaluated to HTML and rendered (think of PHP)
- Render targets: SVG / PDF / PNG / JPEG output via
lambda render.
First-class markup syntax for document generation:
let card = <div class: "card",
<h2 "Title">
<p "Content here.">
>
format(card, 'html')
Scalar operations automatically broadcast over collections:
1 + [2, 3]; // [3, 4] — scalar + array
[1, 2] * 2; // [2, 4] — array * scalar
[1, 2] + [3, 4]; // [4, 6] — element-wise
[1, 2] ** 2; // [1, 4] — element-wise power
[1, 2, 3] eq 2 // [false, true, false] — element-wise comparison
The pipe operator |> enables fluent data transformations, and its filter stage |: keeps the items a test accepts. Use ~ to reference the current item:
let users = [{name: "Alice", age: 30}, {name: "Bob", age: 15}, {name: "Carol", age: 41}]
// Map: double each element
[1, 2, 3] |> ~ * 2; // [2, 4, 6]
// Extract fields
users |> ~.name; // ["Alice", "Bob", "Carol"]
// Filter with '|:'
[1, 2, 3, 4, 5] |: ~ > 3; // [4, 5]
// Chain operations: filter → map → aggregate
users |: ~.age >= 18 |> ~.name |> len // 2 — count adult names
Powerful comprehensions with let, where, order by,group by, limit, offset:
// Filter and transform
for (x in data where x > 0) x * 2
// With local bindings
for (x in data, let sq = x * x where sq > 10) sq
// Sorting and pagination
for (x in items order by x.price desc limit 5) x.name
// Type annotations
let x: int = 42
let items: string[] = ["a", "b"]
// Union and optional types
type Result = int | error
type Name = string?
// Element type patterns
type Link = <a href: string; string>
type Article = <article title: string; string, Section*>
// Function types
fn add(a: int, b: int) int => a + b
Match expressions support value, range, type, and constrained patterns:
fn describe(x) => match x {
case null: "nothing"
case 0: "zero" // literal value
case 1 to 9: "small number" // range
case int that ~ > 9: "big number" // type + constraint
case string: "text: " ++ ~ // type
case int[]: "int array" // collection type
default: "something else"
}
The ? query operator searches data trees by type or structure, similar to jQuery:
html?<img> // all <img> descendants
html?<div class: string> // <div>s with a class attribute
data?{status: "ok"} // maps where status == "ok"
html[body][div]?<a> // direct path then recursive search (given type body = <body>, type div = <div>)
-
Clone the repository:
git clone https://github.com/henry-luo/lambda.git cd lambda -
Install dependencies:
./setup-mac-deps.sh # macOS ./setup-linux-deps.sh # Linux ./setup-windows-deps.sh # Windows (under MSYS2)
-
Build:
Lambda uses a Premake5-based build system generated from build_lambda_config.json.
make build # Incremental build (recommended)
make release # Optimized release build
make test # Run unit test
make clean-all # Clean build artifactsThe build produces lambda.exe at the repo root; release bundles ship it as lambda.
lambda # interactive REPL
lambda <script.ls> # run a functional script
lambda run <script.ls> # run a procedural script
lambda validate <file> [-s <schema.ls>] # validate against a schema
lambda convert <input> -t <to> -o <output> # format conversion
lambda layout <file.html> # print the CSS layout tree
lambda render <input> -o <output.svg|pdf|png> # render to image
lambda view <file.html|file.md|file.ls|...> # open in interactive viewer
lambda edit <file.md|file.html|file.svg> # edit a document and save it back
lambda fetch <url> [-o file] # download a URL
lambda js <script.js> # run JavaScript on LambdaJS
lambda --help # show helpTip: lambda <command> --help prints detailed options and examples.
// Parse JSON and convert to Markdown (`^` propagates a read error)
let data = input("data.json", 'json')^
format(data, 'markdown')
// Process CSV data
let csv = input("data.csv", 'csv')^
for (row in csv where row.age > 25) row
λ> let data = input("sample.json", 'json')^
λ> len(data.users)
42
λ> for (u in data.users where u.active) u.name
("Alice", "Bob", "Charlie")
The latest run (Result50, 2026-09-30) covers 63 benchmarks across six standard suites (R7RS, AWFY, BENG, KOSTYA, LARCENY, JetStream) plus Text, against Node.js v22.13.0. Ratios are geometric means of JIT-pinned Lambda execution time divided by Node.js time; below 1.0× means Lambda is faster.
| Lambda MIR JIT vs. Node.js | Geo. Mean Ratio | Lambda Wins | Total |
|---|---|---|---|
| Typed | 0.54× (1.8× faster) | 42 | 63 |
| Untyped | 1.05× (5% slower) | 32 | 63 |
See the latest full benchmark report for per-benchmark details, memory profiling, and cross-engine comparisons.
| Standard | Result | Details |
|---|---|---|
| ECMAScript (TC39 test262, ES2024 scope) | 40,261 passing, 0 failing | of 42,889 tests; 2,628 skipped as ES2025+ or out of scope (details) |
| HTML5 parsing (html5lib tree construction) | 364 / 364 | the 7 html5lib test files the suite runs, of 53 |
| CSS layout (WPT and framework suites, compared with Chrome) | 1,874 full + 1,403 partial passes of 3,302 | the 15 gated suites, including Bootstrap 20 / 20 and Tailwind 70 / 70 (details) |
| CommonMark | 655 / 655 | specification examples; GFM tables, task lists and strikethrough add 22 / 22 |
| YAML 1.2 (yaml-test-suite) | 276 / 276 | cases with an expected JSON result |
| Document | Description |
|---|---|
| Document Pipeline | The Mark data model and the convert/validate/render/view/edit workflows |
| Tutorial | Ten chapters from installation to a reactive app, with checked examples |
| Cheatsheet | Quick reference for syntax and common patterns |
| Lambda Reference | Language overview, the documentation index, modules, and examples |
| Syntax | Statements, line continuation, reserved words, symbols, namespaces |
| Data & Collections | Literals, paths, arrays, maps, elements, ranges, document updates |
| Type System | Types, unions, object types, constraints, string patterns |
| Expressions & Statements | Operators, pipes, queries, control flow, and comprehensions |
| Functions | Function declarations, closures, and procedures |
| String Patterns | The pattern language inside \(…) and pattern-aware string functions |
| Reactive UI | view/edit templates, apply() and event handlers |
| Procedural Programming | var, assignment, value semantics, I/O, main(), concurrency |
| Error Handling | raise, T^E, postfix ^, the ^ { } handler, error codes |
| Modules | Imports, pub exports, built-in, package and JavaScript modules |
| Concurrency | Tasks, mailboxes, select, timeouts and cancellation |
| System Functions | Built-in functions (math, string, collection, I/O, concurrency) |
| Packages | Libraries written in Lambda that ship with the runtime (math, chart, graph, LaTeX, PDF, …) |
| CLI Reference | Commands, flags, and usage for the Lambda CLI |
| Validator Guide | Schema-based validation with lambda validate |
| Markup & Data Format Support | Supported input and output formats and how they map to Lambda/Mark |
| Doc Schema | Schema for lightweight markup (Markdown, Wiki, RST) |
| HTML, CSS and SVG Support | What the Radiant layout and rendering engine supports |
| Math Support | LaTeX and ASCII math input and rendering |
| Formal Semantics | Normative semantics specification — S-numbered rulings; the semantic authority when docs or implementation disagree |
| Document | Description |
|---|---|
| Developer Guide | Build from source, dependencies, testing, Tree-sitter grammar, MIR JIT |
| Formal Design | Normative design/implementation specification — D-numbered rulings for the core runtime; the design authority when docs or implementation disagree |
| Documentation Convention | How Lambda documentation is organized — document tiers, authority order, and style conventions |
| C+ Coding Convention | C/C++ coding convention |
| Lambda Core Runtime Design | Detailed design of the core runtime — compilation pipeline, value & type model, the MIR-Direct transpiler, MIR JIT, memory & GC, builtins, error handling, Mark API, and the procedural runtime |
| Radiant Engine Design | Detailed design of the HTML/CSS layout, rendering, and interaction engine — view/DOM model, CSS resolution, layout (block/inline/flex/grid/table), rendering pipeline, SVG, events, editing, state, shell, JS scripting, and media/webview (index to the RAD_01–RAD_22 set) |
| JS and DOM Support | Experimental JavaScript JIT engine and browser DOM — supported features and benchmarks |
| LambdaJS Runtime Design | Detailed design of the embedded JavaScript engine — compilation pipeline, value model, runtime, standard library, RegExp, async/modules, DOM, and Node.js compatibility |
| Platform | Status | Notes |
|---|---|---|
| macOS | ✅ Full | Native development platform |
| Linux | ✅ Full | Ubuntu 20.04+ tested |
| Windows | ✅ Full | Native build via MSYS2 |
This project is licensed under the MIT License - see the LICENSE file for details.
- MIR Project: JIT compilation infrastructure
- Tree-sitter: Incremental parsing framework
- ThorVG: SVG vector graphics library
- Curl: HTTP client and network transfer library
- mbedTLS: TLS and cryptography library