Chibi-Scheme for C application scripting and isolated VMs

What Chibi-Scheme Adds to a C Application

Chibi-Scheme is designed as an extension and scripting language for C programs, rather than as a general-purpose desktop Scheme environment. Its target user is a C developer who wants an application to accept Scheme code without adopting a large scripting platform. The README calls it a small library intended for that role and says it has no external dependencies, which can simplify linking into an existing project.

The runtime includes more than a basic evaluator. Its default settings provide a numeric tower with rational and complex numbers, Unicode support, low-level and high-level hygienic macros, and an extensible module system. The default REPL language contains the bindings from R7RS small, exposed through `(scheme small)`. This gives an application a recognizable Scheme interface while retaining control over the language included in a particular build.

Chibi-Scheme is an embeddable runtime, not a complete application framework. The README does not document editor integration, package publishing, deployment automation, or an administrative API for distributing scripts to end users. A C application still needs to define how users load scripts, how errors reach its interface, and how untrusted or partially trusted scripts are constrained. Those host concerns sit outside the library's stated purpose.

Isolated VM Heaps and Operating-System Threads

The central architectural feature is the separation between the runtime library and each Scheme virtual machine. According to the README, lightweight VM-based threads are supported, and each VM runs in an isolated heap. Multiple VMs can run simultaneously in different operating-system threads. That model is relevant to applications that need independent script contexts rather than sharing one evaluator and heap.

Based on the repository layout, the implementation includes C sources for evaluation, the virtual machine, garbage collection, heap management, numeric operations, and s-expression handling. The build produces the `libchibi-scheme` shared library and a sample `chibi-scheme` command-line REPL. The Makefile also lists libraries for filesystems, weak references, networking, heap statistics, disassembly, AST handling, JSON, Emscripten support, input and output, processes, time, system access, PTYs, threads, cryptography, and optimization. Those component names do not by themselves establish that every library should be included in a minimal production deployment.

The module system is part of the runtime rather than an external package manager. The default language includes R7RS small bindings, while the layer-based build permits smaller configurations. The README points to the manual for exact startup and compilation options. It does not specify the complete C embedding API, host-data ownership rules, or the precise thread-safety contract for objects shared across VM boundaries, so those details must be checked before designing concurrent integrations.

Building Chibi-Scheme and Running Its Test Suite

The normal build assumes GNU make on most platforms. The README identifies this sequence as the first verification step. It builds the runtime and invokes the included tests, giving a new user a project-level check before installing anything. The documented command is:

make && make test

The build should produce the `libchibi-scheme` shared library and a sample `chibi-scheme` command-line REPL. To use the REPL before installation, the README says to configure the dynamic-library search path. Use `LD_LIBRARY_PATH` on Linux and similar systems, or `DYLD_LIBRARY_PATH` on macOS. The project does not document the complete native Windows desktop procedure in the main README, so Windows developers should follow `README-win32.md` rather than assume the Unix commands apply.

The default installation prefix is `/usr/local`. The documented installation command is:

sudo make install

For a different directory, the README provides these forms:

make PREFIX=/path/to/install/
sudo make PREFIX=/path/to/install/ install

The first command builds with the selected prefix, and the second installs into it. The Emscripten build uses `make js`, not `emmake make js`. A first practical use is therefore to build, run the tests, and launch the sample REPL before installing it. The repository also contains `examples/hello.scm` and networking examples, but the README does not print their source or command-line invocations.

R7RS Bindings and Configurable Language Layers

Chibi-Scheme combines a compact runtime with a substantial default Scheme language. The README says the REPL includes all bindings from R7RS small, while the implementation also covers rational numbers, complex numbers, Unicode, hygienic macros, and modules. This lets a host application expose a capable scripting environment without requiring the library to carry every possible Scheme extension by default.

Some boundaries still require inspection. The README identifies Unicode support and both low-level and high-level hygienic macros, but it does not enumerate encoding APIs, normalization behavior, or compatibility with a specific macro implementation. Scripts that depend on these details should consult the generated `doc/chibi.html` or the online manual rather than infer exact semantics from the feature list.

The Makefile contains a `FEATURES` variable, and the README directs users to the manual for compiling with fewer features or requesting a smaller language at startup. This configurability is useful for constrained deployments. However, the README does not quantify the binary size, memory use, or compatibility impact of individual features. A host application should therefore choose its required language layer explicitly instead of treating the default as a fixed ABI or behavior contract.

Platform Boundaries, Release Changes, and the Custom Licence

Chibi-Scheme's small footprint does not remove platform constraints. The README lists 32-bit and 64-bit Linux, FreeBSD, NetBSD, OpenBSD, DragonFlyBSD, OS X, Plan 9, Windows, iOS, Android, ARM, and Emscripten. Native Windows desktop support receives separate discussion in `README-win32.md`. A target not covered by those statements needs direct examination of its build files, particularly `Makefile.detect` when using a make implementation other than GNU make.

The repository uses a custom licence that GitHub classifies as `Other`. The licence text is in the `LICENSE` file. The README does not summarize redistribution conditions, linking obligations, modification terms, or warranty language, so those points cannot be inferred from the repository category. This is an adoption gate for a C library intended to ship inside another product, not a cosmetic metadata issue.

Release 0.12 was published on 2026-03-18, following release 0.11 on 2024-10-31. The last push was on 2026-10-12, so the repository shows recent development. The README and release list do not provide a migration guide, compatibility matrix, or rollback procedure for embedded applications. Version selection should therefore be tied to the host's supported C toolchain and a review of changes between the versions being used.

Chibi-Scheme Versus an Existing or Larger Runtime

The practical alternative is to use a scripting facility already supplied by the host platform or a larger, separately packaged Scheme runtime. The difference in approach is specific. Chibi-Scheme offers a small C library, an explicit VM model, and an isolated heap for each VM. A larger runtime may be selected when a product needs broader distribution tooling, a conventional installation experience, or documented language coverage beyond what this repository describes. The repository overview names no specific alternative, so it cannot support a product-by-product comparison.

For a C product whose scripting subsystem needs compact code and independent VM heaps, Chibi-Scheme's design is a direct fit. Replacing an existing engine, however, creates migration work around loading, errors, native bindings, and deployment. The README does not provide a host embedding example or native API reference. For a standalone Scheme user focused on development tooling, the sample REPL may also be less relevant than an environment with documented package and editor integration.

An initial integration check should focus on shared-library loading, VM creation, script loading, and cleanup. The next check should cover the language features used by real scripts. Finally, read `COPYING` and the manual sections for modules and threading. These are project-specific checks because they correspond directly to the library architecture, build output, and licence files in the repository.

Editorial conclusion

C applications that need a compact Scheme runtime can adopt Chibi-Scheme when its isolated VM heaps and module model fit the design. Projects needing a conventional licence classification or undocumented host-platform behavior should look elsewhere first. Before integration, inspect `COPYING`, follow the relevant platform instructions, and verify shared-library loading in the host executable.

Frequently asked questions

Official sources

1. ashinn/chibi-scheme on GitHub
2. Issues
3. README
4. Releases