SchOS/docs/plan/finch.md

Finch, for SchOS's own programs

Later. Not being worked on — it is behind 1.0.md's freeze like everything else here that is not named there. This records the decision so it is not rediscovered.

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 -O2 pipeline 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" plus link "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 in src/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,000 for the C++ one in src/) that builds itself to a byte-identical result — tests/boot.sh.

What SchOS would need to do

1. A schos target. finch picks 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 existing x86_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.
2. 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.
3. boot/ as the SchOS-hosted compiler. The C++ compiler needs LLVM's C++ libraries; the one in boot/ 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.
4. Bindings for SchOS's own interfaces (/dev/pci, /dev/netdev, schinit's job protocol, the framebuffer) — generated by the C importer from the headers in include/uapi/, so they are not hand-written and cannot drift from the kernel.

What "finishing Finch" means is not settled

The repository has no list of what is unfinished. Before work starts, the author names it. Candidates seen in the tree: note.txt and notatka.txt are scratch files; OpenGL.fn was deleted in the last commit; the boot/ compiler is shorter than the C++ one, so some language features may exist only in the latter. The first task is to diff the two feature sets, not to guess.

Rules

• Nothing in the kernel is rewritten in Finch. It is for applications and tools.
• No new capability starts until the register of unfinished work is empty; this document is a plan, not an exception to that.