Forem: Roman Melnikov

The 2,600-Line Compiler That Compiles Itself and Emits F#, TypeScript, Python, Java, and C#

Roman Melnikov — Mon, 18 May 2026 09:34:34 +0000

The 2,600-Line Compiler That Compiles Itself and Emits F#, TypeScript, Python, Java, and C

ll-lang started as a language for LLM code generation. The more interesting update now is not the syntax pitch. It is the compiler story: the compiler is written in ll-lang itself, the bootstrap reached a fixpoint, and the same source can emit several host targets.

That gives the project two concrete proofs:

compiler₁.fs == compiler₂.fs
one source language can emit F#, TypeScript, Python, Java, C#, and an experimental LLVM backend

That combination moves ll-lang out of the "interesting syntax demo" category.

Why the self-hosting milestone matters

A lot of language projects can parse a toy file. Fewer can move their own compiler into the language they are building.

The ll-lang repo now documents bootstrap as complete. The canonical compiler lives in the self-hosted path, while archived stage0 code stays under obsolete/stage0 only for recovery diagnostics. The README makes the claim explicit: compiler₁.fs == compiler₂.fs.

That fixpoint matters because it means the compiler output stabilizes under its own pipeline. It is not just "the compiler can probably compile itself." It is "the compiler compiles itself, and the emitted artifact stops changing."

For a project aimed at LLM workflows, that matters even more. The promise is not just smaller syntax. The promise is a closed, testable toolchain.

The bootstrap path

The documented bootstrap path is intentionally simple:

git clone https://github.com/Neftedollar/ll-lang.git
cd ll-lang
./tools/bootstrap-self.sh install
BOOTSTRAP_BIN="$(./tools/bootstrap-self.sh path)"
"$BOOTSTRAP_BIN" check "$PWD/lllcself/src/Main.lll"

The pinned artifact is verified against bootstrap/lllc-bootstrap.lock.json, so bootstrap does not depend on a lucky local setup. On success the compiler reports OK and exits 0.

There is also a strict launcher:

./tools/lllc-bootstrap.sh check "$PWD/lllcself/src/Main.lll"

That wrapper runs the pinned bootstrap path directly instead of silently falling back to older bridge behavior.

The multi-target path

Self-hosting is only half the story. A compiler that only proves it can emit itself is interesting to compiler people. A compiler that can also target multiple ecosystems is easier for application teams to try.

ll-lang exposes that through the same CLI surface:

lllc build --target fs   shapes.lll
lllc build --target ts   shapes.lll
lllc build --target py   shapes.lll
lllc build --target java shapes.lll
lllc build --target cs   shapes.lll
lllc build --target llvm shapes.lll

The repository tutorial shows the same algebraic data type mapped into several host languages:

F# discriminated unions
TypeScript tagged unions
Python @dataclass + pattern matching
Java 21 sealed interfaces + records
C# records

That is the practical angle. The source language stays compact for prompt-driven authoring, while the output lands in ecosystems teams already run in production.

One source, multiple outputs

The multi-target tutorial uses a simple source shape:

module Shapes

Shape = Circle Float | Rect Float Float | Empty

area(s Shape) Float =
  | Circle r  -> 3.14159 * r * r
  | Rect w h  -> w * h
  | Empty     -> 0.0

From there, ll-lang emits target-specific code instead of flattening everything to one runtime model. That is what good cross-target compilers do: preserve the source idea while producing code that still looks native enough for the host ecosystem.

What I would try first

If you want the fastest way to evaluate the project:

Read the README bootstrap section.
Open lllcself/src/Main.lll to see that the compiler entrypoint is in ll-lang.
Read docs/tutorials/04-multi-target.md and compare the emitted TypeScript, Python, and Java shapes.
Run the bootstrap installer on a clean machine.

That sequence shows both halves of the project without requiring a deep compiler-internals read first.

Why this matters for LLM workflows

