ultimatehaider/plantlang

Purpose and entry points

PlantLang—Chloroplast is a self-hosted native compiler toolchain. It translates .plant source into C, then relies on GCC plus a C runtime to create executables. The user-facing compiler is bin/Chloroplast; the immutable bootstrap compiler is dist/Chloroplast. Compiler CLI behavior and compilation orchestration originate in src/plantc/main.plant.

Self-hosting build chain

The repository’s central control flow is bootstrap → compile compiler sources → link native compiler → repeat generations and compare artifacts for convergence. Makefile owns this build and self-hosting verification boundary; generated/intermediate compiler generations live under build/, while release-like executable outputs are under bin/ and dist/. Required build infrastructure is local make and gcc; no VM or JavaScript runtime is involved.

Paths: Makefile, dist/Chloroplast, build/plantc_all.plant.

Front end: lexical and syntactic lowering

The compiler is itself PlantLang source. The lexer turns source text into tokens, and the parser constructs/interprets the language’s syntax and AST-level representation, including declarations, control flow, module imports, types, generics, closures, async constructs, and FFI declarations. Parse failures form the primary source-language diagnostic boundary before C emission.

Paths: src/plantc/lexer.plant, src/plantc/parser.plant, src/plantc/main.plant.

C code generation

The code generator maps PlantLang semantics to standalone C: native actions, data shapes/classes/unions, generic monomorphizations, closure environment/function pairs, cooperative async state machines, exception machinery, and external C declarations/calls. Generated C is the boundary between language implementation and platform compiler/linker; it includes or targets runtime APIs rather than embedding their implementation.

Paths: src/plantc/codegen_c.plant, src/plantc/main.plant.

Native runtime and memory model

The compiled program links against a lightweight C runtime that supplies PlantLang’s operational substrate: core value/container/string facilities, deterministic scope-oriented arena allocation, exception/control support, async scheduling/draining, and native service integrations. Runtime headers define the ABI and compatibility/type layer used by generated C. Programs compile with the runtime source and -lm.

Paths: runtime/c/plant_runtime.c, runtime/c/plant_runtime.h, runtime/c/plant_types.h.

External integration boundary

PlantLang code can call native C through declared externals, including reference values, structs, callbacks, varargs, handles, and error reporting. The runtime also exposes built-in native services such as filesystem, JSON, time, math, strings, and collections. Network/server and filesystem behavior is implemented as native capabilities invoked by compiled programs, not as repository-hosted services.

Paths: runtime/c/plant_compat.h, runtime/c/plant_runtime.h, src/plantc/codegen_c.plant.

Verification and executable lifecycle

The primary validation model is compile-and-run native integration coverage: test programs are compiled by Chloroplast, linked to the runtime, and compared with expected outputs. Suites specifically exercise language regressions, FFI/runtime behavior, generics, closures, async, persistence/memory, and performance. Examples provide direct source inputs for the same compiler-to-C-to-native lifecycle.

Paths: tests/regression/run_regression_tests.sh, tests/native/run_native_tests.sh, examples/hello.plant.