Compiler & contributing

The E# compiler — the lexer, binder, the Mono.Cecil IL backend, the C# transpiler, and the standard library (stdlib) — is the language. While E# is in active development, that source lives in a private repository. The surface still moves week to week, and keeping the compiler private during this phase lets the design change without breaking people who’d otherwise be building against a moving target.

What is public is the corpus: a large, growing set of .es programs drawn straight from the language’s own test suite and samples — including integration tests, some of them sizeable multi-file programs. These are not illustrative sketches; they’re the exact programs the compiler is held to.

Every entry is one of three things: a passing test case, a sample or integration test, or a compilable program that builds to a real executable. Each one earns its place:

• It compiles cleanly — or, for the negative cases, fails with exactly the expected error or diagnostic (deliberate ill-formed syntax exists in the corpus precisely to pin down what the compiler must reject, and it’s verified as rejected the right way).
• It produces its expected output — a positive test asserts a known-good result, so the program’s behaviour is verified, not just its compilation — or, where there’s no asserted output, it’s verified to be a real, well-formed program rather than filler or accidental garbage.

The corpus is the compiler’s actual contract, made public. It’s public precisely because it’s the easy thing to make public — no build secrets, no in-flight design, no half-finished backend. The compiler that produces it is the part still under the knife.

Requesting access

If you’d like to read or build the compiler, message me on GitHub — @khayzz13 — and I’ll send you access. There’s no form and no waitlist; it’s a private repo, not a closed one. Researchers, prospective contributors, and the merely curious are all welcome to ask.

Contributing — soon, and tests first

I would love contributors. As the project opens up, the first and most valuable contribution will be tests — .es programs that exercise corners of the language, pin down behaviour, and grow the corpus that the whole specification is anchored to. The corpus is the contract; every test that lands makes the contract sharper.

The plan is to set up a clear path for people to generate and submit tests, and — importantly — to keep contributed tests in a separate folder that remains the contributor’s own copyrighted work, cleanly partitioned from the core compiler maintenance and the work I do on the language itself. Your tests stay yours; they ride alongside the project without being absorbed into it. That separation is the point: it keeps contribution low-friction and unambiguous about ownership.

Compiler-internals contribution — the binder, the IL emitter, diagnostics — will follow once the test-contribution path is established and the surface settles. For now, if you want to help, the best way is to ask for access, write programs, and break things.