The original thesis behind ll-lang is that a smaller, statically checked syntax reduces noise in prompts and makes diagnostics machine-readable. The built-in MCP server ships with the toolchain for agent use.

What changed is that the implementation now backs up the thesis. The compiler is self-hosting. The stdlib is self-hosted. The project system is real. The codegen path is not locked to one runtime.

That is a stronger story than "language for LLMs." It is a claim with compiler evidence behind it.

What the line count actually is

The self-hosted compiler CLI under lllcself/src/ is 2589 lines today. So "about 2600 lines" is the accurate version of the headline, even if "under 3000 lines" is the broader takeaway.

What this milestone does not mean

It does not mean every part of the stack is finished forever. The repo is explicit that llvm is still experimental, and that some self-host routing work is still documented as controlled rollout. That is a positive signal, not a weakness. Compiler projects get more trustworthy when they mark their edges clearly.

The short version

The easy headline for ll-lang would be "a typed language for LLMs."

The better headline now is narrower and more technical:

ll-lang reached a self-hosting bootstrap fixpoint, and the same language can already emit multiple mainstream targets.

That is the kind of milestone that turns a positioning story into an implementation story.

GitHub: https://github.com/Neftedollar/ll-lang
Landing page: https://neftedollar.com/ll-lang/
Earlier intro post: https://dev.to/neftedollar/why-we-built-ll-lang-a-statically-typed-functional-language-for-llms-2hg8

Wire ll-lang into Claude Code, Cursor, or Zed in 30 Seconds

Roman Melnikov — Sun, 26 Apr 2026 21:34:45 +0000

Wire ll-lang into Claude Code, Cursor, or Zed in 30 Seconds

If you want an LLM to write ll-lang productively, the best setup is not "open a terminal and hope the model can parse shell output." The better setup is MCP.

ll-lang ships with a built-in MCP server through lllc mcp, so your editor can call the compiler and project tooling as structured tools.

That means your agent can ask questions like:

does this compile?
what does E005 mean?
where is this symbol defined?
what targets can I build to?

And get structured JSON back instead of scraped terminal text.

1. Add the MCP server

Use the current config shape from the ll-lang README and MCP user guide:

{
  "mcpServers": {
    "ll-lang": {
      "command": "lllc",
      "args": ["mcp"]
    }
  }
}

If lllc is not on your $PATH, replace command with the absolute path to the binary. In a local repo checkout, you can also point to the bootstrap wrapper if that is your preferred install path.

Typical locations:

Claude Code: ~/.config/claude/mcp.json
Cursor: project .cursor/mcp.json or equivalent MCP settings path
Zed: your MCP server settings file

The important part is the command itself: lllc mcp.
The MCP server name is up to you. The README currently shows lllc; the MCP guide shows ll-lang.

2. Restart the client and confirm the server appears

Once the client reloads MCP servers, ll-lang should show up as an available tool provider.

At that point your agent can call ll-lang directly instead of inferring behavior from shell commands.

3. What tools you get

The current README and docs/user-guide/09-mcp.md document 30 tools. They cover the workflow you actually want in an AI coding loop:

Core compile/check: compile_source, check_source, compile_file, check_file
Diagnostics and repair: diagnose_source, diagnose_file, explain_error, fix_suggest, apply_fix_preview
Formatting and AST inspection: format_source, format_file, parse_source, typed_ast
Project-level operations: project_graph, check_project, build_project
Symbol navigation: symbols, definition, references
Dependency helpers: mod_add, mod_tidy, mod_why
FFI helpers: ffi_inspect, ffi_validate
Test helpers: test_list, test_run
Catalog/meta: stdlib_search, list_errors, lookup_error, list_targets

That is enough for a serious inner loop. The model does not just "write code"; it can inspect the project, ask for diagnostics, search the stdlib, and repair errors with structured feedback.

4. The shortest useful workflow

Once MCP is wired in, the productive loop is simple:

Ask the model to draft a small ll-lang module.
Call check_source or check_file.
If an error comes back, call lookup_error or explain_error.
Apply the fix and re-run check_source.
When clean, use build_project or compile_file.

