Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015f73FesGZGYPkmDvUcj6QX
4.7 KiB
Finch, for SchOS's own programs
Two things, and only one of them is later.
- Bringing Finch into SchOS (below) is later — behind 1.0.md's freeze like everything else here that is not named there.
- Finishing Finch itself, and making it fully self-hosting, is work on the Finch repository and does not touch this tree. It can proceed now; see the gap.
Finch is the author's own language: https://pandor.pl/git/nexoniarz/Finch
(GitHub mirror: Nexoniarz/Finch). The plan is to write SchOS's own
applications and tools in it, in place of C, and so leave behind what C does
badly: silent narrowing, signed/unsigned mixing, undefined behaviour on an
out-of-range index, a forgotten free.
What it is today (version 2.4.0)
Measured from the repository, not from its README alone:
- LLVM front end, C-like syntax, no semicolons, no headers, no preprocessor.
It compiles through LLVM's
-O2pipeline to native code; there is no garbage collector. - Values, not references: lists, text and structs copy on assignment and are freed at the end of their block. Out-of-range indexes, division by zero and null pointers stop with a runtime error rather than undefined behaviour.
- Errors as values (
int(s) or 0,try read_file(p)), maps, methods, modules. - C interop through libclang:
import "foo.h"pluslink "foo"calls any C library, structs by value and callbacks included. That is the way in to everything SchOS already has — musl, the/dev/*interfaces, Alpine's libraries. - Targets: Linux, macOS, Windows, on x86-64 and ARM64 (
src/target.cpp; the System V, AAPCS64 and Microsoft x64 ABIs are insrc/abi.cpp). - Tooling: a language server (
finch lsp), VS Code and Kate support, 74 tests. - Self-hosting:
boot/is a Finch compiler written in Finch (about 3,100 lines, against about 5,900 for the C++ one insrc/, language server included) that builds itself to a byte-identical result —tests/boot.sh.
What SchOS would need to do
- A
schostarget.finchpicks a triple, a C compiler and a linker per target. SchOS runs unmodified Alpine binaries and Alpine's musl (see alpine.md), so the first target is the existingx86_64-unknown-linux-musl, and a Finch program built on the host should run on SchOS before anything in Finch is made SchOS-specific. Test that before writing a line of target code. - The compiler on SchOS. Needs LLVM 21 and libclang, both of which Alpine packages. That is a question of apk and memory, not of SchOS.
boot/as the SchOS-hosted compiler. The C++ compiler needs LLVM's C++ libraries; the one inboot/is the candidate for being the compiler that ships in the image, once it emits through LLVM's C API or a smaller back end.- Bindings for SchOS's own interfaces (
/dev/pci,/dev/netdev, schinit's job protocol, the framebuffer) — generated by the C importer from the headers ininclude/uapi/, so they are not hand-written and cannot drift from the kernel.
Where self-hosting stands
The Finch compiler written in Finch (boot/) now builds itself: stage 2 and
stage 3 are byte-identical (58,660 lines of LLVM IR), and it passes all 22 of
the repository's run tests (the C++ one passes 77/77). The work is on the
finish-finch branch of github.com/Nexoniarz/Finch; before-bootstrap there
is the all-C++ compiler, kept as the backup. main is untouched.
What the self-hosted compiler has: sized numbers, methods, defer, errors as
values, maps, for k, v in, C import through libclang (written in Finch, in
boot/cimport.fch), C structs by value and addr(fn) callbacks (System V
x86-64), run, build, ir, version, -O0, -l, -I.
What it does not have yet, and the C++ compiler does:
-g debug info |
text IR needs the DWARF metadata written by hand |
--target (Windows, ARM64, macOS) |
their struct-passing rules (abi.cpp) and linkers |
lsp, the editor language server |
lsp.cpp, 580 lines |
export fn, build --shared |
on the author's local embed branch |
main becomes the Finch-written compiler when those are in, so that
nothing a user does today stops working; until then it is the seed that builds
the first stage. The new language features (enums, match, generics, a
standard library) come before that switch, as simple as the rest of the language.
Rules
- Inference, not an instruction: the kernel stays in C. Finch is for applications and tools; the user said "our apps or stuff like that".
- No new capability starts until the register of unfinished work is empty; the SchOS half of this document is a plan, not an exception to that.