# 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](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](#the-self-hosting-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 `-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,900 for the C++ one in `src/`, language server included) 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](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.

## 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](1.0.md#the-freeze-and-the-register-of-unfinished-work)
  is empty; the SchOS half of this document is a plan, not an exception to that.