accept-loop calls the accept-conn syscall word. Your connection is accepted. The request is read into a Forth-allocated buffer.
You're looking at a web server written in Forth, running on verified LLVM IR capabilities, bootstrapped by 100 lines of C. The page you're reading was served by the system it describes.
Every HTTP request that hits this server passes through exactly three layers. Each layer does one job and nothing else.
catalog.conf are compiled in. Each one synthesized from intent, validated against test cases, compiled to machine code.
accept-loop calls the accept-conn syscall word. Your connection is accepted. The request is read into a Forth-allocated buffer.
string_index_of_char capability to find the space delimiter, then copy_bytes to isolate the path.
find-route looks up "/how-it-works" in the Forth dictionary. It finds the word /how-it-works and executes it. The route word calls serve-file with the filename.
serve-file calls the verified build_file_path capability (which itself composes string_copy + string_concat) to construct "server/pages/how-it-works.html", then reads it with Forth's read-file word.
http_build_response capability assembles the HTTP response: status line, Content-Type header, Content-Length, Connection: close, blank line, body. One capability call, 10/10 test cases.
write-fd syscall word sends the response. Connection closed. Back to step 1.
This is the actual route that served this page:
Two lines. The route word is looked up in the Forth dictionary by find-route, which uses Ficl's dictLookup — a hash table search, not string comparison. Adding a new route is one line of Forth.
Here's serve-file, the word that does the actual work:
Every blue word is either a Forth primitive or a verified LLVM IR capability. build_file_path and string_copy are verified capabilities. read-file is a Forth word composed from syscall primitives (open-rd, fstat-size, read-fd, close-fd).
This server uses 7 verified capabilities from the Method Dictionary. Each was synthesized from a natural language intent, validated against test cases, and compiled to native machine code.
build_file_path is a composite — its LLVM IR declares and calls string_copy and string_concat. The Semantic Compiler verified all three together. Capabilities compose like functions, but every composition is independently verified.
This website doesn't have its own C program. It runs on the generic Semcom Runner — 100 lines of C that can execute any Forth program with access to the full capability library.
SEMCOM_LIB=native/libsemcom.dylib \ SEMCOM_MANIFEST=native/semcom_caps.manifest \ ./semcom-runner projects/website/routes.fth 8080
The runner provides three things and nothing else:
Loads the capabilities declared in catalog.conf and registers them as Forth words. In production, capabilities are statically linked — no dynamic loading, no dlsym, no shared libraries.
9 words that touch the OS: open-rd, read-fd, write-fd, close-fd, fstat-size, tcp-listen, accept-conn, find-route, z". The complete syscall surface.
A CLI calculator, an API server, a data pipeline, this website — they're all just different .fth files run by the same 100-line bootstrap. The Forth program IS the application. The runner is the platform.
Millions of lines of C/C++/Go. Thousands of dependencies. CVEs measured in hundreds per year. You trust the framework, the runtime, the OS, the package manager, and every transitive dependency.
122 lines of Forth. 100 lines of C. 7 verified capabilities. 115KB static binary. Every computation has test evidence. The entire server logic fits on a single screen. You can read all of it.
This isn't a toy. You loaded this page from it. The HTML you're reading right now was served by 121 lines of Forth dispatching onto verified LLVM IR. The server parsed your HTTP request, looked up the route, read the file, built the response, and sent it back — and every computation along the way was either a verified capability or a Forth word you can inspect.
That's the Semantic Compiler thesis: intent in, verified machine code out, nothing else in the stack.