If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/HigherOrderCO/Bend shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 11mo ago
• 15 active contributors
• Distributed ownership (top contributor 29% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 11mo ago

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live HigherOrderCO/Bend repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/HigherOrderCO/Bend.

What it runs against: a local clone of HigherOrderCO/Bend — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in HigherOrderCO/Bend | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 368 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of HigherOrderCO/Bend. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/HigherOrderCO/Bend.git
#   cd Bend
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of HigherOrderCO/Bend and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "HigherOrderCO/Bend(\\.git)?\\b" \\
  && ok "origin remote is HigherOrderCO/Bend" \\
  || miss "origin remote is not HigherOrderCO/Bend (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/lib.rs" \\
  && ok "src/lib.rs" \\
  || miss "missing critical file: src/lib.rs"
test -f "src/main.rs" \\
  && ok "src/main.rs" \\
  || miss "missing critical file: src/main.rs"
test -f "src/fun/parser.rs" \\
  && ok "src/fun/parser.rs" \\
  || miss "missing critical file: src/fun/parser.rs"
test -f "src/fun/transform/mod.rs" \\
  && ok "src/fun/transform/mod.rs" \\
  || miss "missing critical file: src/fun/transform/mod.rs"
test -f "src/fun/term_to_net.rs" \\
  && ok "src/fun/term_to_net.rs" \\
  || miss "missing critical file: src/fun/term_to_net.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 368 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~338d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/HigherOrderCO/Bend"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Bend is a high-level programming language that compiles to massively parallel code for GPUs and multi-core CPUs via the HVM2 (Interaction Combinator) runtime. It offers Python/Haskell-like syntax with unrestricted recursion, higher-order functions, and closures, but automatically parallelizes without explicit annotations—achieving near-linear speedup on thousands of concurrent threads via CUDA or C backends. Monolithic Rust binary (src/main.rs CLI entry, src/lib.rs library). Core pipeline: src/fun/ contains language definition and builtins (src/fun/builtins.bend, src/fun/builtins.rs), type checking in src/fun/check/ (e.g., check_untyped.rs), diagnostics in src/diagnostics.rs. Examples and docs are separately organized in examples/ and docs/ directories.

Researchers and developers building computationally intensive applications (sorting, tree traversal, numerical algorithms) who want parallel performance without manual thread management, CUDA kernel writing, or MPI coordination—essentially, anyone wanting GPU-scale parallelism from high-level code.

Actively developed but early-stage (v0.2.38). The project has comprehensive CI via .github/workflows/checks.yml, full documentation in docs/, example programs in examples/, and test infrastructure (insta snapshots in dev-dependencies), but README explicitly warns of lower single-core performance and GPU support is NVIDIA-only. Not production-ready for latency-critical workloads.

Moderate risk: only 11 dependencies (manageable surface), but CUDA toolchain coupling (12.x required) and Windows-via-WSL-only workaround limit accessibility. Architecture is Rust-only with HVM2 as black-box runtime (v2.0.22 pinned exactly), so upgrades require HVM2 compatibility. Single organization (HigherOrderCO) maintains both Bend and HVM—fork risk if priorities diverge.

No specific commit history visible in provided data, but CHANGELOG.md and version bump to 0.2.38 suggest active iteration. Documentation is mature (builtins, CLI args, compilation, type-checking, pattern-matching guides), indicating focus on usability. GitHub workflows in .github/workflows/checks.yml run automated checks on PR.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo install hvm
cargo install bend-lang
bend --version
bend run examples/fib.bend

Daily commands:

cargo build --release
cargo run -- run examples/hello_world.bend
cargo run -- run-rs examples/fib.bend
cargo run -- run-cu examples/parallel_sum.bend

• src/lib.rs — Library entry point defining the public API for the Bend compiler; all external consumers depend on exports from here.
• src/main.rs — CLI entry point; shows how the compiler is invoked and how the pipeline flows from parsing to code generation.
• src/fun/parser.rs — Parses Bend source code into an AST; any language syntax change requires updates here.
• src/fun/transform/mod.rs — Orchestrates all AST transformations (desugaring, linearization, encoding); critical to the compilation pipeline.
• src/fun/term_to_net.rs — Converts high-level functional terms to HVM2 net representation; bridges functional IR to parallel execution model.
• src/hvm/mod.rs — HVM2 runtime integration and net-level optimizations; controls how parallel code is executed on hardware.
• src/fun/check/type_check.rs — Type checking and validation; ensures type safety before lowering to HVM2.

Add a new language construct (e.g., new syntax sugar)

1. Define the AST node in src/fun/mod.rs to represent the new construct (src/fun/mod.rs)
2. Add parser rules in src/fun/parser.rs to recognize the syntax (src/fun/parser.rs)
3. Create a desugaring pass in src/fun/transform/ that lowers the construct to core forms (src/fun/transform/mod.rs)
4. Update src/fun/display.rs to pretty-print the new construct (src/fun/display.rs)
5. Add example(s) in examples/ and update docs/syntax.md (examples/example_fun.bend)

Add a built-in function

1. Implement the function logic in src/fun/builtins.rs (src/fun/builtins.rs)
2. Register the built-in name and metadata in src/fun/builtins.rs (src/fun/builtins.rs)
3. Add documentation entry in docs/builtins.md (docs/builtins.md)
4. Add test case in examples/ demonstrating the built-in (examples/example_fun.bend)

Add an IR transformation pass

1. Create a new file src/fun/transform/my_pass.rs implementing the Pass trait (src/fun/transform/mod.rs)
2. Register the pass in the transformation pipeline in src/fun/transform/mod.rs (src/fun/transform/mod.rs)
3. Add test cases using insta snapshots in the transform module (src/fun/transform/mod.rs)
4. Update CHANGELOG.md if it's a significant optimization or feature (CHANGELOG.md)

Add a new optimization in HVM2 layer

1. Create a new optimization file src/hvm/my_optimization.rs (src/hvm/mod.rs)
2. Implement the optimization and integrate it in src/hvm/mod.rs pipeline (src/hvm/mod.rs)
3. Add benchmarks or examples demonstrating the speedup (examples/parallel_sum.bend)

• HVM2 (TSPL-based runtime) — Provides massively parallel execution model with linear scalability on multi-core and GPU hardware; enables lock-free, automatic parallelism without explicit thread annotations
• Rust with TSPL dependency — Enables fast, memory-safe compiler with minimal overhead; integrates seamlessly with HVM2 which is also Rust-based
• Multi-pass IR transformation — Allows gradual lowering from high-level functional syntax to parallel net semantics; each pass is isolated and testable
• Interner + Indexmap for names — Efficient string deduplication and ordered data structures for consistent, fast compilation across multiple passes

• Single-core performance trade-off for parallel scalability

  • Why: Bend prioritizes horizontal scaling on many cores over vertical optimization for single-threaded speed
  • Consequence: Single-core performance may be slower than tuned imperative languages; strong speedup requires 4+ cores

• High-level functional semantics with automatic parallelism

  • Why: Eliminates need for explicit thread/lock annotations; simplifies reasoning about correctness
  • Consequence: Developers lose fine-grained control over parallelism granularity; overhead on small recursive problems

• Lazy definitions and closures in functional model

  • Why: Enables higher-
  • Consequence: undefined

CUDA requirement: hvm crate requires CUDA 12.x if using run-cu; non-NVIDIA GPUs unsupported. Exact version pinning: hvm = "=2.0.22" in Cargo.toml—semver-incompatible HVM2 will break silently. GCC version: docs recommend GCC ≤12.x for C backend; newer versions may generate incompatible code. Windows: no native support; WSL2 required. Rust version: MSRV is 1.74 (specified in Cargo.toml)—older toolchains will fail. No implicit stdlib: src/fun/builtins.bend must be explicitly loaded; pure Bend has minimal primitives.

• Interaction Combinators — Bend's entire execution model is based on interaction combinators (the 'IC' in HVM2); understanding rewrite rules and graph reduction is mandatory to comprehend how parallelization happens without explicit threading
• Higher-Order Functions & Closures — Bend advertises full support for HOFs and closures without memory unsafety; critical for understanding scoping rules and how the combinator model handles free variables
• Lambda Calculus & Combinatory Logic — Bend's desugaring strategy converts high-level syntax to combinators (SKI combinator calculus or similar); needed to understand IR generation and optimization
• SIMD & GPU Parallelism (CUDA/C) — Bend targets CUDA kernels and parallel C; understanding memory coalescing, warp scheduling, and kernel launch overhead helps predict performance on run-cu vs run
• Type Inference (Algorithm W) — Bend performs automatic type inference via src/fun/check/check_untyped.rs; understanding unification and constraint solving helps extend type system
• Pattern Matching Compilation — Bend supports rich pattern matching; the compiler must desugar patterns to decision trees and avoid exponential blowup—visible in docs/pattern-matching.md
• Tail Call Optimization (TCO) & Trampolining — Bend advertises 'unrestricted recursion'; implemented via combinator-based trampolining rather than stack frames—critical for understanding why deep recursion is safe

• HigherOrderCO/HVM2 — The interaction-combinator runtime that Bend compiles to; essential for understanding execution model and performance
• graydon/rust-learning — Not directly related, but Bend is written in Rust; learning Rust patterns helps contribute to Bend's compiler
• tweag/nickel — Similar-era functional language with type inference; comparative reference for syntax and compiler design choices
• hasura/graphql-engine — Uses HVM2 indirectly; ecosystem example of who adopts Bend/HVM2 for real workloads

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test suite for src/fun/parser.rs with snapshot testing

The parser is a critical component of the Bend compiler, but there's no dedicated test file visible in the repo structure. The project already has insta (snapshot testing framework) as a dev dependency, which is perfect for parser testing. This would catch regressions in syntax parsing, improve contributor confidence, and serve as executable documentation of parser behavior.

• [ ] Create tests/parser_tests.rs with snapshot tests using insta crate
• [ ] Test each language feature mentioned in docs/syntax.md (lambdas, pattern matching, definitions, etc.)
• [ ] Add tests for error cases and malformed input to ensure good error messages
• [ ] Reference existing .bend examples in examples/ directory as test cases
• [ ] Run cargo insta test --review to generate snapshots and commit them

Add integration tests for end-to-end compilation pipeline with src/fun/transform modules

The src/fun/transform/ directory contains several desugaring and optimization passes (desugar_bend.rs, desugar_fold.rs, desugar_match_defs.rs, etc.), but it's unclear if these transformations are tested together. Integration tests validating that transformations preserve semantics and produce correct output would prevent subtle bugs and regressions when modifying the compiler pipeline.

• [ ] Create tests/compilation_pipeline_tests.rs with tests for each transformation pass
• [ ] Test specific examples from examples/ (e.g., examples/fib.bend) compile correctly through all stages
• [ ] Add snapshot tests for intermediate IR representations at each transformation stage
• [ ] Verify that desugared code produces identical runtime results as original syntax
• [ ] Add edge case tests (deeply nested folds, complex pattern matches, etc.)

Create docs/troubleshooting.md with common compilation errors and debugging guide

The docs/ directory has thorough feature documentation but lacks a troubleshooting guide. Looking at src/fun/check/ (unbound_refs.rs, unbound_vars.rs, type_check.rs), the compiler clearly produces typed error messages, but new users likely hit these errors without understanding them. A troubleshooting guide would reduce friction, support issues, and duplicate questions.

• [ ] Create docs/troubleshooting.md with sections for common errors (unbound references, type mismatches, recursion issues)
• [ ] Document error messages from src/fun/check/type_check.rs and src/diagnostics.rs
• [ ] Add section explaining how to read compiler error output and what it means
• [ ] Include debugging tips for performance issues and parallelization gotchas
• [ ] Link to this guide from README.md and GUIDE.md

• Add snapshot tests for src/diagnostics.rs error messages. Currently no test files visible for diagnostic rendering; add tests/diagnostics_test.rs with Insta snapshots for common type errors (e.g., arity mismatch, undefined variable).
• Document the pattern-matching compilation strategy in docs/pattern-matching.md. The file exists but likely lacks examples showing how patterns desugar to nested conditionals and how to avoid exponential case blowup.
• Extend examples/ with a documented quicksort or tree traversal that showcases parallel recursion. Current examples (fib, sort, list) exist but lack inline comments explaining how HVM2 parallelizes the code versus sequential equivalents.

The Bend codebase demonstrates generally good security posture. As a compiler/language project, it has limited exposure to common web vulnerabilities (SQLi, XSS, etc.). The main security considerations are dependency management and the need for a responsible disclosure policy. The pinned HVM version should be monitored for security updates, and the Rust version requirement could be modernized. No hardcoded secrets, dangerous code patterns, or critical vulnerabilities were identified in the provided file structure analysis.

• Medium · Pinned HVM Dependency Version — Cargo.toml - hvm dependency. The HVM dependency is pinned to an exact version (=2.0.22) using the '=' operator. While this ensures reproducibility, it may prevent receiving security patches and bug fixes in future releases. Consider monitoring this dependency for security advisories. Fix: Periodically review HVM releases for security updates. Consider using '^2.0.22' to allow patch updates automatically, or regularly update to newer versions after security review.
• Low · Outdated Rust Version Requirement — Cargo.toml - rust-version field. The project specifies rust-version = '1.74', which may be older than current stable releases. Using older Rust versions could miss out on security improvements and bug fixes in the Rust standard library and tooling. Fix: Regularly update the minimum Rust version requirement to a more recent stable release to ensure users benefit from the latest security patches and language improvements.
• Low · Development Dependency Exclusion — Cargo.toml - dev-dependencies and exclude field. The Cargo.toml excludes the 'tests/' directory from the package, but dev-dependencies like 'insta', 'stdext', and 'walkdir' are still included. While dev-dependencies don't affect production builds, ensure they don't introduce unnecessary attack surface in development environments. Fix: Regularly audit dev-dependencies for security vulnerabilities. Use 'cargo audit' to identify known issues in both dependencies and dev-dependencies.
• Low · Missing Security.md or Security Policy — Repository root. No visible SECURITY.md or security policy file in the repository. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file following the GitHub security advisory guidelines (https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository) to establish a responsible disclosure process.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.