That loop is much tighter than:

write -> run shell command -> inspect mixed stdout/stderr -> guess what failed

5. Why this setup matters

ll-lang is designed for LLM code generation, so the compiler output is part of the authoring experience, not just a final gate.

Examples:

E005 TagViolation tells the agent it passed an untagged value where a tagged value was required.
E004 UnitMismatch tells it incompatible units met in arithmetic.
lookup_error can turn an error code into a short explanation without making the model search docs manually.

Because the protocol is structured, the model can route on exact fields instead of trying to interpret prose or terminal formatting.

6. Minimal prompt to test it

After MCP is connected, try this:

Create a small ll-lang module with tag UserId, a function that accepts Str[UserId], and then check whether it compiles. If it fails, fix it using the ll-lang MCP tools.

If the wiring is correct, the model should use ll-lang tools directly rather than defaulting to shell output parsing.

7. Install and repo links

Repo: https://github.com/Neftedollar/ll-lang
Landing page: https://neftedollar.com/ll-lang/

Bootstrap path from the README:

git clone https://github.com/Neftedollar/ll-lang.git
cd ll-lang
LLLC_BOOTSTRAP_REINSTALL=1 ./tools/check-selfhost-ci.sh

Then keep the MCP config in place:

{
  "mcpServers": {
    "ll-lang": {
      "command": "lllc",
      "args": ["mcp"]
    }
  }
}

Why We Built ll-lang, a Statically Typed Functional Language for LLMs

Roman Melnikov — Sun, 26 Apr 2026 21:34:34 +0000

Why We Built a Statically Typed Functional Language for LLMs to Write

ll-lang is a language for one narrow, practical job: helping LLMs generate correct code faster by spending fewer tokens on syntax and getting compile-time feedback instead of runtime surprises.

The problem with "AI coding" is not that models cannot produce code. They clearly can. The problem is that most mainstream languages give them the wrong feedback loop.

When an LLM writes Python, TypeScript, or Java, two things usually happen at the same time.

First, the model burns a lot of context on syntax that does not carry much logic. Braces, semicolons, class wrappers, repeated keywords, interface boilerplate, and ceremony-heavy declarations all consume tokens. That matters when your real bottleneck is context budget.

Second, many important mistakes surface too late. A model can generate a file that looks plausible, passes a quick glance, and still fails only after execution. The signal arrives as a runtime error, a stack trace, or an application-side failure. By then, the model has already spent tokens on the wrong path.

That is an expensive loop:

write -> run -> inspect prose error -> regenerate -> run again

We built ll-lang to change that loop.

ll-lang is a statically typed functional language designed for LLM code generation. The design goal is narrow on purpose: make it easier for a model to write code that compiles, gets strong feedback quickly, and can still target normal downstream ecosystems like F#, TypeScript, Python, Java, and C#.

This is not a "replace every language" project. It is a tooling and authoring language for a specific constraint: an LLM agent writing code under token pressure.

The four design principles

The current README boils ll-lang down to four principles. They are worth unpacking because together they define the product.

1. Token-efficient syntax

We wanted a language that spends more tokens on logic and fewer on ceremony.

ll-lang keeps the syntax compact:

no braces
no semicolons
no fn, type, in, then, or with
only 15 keywords
declarations use an uppercase/lowercase convention instead of extra syntax

That matters more than it looks on paper. Every redundant token competes with actual reasoning. If an LLM has to generate an algebraic data type, a few helpers, and a pattern match, the difference between a compact representation and a verbose one compounds quickly.

The project README reports ll-lang as 8 to 17 percent more compact than F# on real code, and significantly more compact than TypeScript, Python, and Java on type-heavy definitions. That is not an aesthetic choice. It is directly about how much useful logic you can fit inside the same context window.

2. Static types with inference

A language for LLMs cannot force the model to annotate every line. That just reintroduces verbosity through another door.

