- runtime/stdlib.el: master import file for the full El standard library in correct dependency order (string→math→time→env→fs→exec→json→http→ state→thread→channel→engram→manifest); test.el excluded (dev-only) - tools/install.sh: installs El to a prefix (default /usr/local/el); copies elc binary, runtime .el files, headers, compiles libel.a from el_seed.c + el_runtime.c, generates an installed stdlib.el with absolute paths - tools/new-project.sh: scaffolds a new El project with src/main.el, build.sh (auto-discovers local elc/runtime), README.md, .gitignore; verified working end-to-end - AGENTS.md: fix elc rebuild docs — elc writes to stdout, not to its second argument; correct usage is ./dist/platform/elc elc-cli.el > elc-new.c
4.6 KiB
El Language — Agent Guide
El is a self-hosting, statically-typed language that compiles to C. This file orients agents that work on El itself or on programs written in El.
What El Is
El compiles .el source → C → native binary. Every El value is el_val_t (int64_t). Strings are heap pointers cast through int64_t. The compiler is written in El (self-hosting).
The compiler pipeline:
elc-cli.el
└─ imports: compiler.el
└─ imports: lexer.el, parser.el, codegen.el, codegen-js.el
The canonical compiler binary is dist/platform/elc. It was produced by running an earlier version of itself on elc-cli.el.
The Two Layers — Know Which One You're In
Layer 1: El programs (.el files)
This is where almost all work belongs. El programs are source files that get compiled by elc. New library functions, application logic, and language-level utilities all go here as .el files.
Do not add C code when El can express it. If functionality can be built from existing El primitives (string ops, exec, fs_read/write, http_post, etc.), write it in El.
Layer 2: The C runtime (el-compiler/runtime/el_runtime.c)
This is the hand-written C layer that provides El's native built-in primitives: libcurl HTTP, pthreads server, filesystem I/O, JSON parsing, engram graph store, etc. It is not generated — it is maintained by hand.
Only edit el_runtime.c when you genuinely need OS-level access (raw sockets, GPU calls, new libcurl features). For everything else, write El.
When you do add a C builtin:
- Add the C function to
el_runtime.c - Declare it in
el_runtime.h - Add it to the
builtin_aritytable inel-compiler/src/codegen.el(so the compiler knows the arg count) - Rebuild the elc binary (see below)
Rebuilding the Compiler
After changing any .el source in el-compiler/src/:
cd /Users/will/Development/neuron-technologies/foundation/el
./dist/platform/elc elc-cli.el > elc-new.c
cc -std=c11 -I el-compiler/runtime -lcurl -lpthread \
-o dist/platform/elc-new \
elc-new.c el-compiler/runtime/el_runtime.c
# Verify self-hosting:
./dist/platform/elc-new elc-cli.el > elc-verify.c
diff elc-new.c elc-verify.c # should be identical
mv dist/platform/elc-new dist/platform/elc
After changing el_runtime.c only (no El source changes), rebuild downstream programs but do NOT need to rebuild the compiler binary itself — the runtime is linked at the application level, not the compiler level.
How El Programs Are Built
Each El application has a build.sh that:
- Concatenates all
.elsource files (strippingimportlines) - Runs
elcto produce a.cfile - Runs
cclinking againstel_runtime.c
Example (cgi-studio daemon):
cd products/cgi-studio/el-daemon
./build.sh
When you add a new .el file to an application, add it to that application's build.sh concat list.
Parallelism in El
El is single-threaded at the application level. Parallelism is achieved through subprocess fan-out:
// Pattern: write payloads to temp files, exec bash script with & and wait,
// read results back from temp files.
fn http_post_parallel(urls: [String], bodies: [String]) -> [String] {
// ... bash fan-out via exec() ...
}
Use exec() (blocking) or exec_bg() (fire-and-forget) with shell scripts to run concurrent work. There is no goroutine or async/await — parallelism goes through the OS process layer.
Key Files
| Path | What it is |
|---|---|
dist/platform/elc |
Canonical compiler binary (arm64 Mac) |
el-compiler/src/codegen.el |
Code generator — builtin arity table lives here |
el-compiler/src/lexer.el |
Lexer |
el-compiler/src/parser.el |
Parser |
el-compiler/runtime/el_runtime.c |
Hand-written C runtime (native builtins) |
el-compiler/runtime/el_runtime.h |
Runtime header (C function declarations) |
spec/language.md |
Language specification |
BOOTSTRAP.md |
How to recover the compiler from scratch |
elc-cli.el |
Compiler entry point |
elc-combined.el |
Pre-merged single-file compiler (used during early bootstrap) |
HTTP Timeout
The El HTTP client (libcurl) defaults to 60 seconds. Override per-process via EL_HTTP_TIMEOUT_MS env var. Set it before spawning any subprocess that makes long API calls:
exec("EL_HTTP_TIMEOUT_MS=300000 " + SOME_BIN + " " + args + " 2>&1")
Rules
- New library functions → write in El
- New OS/hardware primitives → write in C and register in
codegen.elarity table - Never edit
dist/platform/elcdirectly — always rebuild from source - Never modify
el_runtime.cto add functionality that El can express