lamb

Here's a concise technical briefing for the lamb repository, written to consultant standards.

The Problem

Lamb is a minimal functional language interpreter written in C with no test suite, no CI pipeline, and no build automation. For a team evaluating it as a runtime or embedding candidate, the absence of automated quality gates means every change risks untested behavioral drift. The single lamb.c file (1139 lines) carries the entire language implementation, parser, evaluator, and REPL — a cognitive load risk for any team relying on it long-term.

What This Does

Lamb implements a pure functional programming language in a single C file (lamb.c), based on the untyped lambda calculus with normal-order reduction. The entry point is main() in lamb.c, which parses REPL input or a .lamb source file, evaluates abstract syntax trees via a reduction loop, and prints results. Standard library definitions live in std.lamb and are loaded at runtime. The interpreter supports function application, let-bindings, #trace and #void magics for debugging, and a minimal REPL loop. There are no external dependencies — compile with cc -o lamb lamb.c and run ./lamb ./std.lamb. The language has no type system, no module system, and no separate compilation model — it is a single-translation-unit interpreter.

How It Is Wired

Execution flows through a single file: lamb.c. The main() function initializes the environment, loads std.lamb if provided, then enters a read-eval-print loop. The parser (parse()) converts user input into an AST, which is then reduced by the reduce() function applying normal-order beta reduction. The evaluator handles variable lookup, abstraction, and application. The #trace and #void magics are implemented as special forms that intercept reduction to print intermediate terms. No OS-level effects beyond I/O and exit occur. The std.lamb file defines primitive terms (cons, car, cdr, nil, etc.) and the tracing utility trace_list. There are no external libraries, no config files, and no environment variables — the entire behavior is self-contained in the C source and the single stdlib file.

How To Use It

Build:

$ cc -o lamb lamb.c

Run:

$ ./lamb ./std.lamb

For a REPL with history, use rlwrap:

$ rlwrap ./lamb

No environment variables or configuration files are required.

Real-World Use

Lamb is suitable as a learning toy or a minimal embedding target for researchers prototyping lambda-calculus transformations. Its single-file C implementation makes it easy to drop into a larger C project and call the parse/reduce functions directly. However, the lack of a type system, test coverage, or configurability means it is not production-grade software. A team could use it to prototype a DSL compiler front-end or teach lambda-calculus semantics, but any production use would require forking, adding serialization, type checking, and error handling.

Code Health & Issues

• MEDIUM - cognitive load: lamb.c has max indentation depth 7 and 1139 lines of code — control flow is hard to follow and a single change ripples widely.
• MEDIUM - cognitive load: No test files detected; untested code paths across the entire interpreter.
• LOW - clarity: 11 TODO/FIXME markers remain unresolved in lamb.c.

SDLC observations: No CI/CD pipeline, no Dockerfile, no lockfile. A license file is present (LICENSE).

The Bottom Line

Lamb is a small, self-contained C interpreter for the untyped lambda calculus. It works, the syntax is documented, and the code is readable for a functional programming enthusiast. However, the single-file architecture, absence of tests, and no build/ CI infrastructure make it unsuitable as a dependency or runtime for any team that values reproducibility and maintainability. Use it for prototyping or education, not for production systems.

Static analysis detected 3 findings across 2 severity levels in lamb.c. No automated test or CI configuration was found in the repository.