So ll-lang uses Hindley-Milner type inference. You keep the guarantees of a static type system, but you only write annotations where they actually clarify boundaries. The compiler carries the rest.

This gives you a useful middle ground:

enough structure for compile-time guarantees
less annotation overhead for the model
fewer chances to drift between a declaration and an implementation

For an agent, that is a better authoring environment than either extreme. Fully dynamic code catches mistakes too late. Fully annotation-heavy code spends too much of the budget describing obvious facts.

3. Compiled equals works

This is the most important principle in the project.

ll-lang is designed so the compiler catches the classes of mistakes that LLMs make all the time:

type mismatches
unbound variables
non-exhaustive matches
tag violations
unit mismatches

In other words, the fast feedback signal is compile-time, not runtime.

That is a major shift for agent workflows. Instead of asking the model to mentally simulate a whole program and then parse a runtime failure, you can keep it on a tighter loop:

write -> check -> fix one precise error code -> continue

That is cheaper, faster, and much easier to automate.

4. LLM-readable errors

Even a strong type system is less useful if the diagnostics are written as long human prose that an agent has to scrape.

ll-lang errors are intentionally compact and machine-readable:

EXXX line:col ErrorKind details

Examples from the README include:

E001 12:5 TypeMismatch Str Str[UserId]
E003 15:1 NonExhaustiveMatch Shape missing:Empty
E004 20:9 UnitMismatch Float[m] Float[s]
E005 7:14 TagViolation Str[Email] Str[UserId]

This matters because an agent can route on the code first and the text second. It does not need a fragile natural-language parser to understand what went wrong.

A worked example: catching a real bug before runtime

Here is the kind of bug that shows up constantly in AI-generated code: a model mixes up raw strings, tagged identifiers, and measurements that should not compose.

In a dynamic language, that often survives until the application runs. In ll-lang, it gets rejected immediately.

module ResetFlow

tag UserId
tag Email
tag m
tag s

lookupEmail(id Str[UserId]) Str[Email] = "alice@example.com"[Email]
sendReset(to Str[Email]) = to

bad(rawId Str)(distance Float[m])(elapsed Float[s]) =
  email = lookupEmail rawId
  total = distance + elapsed
  sendReset rawId

There are three distinct mistakes here:

lookupEmail expects Str[UserId], but rawId is only Str.
distance + elapsed tries to add meters and seconds.
sendReset expects Str[Email], but receives a raw string.

Those are not edge cases. They are the exact kind of mistakes that happen when a model is juggling several concepts at once and loses one semantic detail at a callsite.

With ll-lang, the compiler catches them as first-order feedback. The error stream is not an afterthought. It is the product.

You get precise signals like:

E005 TagViolation for passing an untagged string where Str[UserId] or Str[Email] is required
E004 UnitMismatch for combining values that do not share compatible units

The fix is explicit and local:

module ResetFlow

tag UserId
tag Email
tag m
tag s

lookupEmail(id Str[UserId]) Str[Email] = "alice@example.com"[Email]
sendReset(to Str[Email]) = to
speed(distance Float[m])(elapsed Float[s]) = distance / elapsed

good(rawId Str)(distance Float[m])(elapsed Float[s]) =
  userId = rawId[UserId]
  email = lookupEmail userId
  rate = speed distance elapsed
  sendReset email

That difference is exactly why "compiled equals works" is not just a slogan. It is the basis for a better agent loop.

If the model is going to make mistakes, which it will, we want those mistakes to collapse into compact compiler diagnostics instead of delayed runtime behavior.

Why this matters specifically for LLMs

Humans can often compensate for a weak signal. They read between the lines, trace a stack, remember a convention from elsewhere in the codebase, and infer what the system probably meant.

LLMs are different. They are much better when:

the syntax is regular
the error shape is stable
the repair target is local
the feedback arrives before execution

ll-lang leans into that reality instead of pretending models code the same way humans do.

