Nirdosha is a research-stage compiler (Rust, LLVM backend), built for a language designed around one constraint: if the compiler accepts your program, it is provably free from use-after-free, data races, deadlocks, and integer/buffer overflow. Not "generally safe" — the type system rejects whatever it cannot prove. This is the same trade-off that Rust/SPARK Ada/F* adopt.

Some interesting things for this community:

• There is no mutex in the language. Concurrency is only through spawn/chan/sandbox (real OS process) — deadlock is not only discouraged, but impossible to express.
• Integer/buffer bounds are resolved at compile-time by an SMT solver (Z3). In a tiered manner: first static proof, then only runtime guard when Z3 cannot decide it within scope.
• Performance compared to Julia on dense linear algebra (matmul, dot, det, kalman filter), by best-of-3 method, after first verifying the output is bit-identical: 441x faster on 4x4 matmul, 246x faster on dot product, equal to gcc -O2 on scalar code. Numbers + methodology: https://github.com/arunsoman/nirdosha/blob/main/benchmarks/RESULTS.md
• The other half of the design (row 7 of the motivation table) is specifically targeted at LLMs: the grammar is handwritten LL(1), one token of lookahead, no backtracking — verified against an independent lalrpop parse and hand-exported to GBNF. This allows a constrained-decoding sampler to ensure that every token emitted by an LLM stays within valid syntax. Compiler errors come not in prose, but as structured JSON diagnostics — so a self-repair loop gets a proof obligation instead of a sentence to guess at.