A good LLM authoring language should make the happy path easy, but it should also make the failure path legible. That is where ll-lang spends most of its design budget.

Self-hosting is proof, not branding

A lot of language projects make ambitious claims early. We wanted something harder to fake.

ll-lang is self-hosting. The compiler pipeline is implemented in ll-lang, including the lexer, parser, elaborator, type inference, code generation, module system, and MCP server. The bootstrap fixpoint in the README is a strong statement of maturity:

compiler1.fs == compiler2.fs

That matters because it proves a few things at once:

the language can handle real compiler work, not just toy examples
the stdlib and module system are usable at meaningful scale
changes that break core semantics show up inside the language's own build loop

For DevRel, self-hosting also changes the story from "interesting experiment" to "working system with operational evidence."

The MCP layer turns the compiler into an agent tool

The language alone is only half the story. The other half is how an agent interacts with it.

ll-lang ships with an MCP server through lllc mcp. That means Claude Code, Cursor, Zed, and other MCP-capable clients can call compiler functionality as structured tools instead of shelling out and scraping terminal output.

The current README and user guide document 30 tools across:

compile and check flows
diagnostics and repair helpers
formatting and AST inspection
project graph and build operations
symbol navigation
dependency helpers
test helpers
FFI helpers
catalog and metadata lookups

That is important because it lets the model stay in a structured loop:

write source
call check_source or check_file
inspect structured diagnostics
call lookup_error or repair-oriented tools
retry

This is a much cleaner architecture than "ask the agent to guess what a shell command meant."

Why not just use TypeScript or Python with better prompts?

Prompting helps, but it does not solve the underlying signal problem.

You can absolutely get useful code from mainstream languages. But for the specific case of LLM-authored logic, they still impose tradeoffs:

more syntax overhead
weaker compile-time guarantees in common workflows
noisier runtime failures
error messages optimized for people, not agents

ll-lang changes the default environment instead of asking the prompt to carry the entire burden.

Where ll-lang fits

ll-lang is a good fit when:

an LLM agent is generating typed business logic
compile-time correctness matters more than framework breadth
the same source may need to target multiple runtimes
token efficiency is a practical constraint

It is not trying to be the answer to every programming problem. It is a sharper tool for a narrower one.

That is usually a good sign.

Try it

Repo: https://github.com/Neftedollar/ll-lang
Landing page: https://neftedollar.com/ll-lang/

Bootstrap path from the current README:

git clone https://github.com/Neftedollar/ll-lang.git
cd ll-lang
LLLC_BOOTSTRAP_REINSTALL=1 ./tools/check-selfhost-ci.sh

If you want to see the agent story directly, wire the MCP server into your client:

{
  "mcpServers": {
    "ll-lang": {
      "command": "lllc",
      "args": ["mcp"]
    }
  }
}

The MCP server label is arbitrary. Some docs show lllc, others ll-lang. What matters is command: "lllc" with args: ["mcp"].

Then ask your editor or agent a simple question: "Does this compile?"

That is the core bet behind ll-lang. Give the model a language with less ceremony, stronger guarantees, and better diagnostics, and the quality of the coding loop improves materially.

For human-first languages, runtime is often where truth appears.

For agent-first workflows, that is too late.

Type-Safe Cypher Queries in F# — Introducing Fyper

Roman Melnikov — Fri, 03 Apr 2026 02:37:26 +0000

Every F# developer who's worked with Neo4j knows the pain: raw Cypher strings, no IntelliSense, no compile-time checks, and the constant fear of typos in property names.

// The old way — string-based, error-prone
let cypher = "MATCH (p:Preson) WHERE p.agee > 30 RETURN p"
// Two typos. You'll find out at runtime. Maybe in production.

I built Fyper to fix this. It's a type-safe Cypher query builder that uses F# computation expressions:

type Person = { Name: string; Age: int }

let query = cypher {
    for p in node<Person> do
    where (p.Age > 30)
    select p
}
// Generates: MATCH (p:Person) WHERE p.age > $p0 RETURN p
// Parameters: { p0: 30 }

Typo in p.Agee? Compile error. Wrong type name? Compile error. Forgot to parameterize a value? Impossible — Fyper parameterizes everything by default.

How It Works

Plain F# records are your schema. No attributes, no base classes, no code generation:

type Person = { Name: string; Age: int }
type Movie = { Title: string; Released: int }
type ActedIn = { Roles: string list }

Fyper conventions:

Type name → node label (Person → :Person)
PascalCase field → camelCase property (FirstName → firstName)
Relationship type → UPPER_SNAKE_CASE (ActedIn → ACTED_IN)

Relationships

let findActors = cypher {
    for p in node<Person> do
    for m in node<Movie> do
    matchRel (p -- edge<ActedIn> --> m)
    where (p.Age > 30 && m.Released >= 2000)
    orderBy m.Released
    select (p.Name, m.Title)
}
// MATCH (p:Person) MATCH (m:Movie)
// MATCH (p)-[:ACTED_IN]->(m)
// WHERE (p.age > $p0) AND (m.released >= $p1)
// ORDER BY m.released
// RETURN p.name, m.title

Variable-length paths work too:

matchPath (p -- edge<Knows> --> q) (Between(1, 5))
// MATCH (p)-[:KNOWS*1..5]->(q)

Mutations

F# record update syntax for SET — only changed fields generate Cypher:

// Birthday: increment age
let birthday = cypher {
    for p in node<Person> do
    where (p.Name = "Tom")
    set (fun p -> { p with Age = p.Age + 1 })
    select p
}
// SET p.age = (p.age + $p0)

// MERGE with ON MATCH / ON CREATE
let ensurePerson = cypher {
    for p in node<Person> do
    merge { Name = "Tom"; Age = 0 }
    onMatch (fun p -> { p with Age = 50 })
    onCreate (fun p -> { p with Age = 25 })
}

Multi-Backend: Same Query, Different Database

Write once, run on Neo4j or Apache AGE (PostgreSQL):

// Neo4j
let neo4j = new Neo4jDriver(
    GraphDatabase.Driver("bolt://localhost:7687",
        AuthTokens.Basic("neo4j", "password")))

// Apache AGE (PostgreSQL)
let age = new AgeDriver(
    NpgsqlDataSource.Create("Host=localhost;Database=mydb;..."),
    graphName = "movies")

// Same query, different backend
let! people = query |> Cypher.executeAsync neo4j
let! people = query |> Cypher.executeAsync age

Each driver declares which Cypher features it supports. Unsupported features (like OPTIONAL MATCH on AGE) are rejected at query construction time — not at the database.

Inspect Without Executing

Debug queries without a database connection:

let cypher, params = query |> Cypher.toCypher
printfn "%s" cypher
printfn "%A" params

Cypher Parser (Bonus)

Fyper includes a zero-dependency Cypher parser. Parse any Cypher string into a typed AST:

open Fyper.Parser

let parsed = CypherParser.parse
    "MATCH (p:Person)-[:ACTED_IN]->(m:Movie) RETURN p.name"
// parsed.Clauses = [Match(RelPattern(...)); Return(...)]

// Roundtrip: parse → compile
let compiled = CypherCompiler.compile parsed

Performance

Benchmarked on Apple M1 Pro:

Operation	Time
Compile simple query	890 ns
Compile complex query (8 clauses)	3.2 μs
Parse Cypher string	1.2 μs
Full roundtrip (parse → compile)	2.0 μs

Get Started

dotnet add package Fyper
dotnet add package Fyper.Neo4j    # or Fyper.Age

GitHub: github.com/Neftedollar/fyper
Docs: neftedollar.github.io/fyper
NuGet: nuget.org/packages/Fyper

250 tests (unit + property-based + integration). MIT license. Zero dependencies in core.

If you've been writing raw Cypher strings from F# — try Fyper. I'd love feedback: open an issue or leave a comment here.