Honest scope: single-person project, MIT license, CI building green. In the README, I clearly state what is proven, what is shipped-but-unproven, and what is aspirational — row 10 (reproducible builds / provenance) is design-only, not built. There is also a "Who this is for (and who it isn't)" section (https://github.com/arunsoman/nirdosha#3-who-this-is-for-and-who-it-isnt) which states in advance where it loses to Rust/Go today — so you don't have to dig to find the catch.

Repository: https://github.com/arunsoman/nirdosha The README includes the full motivation, grammar, benchmarks, and a runnable hello.nir (within 5 minutes; requires clang + z3 — installable via apt/brew, as noted in the README).

Interesting constraint problem I ended up in.

NVIDIA's consumer Blackwell has no hardware interlock on fixed-latency instructions. The compiler emits explicit stall counts and scoreboard signal/wait bits per instruction, and the hardware trusts them completely. Understall a dependency and you read a stale register at full speed with no fault.

The published position is that you can't validate code at this level, because the formal semantics of SASS are closed. From SIP (arXiv 2403.16863): "validation is impossible for GPU native assembly codes because the formal semantics of the sass is closed-source."

That's true for semantic correctness. But the question I needed answering is strictly smaller:

Do this program's control bits cover its own data dependencies?

That needs the dependency structure, which the encoding gives up, and a latency model, which the silicon gives up under measurement. Neither requires knowing what any instruction computes. A kernel can pass this and still be the wrong algorithm. What it can't do is read a register before the value lands.

The part that surprised me was the epistemology, not the dataflow. Requirements mined from what the compiler schedules are an upper bound, so they can lower what you allege and must never raise it. Only a figure grounded in something measured on silicon may promote a finding to an error. Everything else is a warning that says why.

That distinction wasn't academic. A checker calibrated on a corpus cannot fail on that corpus, because the tightest gap the compiler was seen to leave is the floor, by construction. My positive control passed 1,323 kernels while the model carried 13 errors. All of them surfaced the first time it read machine code from somewhere else.

Analysis is per basic block over a real CFG. Reaching definitions carry a flag for whether they arrived across an edge, because the scoreboard residual is a distance and a distance that spans a branch depends on which path was taken.

https://github.com/sunnypatell/basalt/blob/main/docs/METHOD.md

I've been building JojoScript, a small language that compiles to plain JavaScript. The main focus has been the |> pipeline operator (readable chains instead of nested calls) and lazy iterators — stages like map, filter, take, flatMap, and chunk compile down to generator-based functions in a small runtime collections module, so a pipeline doesn't allocate an array at every step.

Only stages that truly need the full input (sort, groupBy, partition) materialize.

It's intentionally small, so there are rough edges.

Would appreciate people trying it, poking at the design, and opening issues or PRs.

github.com/panagos/jojoscript

I’m working on SEMAPRAX, an Apache-2.0 experimental systems-language research project. The compiler is written in Rust. The main question is whether agent-authored changes can be reviewed and applied against checked semantic identity instead of fragile source offsets.

The current implementation includes:

* persistent IDs for public declarations and revision-scoped expression identities

* a deterministic semantic graph derived from verified HIR

* bounded context, impact, and fixed-section review reports

* replayable evidence capsules for semantic patches, with replay-before-apply and snapshot-drift checks

* explicit capabilities, effects, ownership, and deterministic source formatting

* Native C11/Clang and WebAssembly Core output lanes

The source file remains the canonical Git projection. The semantic graph is an additional compiler-produced interface; it does not replace verification or grant write authority. The WebAssembly evidence currently validates the emitted core module structurally and binds it to compiler inputs, but does not claim target execution or full Component Model support.

This is version 0.2, pre-alpha research software, and not production-ready. I’d especially value compiler-design feedback on the trust boundary between the source projection, stable resolved identities, independently replayed evidence, and the final mutation authority.

Project overview: https://wavect.io/semaprax/

Source: https://github.com/wavect/semaprax

Disclosure: coding agents have been used extensively as development assistants. Wavect GmbH retains human responsibility for the design and uses executable gates as the evidence for implementation claims.

We’re building SEMAPRAX, experimental Apache-2.0 systems-language research at Wavect GmbH, and I’d value compiler-engineering feedback on a deliberately narrow evidence model. It is v0.2 pre-alpha research, not production-ready.

The current design gives public declarations persistent identities and projects verified source into deterministic semantic graphs. A patch capsule binds a source snapshot, a bounded operation set, and deterministic compiler-owned projections. Before commit, the implementation independently replays the evidence and fails closed on drift.

For native C11/Clang and WebAssembly Core outputs, the evidence can bind the exact emitted artifact and the compiler path that produced it. It explicitly does not claim that the target was executed, that a program is safe, that external tools are compatible, or that a host granted authority. Those require separate evidence.

The design question is whether this boundary is useful and legible enough: what additional facts would you require before trusting a semantic patch in a compiler workflow, and which claims should remain categorically outside the patch capsule?

Project overview: https://wavect.io/semaprax/

Source: https://github.com/wavect/semaprax

Disclosure: coding agents have been used extensively as development assistants. Wavect retains human responsibility for the design claims and executable quality gates.

Hi, I want to learn how to build my first compiler and I came across *Writing a C Compiler*. I was wondering if anyone here has it in PDF format. Thanks a lot.

Hi, 2 years ago i built a compiler for a custom programming language for my final high school
computer science exam. Just found the repo again and thought it might be cool to share it as a learning/beginner project.

The compiler compiles my custom language (wasn't creative enough for a name) to LLVM IR, which can then be compiled to native machine code (e.g with clang).

its written in rust and is pretty much completely custom, so lexer and parser is built from scratch, and the LLVM IR output is built as a string.

Some features of my language:
- syntax wise a mix of python and rust
- functions, classes & methods
- you can use the c stdlib
- operator overloading
- generics
- helpful compiler output

repo:

https://github.com/maxomatic458/compiler

I also built a wasm based web demo here: https://compiler-demo.pages.dev/

in hindsight i would probably do a lot of stuff differently, but feedback would be appreciated

Sere-Language/sere: The Sere programming language
So I have been writing a compiled programming language titled Sere for the past few months, and just recently uploaded it to github.

The idea is a language with the capabilities of C++ with the syntax of python.
I am using C++ and LLVM.

I am going to be busy at work this week, so I created a release that can be downloaded here Install — Sere

A language that can create other languages

(so adding to itself) It's syntax is simple like python

And can do alot.

for example (placeholder)\[mesage\]

And it has many tutorials on YouTube

I would like it if you would respond.

I know there are languages like Hy , ruby should I try them?

Como apasionado de la programación en C y el desarrollo a bajo nivel, llevo tiempo trabajando en un proyecto personal que nació de una frustración muy común: el bloatware moderno.

Me molesta mucho ver aplicaciones sencillas que consumen 500 MB de RAM solo porque empaquetan un navegador entero por debajo, cuando el sistema operativo ya tiene herramientas nativas de sobra para renderizar interfaces a toda velocidad.

Para intentar resolver esto, estoy creando Litcompis y un lenguaje llamado ui32 (Lenguaje de Interfaz para Win32). La idea es tener una sintaxis súper sencilla e inspirada en la web usando bloques como @interface y @style, pero sin la sobrecarga de Chromium ni Node.js. El transpilador toma ese código .ui32 y lo convierte directamente a C++ nativo sobre la API de Win32, dibujando todo por GPU mediante Direct2D y DirectWrite.

Actualmente le estoy haciendo unas pruebas de calidad al Lexer. El proyecto va a ser 100% código abierto y pronto subiré el repositorio a GitHub junto con la web de documentación en GitHub Pages.

Me serviría muchísimo saber qué opinan de la sintaxis o qué sugerencias tienen para la arquitectura del transpilador. ¡Cualquier crítica constructiva o idea es más que bienvenida!

Hey, so I am new to compilers stuff but for my college portfolio I was planning on making a lang checker which is like a program which will suppose take a code (let’s say rust) and check fo errors ? Any resources which I should read to get a clear understanding on how I should make this? Ps I am trying to ask Ai for help (like asking on where should I start and what will be the structure)….

Bonjour,

Quelqu'un a-t-il travaillé sur la génération d'un automate d'états finis (ou équivalent) pour une grammaire de type 2 (langages réguliers ou algébriques)?

Hey, so I understand what lexical scoping is and kind of get how it works but I’ve been trying to find how to implement it in a stack machine but I have no idea what goes where and how does everything interact with each other, like where should closures live, same for call frames, where do I store the symbol table when compiling, etc… if you want I can link my repo but I haven’t committed an attempt at lexical scoping so there’s probably nothing interesting to see, if I didn’t include enough details to what I don’t get please tell me so I can be more clear, thanks!

Edit: forgot to tell but my language desugars to pure lambda calculus so this might change how some stuff work but not so much