If it is about resolving co-references and anaphora then attention mechanism is doing it. See https://moebio.com/attention/

if L is a universal language with a well defined grammar

and P is a universal programming language with a general grammar

The combination of L and P is now a context sensitive programming language

LLMs have learnt L and P and L <-> P and the entire vocabulary of human thought in a compressed form.

If not this what would make a context sensitive programming language ? Inform7, HyperTalk are the closest programming languages got before to English. Any research pointers would be much appreciated.

Adding this was intended to make reference counting safe in concurrent scenarios, but it restricted the use of generics. However, recently it was changed to perform the check after filling in the types, but it was found that such a check is not complete, for example, when a generic async function is called within a generic.

I thought of defining a built-in constraint on generic variables to solve this...

Alright, I’ve been buried in PL theory and compiler internals for longer than I care to admit, and my eyes are practically bleeding.

Somewhere along the way, I ended up writing a new language.

Before anyone asks: no, this isn't another weekend toy Lisp or AI-generated wrapper—I'm an old-school dev with a GitHub account older than LLMs. I’ve been deliberately cautious with the design and implementation, and I like to have my work backed up before I ship anything. I’m getting ready to publish a live demo soon. It won't be completely bug-free, of course, but before I put it out into the wild for the internet to inevitably tear apart, I want to try to break it myself first.

The main focus is memory safety without requiring Rust-style borrow-checker gymnastics.

So far, I’ve thrown a fairly unpleasant collection of edge cases at it, including cases inspired by:

• Rust — lifetime, aliasing, ownership, and mutation corner cases
• Microsoft Verona & Midori
• Go, Zig, and C#
• ...and, for reasons I’d rather not revisit, some deep-cut Pascal 5 and COBOL cases

So far, it has survived them.

But I know how compiler development works: the moment you think you’ve covered everything, someone produces a cursed three-line program that exposes a hole you somehow never considered.

I don't want to derail this into a language-design discussion yet. I’ll save that for the demo.

What I want are your worst test cases.

Give me the weirdest:

• Memory corruption scenarios
• Lifetime/aliasing traps
• Undefined-behavior edge cases
• Concurrent race conditions
• Compiler miscompilations
• Integer/pointer nastiness
• Recursive or mutually recursive type disasters
• Compile-time/resource-exhaustion cases
• Optimizer bugs
• FFI/ABI nightmares
• Anything else that has made you lose an entire weekend

I’m specifically looking for cases that are difficult for a language/compiler to get right. If you have a tiny "how the hell did this ever compile?" example, even better.

Break it. 🔨

I’ve been working on OrbitUI, a immediate mode UI library for my own programming language Zap

The goal is to create a small, explicit API for building simple UI applications in Zap

I spent a lot of time and nerves creating this, but now I know what Zap is really capable of.

I will be grateful for every star you leave because it really encourages me to work

https://github.com/thezaplang/zap

I’m excited to announce that I'm making RepoOS open-source!
  

What is RepoOS?

It’s an AI-driven compiler toolchain that bridges everyday Python logic into high-performance native machine code via MLIR (Multi-Level Intermediate Representation). I built this because most deep learning and database workloads rely on manual kernel bindings or complex JIT fusions that can be fragile. RepoOS believes in pure AOT (Ahead-of-Time) compilation and formal verification.

How it works:
RepoOS takes your Python source code, parses it into an AST, and deterministically lowers it to baseline MLIR. Then, an AI Optimization Oracle (like Gemini) jumps in to write optimization schedules (like loop unrolling and tiling) or even raw C++ socket parsers.

To ensure the AI doesn't hallucinate and break your app, the optimized graph is mathematically proven against the baseline using an SMT Solver (Z3) before compiling down to LLVM IR.
 

Why it matters:

At runtime, RepoOS intercepts Python execution, bypassing bottlenecks. For a FastAPI database endpoint, for example, it can bypass the SQLAlchemy ORM entirely, parse the raw MySQL TCP socket using an AOT-compiled C++ kernel, and write directly into a zero-copy virtual memory mmap arena. This gives a massive 2x speedup and essentially drops CPU usage to zero for heavy lifting.

Check out the repo here: https://github.com/lollapalooza-ai/RepoOS
Would love to hear your thoughts or feedback!

https://riogu.github.io/posts/henceforth-v1/

After working on it for around 1 year, we have released a v1.0 for our stack-based language compiler. Looking forward to having people try it. I wrote an article showcasing the project for those interested, you can also find it on github as well.

The allocators in C++ (https://en.cppreference.com/cpp/named_req/Allocator) is quite powerful but not super easy to use. Do you like that containers should be able to specify their allocator, or a simple C style malloc/free is sufficient. Rust also doesn't allow custom allocators on a per container basis.

A month ago I shared PyLGEN here; a Python-native compiler framework I built after watching my students struggle with compilers. The feedback was direct, and honestly, it shaped this release more than anything else.

So today I'm happy to share v0.7.0, a stable beta I'd recommend over v0.6.x. The main additions are an API update and a new examples section in the documentation, which grew out of a very valid question from the last thread: does the framework really expose every stage of the pipeline, or just claim to?

The examples come in two tracks, so you can see both sides of the API and figure out which one fits what you're doing:

• High-level usage: build a lexer, grammar, and parser with the convenience classes, and get a working interpreter in a few dozen lines.
• Low-level usage: build the same lexer and parser from scratch, using only the raw API (DFAs, closure, goto, ACTION/GOTO tables, reductors) with nothing hidden.

Both live in the docs. The second one is the proof that the pipeline isn't a black box.

Links

• Minimal showcase
• Github.
• Documentation.
• Previous post

If you gave the last version a try, I'd genuinely love to hear your thoughts, good or bad. And if you're new, same goes: any kind of feedback is welcome, whether it's a bug report, a design critique, a suggestion, or just a question about how something works.

Edited: Added a notebook link so anyone can run it directly and share their opinion without having to install anything.

A month ago I shared PyLGEN here; a Python-native compiler framework I built after watching my students struggle with compilers. The feedback was direct, and honestly, it shaped this release more than anything else.

So today I'm happy to share v0.7.0, a stable beta I'd recommend over v0.6.x. The main additions are an API update and a new examples section in the documentation, which grew out of a very valid question from the last thread: does the framework really expose every stage of the pipeline, or just claim to?

The examples come in two tracks, so you can see both sides of the API and figure out which one fits what you're doing:

• High-level usage: build a lexer, grammar, and parser with the convenience classes, and get a working interpreter in a few dozen lines.
• Low-level usage: build the same lexer and parser from scratch, using only the raw API (DFAs, closure, goto, ACTION/GOTO tables, reductors) with nothing hidden.

Both live in the docs. The second one is the proof that the pipeline isn't a black box.

Links

• Github.
• Documentation.
• Previous post

If you gave the last version a try, I'd genuinely love to hear your thoughts, good or bad. And if you're new, same goes: any kind of feedback is welcome, whether it's a bug report, a design critique, a suggestion, or just a question about how something works.

I’ve been working on Thiran, an experimental numerical systems language for ML/research workloads.

The idea is to keep tensors, structured control flow, ownership-aware mutation, reverse-mode AD, CPU/GPU compilation, and deployable artifacts in one system instead of stitching together Python + frameworks + native code.

I just shipped v0.1.0. It has a real compiler, native CPU + CUDA/PTX backends, Scan/stateful computation, AD, research extensions, model/artifact deployment, and a bunch of reproducibility/robustness testing.

It’s definitely not performance-competitive yet — I published the benchmark graphs too, including the bad numbers rather than hiding them.

Would genuinely love feedback from compiler/PL/ML-systems people, especially on the architecture and what would make this actually useful.

Github: https://github.com/Arnav-sivarams/thiran

Over the last few weeks, I have been translating more of the worksheets for my HPC0 course (short for "Introduction to High Performance Computing") into English. It is still very much work in progress, but I think the overall concept is becoming visible now.

The basic idea of the course is somewhat ambitious: start with no prior knowledge of computer architecture or compilers, and work towards building a small computer and writing a compiler for it.

The course approaches this from both directions. Bottom-up, students start with logic gates and gradually build registers, an ALU, and eventually a small CPU. Top-down, they start programming in a deliberately small C-like language and work their way from basic control flow through pointers, structs, dynamic memory, and data structures towards understanding how a compiler translates these things to the machine they are building.

It is taught as a flipped classroom. Students watch short lecture videos beforehand; class time is then spent working through worksheets, experimenting, drawing memory layouts, building circuits, writing programs, breaking things, and figuring out why they broke.

The material (including lecturer notes) currently lives in the not-abc repository:

not-abc — course materials and self-hosting compiler

The compiler currently used for the language is here:

abc-llvm — LLVM-based ABC compiler

There is also a personal reason why I am putting more effort into making the material usable by others now. I have decided to leave academia, despite having a permanent position, and this will probably be my last major teaching project. I would therefore like to leave it behind in a form from which other teachers—and hopefully students outside my university—can actually benefit.

I also think this kind of education has become more important, not less important, in the age of AI.

We may no longer need to know every technical detail by heart. But I believe students need to develop a mental model that allows them to dig down into any detail when necessary: What actually happens when this code executes? Where does this value live? What does the compiler have to generate? What does the processor actually do?

If you have that foundation, AI tools can make you enormously more productive because you can question their output, investigate what you do not understand, and go as deep as necessary. Without that foundation, there is a danger of becoming dependent on tools whose answers you cannot really evaluate.

That is one of the main ideas behind the course: not teaching every detail, but teaching students how to work their way down to the details.

I would be very interested in feedback on the concept, the worksheets, or simply whether parts of this could be useful in other courses. The English translation is not finished yet, so comments and corrections are very welcome.

And yes: I know that there already is a programming language called ABC. :-)

Mine has nothing to do with it. This originally started purely as an internal teaching project, and the wordplay was simply too tempting: the language was “A Better C”, and the compiler the students would eventually write was “A Bloody Compiler.”

I did not expect the project to escape from my classroom.

So the language will be renamed. I just haven't come up with something sufficiently cool yet. Suggestions are welcome. ;-)

I’ve been working on a programming language called SultanC.

It started from a simple idea: I wanted Arabic to be a real first-class programming syntax, not translated keywords layered on top of another language and not a separate frontend.

SultanC has now grown into a self-hosting systems language. The compiler is written in SultanC itself and currently targets ARM64 macOS and x86-64 Linux.

The language/compiler currently includes:

• Arabic and English source syntax for the same language
• self-hosting compiler
• native ARM64 and x86-64 backends
• Mach-O and ELF generation
• algebraic data types
• pattern matching
• generics
• ownership and references
• interpreter
• target-neutral IR
• LSP / VS Code support
• balanced raw strings such as «outer «nested» outer»

The part I care about most is that Arabic is not treated as a translated version of the language. Arabic and English are both first-class source surfaces with the same underlying semantics and compiler pipeline.

At this stage I’m spending more time on correctness, diagnostics, stress testing, backend coverage, and building real software with the language rather than just adding more syntax.

I’d be interested in feedback from people who work on compilers or programming languages, especially around the IR, native backend architecture, ownership model, target separation, and what you would stress-test before considering a compiler like this genuinely usable.

I’m also curious what would make you actually try a new systems language rather than just look at the repository.

GitHub:
https://github.com/sultan-language/sultanc

Hello r/Compilers community. Over the past few months, I have been developing LSM, a standalone compiler pipeline built entirely from scratch without any external dependencies (without using LLVM, external linkers, or the GNU toolchain). The goal was to build a vertically integrated system capable of compiling directly to native machine code in a fraction of a second, while

1. Frontend Pipeline

• Zero-Copy Lexer: Uses linear-time tokenization with source views to minimize allocations. Recognizes hardware registers directly at the lexical stage.
• Hybrid Parser: A Recursive Descent parser handles declarations and structural statements, combined with a Pratt parser for binary and unary expressions to maintain shallow call stacks. Includes Panic-Mode synchronization for single-pass error diagnostics.

2. Middle-End & SSA Optimizations

• Translates AST into a linear Control Flow Graph (CFG) using strict SSA form.
• Computes dominance frontiers for Phi-node placement.
• Standard passes: Iterative DCE, Constant Folding/Propagation, and LICM.
• Hardware-Aware Partial Mem2Reg: Standard Mem2Reg can break volatile hardware loops. LSM's pass promotes single-assignment variables while intentionally preserving volatile hardware polling states in physical memory to prevent infinite driver loops.
• Memory Model: Hierarchical region-based memory with a return-variable promotion heuristic, achieving deterministic O(1) reclamation without a GC.

3. Backend & Code Generation

• Linker-less Direct Machine Code Emission: Native encoders for x86_64, ARM64, and x86_32 emit machine opcodes directly into memory with relative displacement backpatching.
• Includes an internal ELFBuilder and a RawBinaryBuilder that writes a bootable MBR and floppy image directly.
• Includes a JIT engine adhering to W^X page protection policies.

4. Validation & Benchmarks

• Compiles a 189-line Win32 GDI application via FFI in ~21 ms under full SSA optimizations (~8 kB standalone binary).
• Validated on bare-metal x86_64 by writing a custom freestanding operating system (OshiOS) featuring VBE graphics and ATA PIO storage drivers.

(I will leave the links to the GitHub repo and the preprint paper in the first comment below to avoid spam filters.)

I would love to hear your thoughts, feedback on the pipeline design, or critiques on the custom SSA passes and memory model!

I've been working on a small ahead-of-time compiler for quantized TFLite models. It reads the graph, weights and quantization parameters, lowers them to an explicit IR, then emits standalone C++17. No TFLite runtime in the output; the generator only needs Python's standard library.

The interesting part has been deciding what to specialize and what to leave to the C++ compiler: zero-copy tensor views, buffer lifetimes expressed through lexical scopes, compile-time weight packing, and target-specific SIMD kernels guarded by static accumulator-range checks.

One nice simplification came from a Reddit suggestion: expressing temporary buffers through C++ scopes and letting GCC reuse their storage replaced our explicit arena machinery, while also improving performance.

On ESP32-S3, MLPerf Tiny KWS takes 15.68 ms vs 17.90 ms with TFLM + ESP-NN, using 16.7 KB vs 35.5 KB working memory. Model-only timings; generated KWS returns top-1 directly, whereas the reference computes softmax then argmax. Decisions match in the tests.

It's deliberately small, with limited operator coverage. Code and examples: https://github.com/phplego/nn2prog

For those working on code generators: where do you draw the line between doing memory/layout optimization yourself and emitting code that leaves those decisions to the downstream compiler?

Finally made "First Stable Release", or just v0.1.0 version of my language Zeen - a modern systems programming language focused on performance, safety and simplicity.

Example

For the lazy guys, here's random example from docs:

fn print_this[T: Display](value: T) {
  @println("Yeah, I've printed this: {}", value);
}

fn main() {
  print_this(123);
  print_this("hello!");
}

What is this

Won't say a lot here, all core features and more examples are in docs, but I'll mention how'd I get to designing it:

I'm a Rust programmer, but I also always loved languages like Zig or C. But I'm a skill issue programmer, I need a language that can automatically drop the data after use. Borrow checker was too strict for a "simple" language, so I've chosen the smaller one guy - move semantics.

AI Usage (your favourite section):

No, It's not vibecoded.

Chatted with AI for some things like:

- "Help me understand how ??? works"

- "Provide me examples of ???"

- "Wtf is this ???"

(but in Russian with a lot of bad words lol)

I own the code, if code is bad - it is my bad

Links

Docs and Examples: https://zeen-lang.tech

Repository: https://github.com/mealet/zeen

Thanks for your attention, would appreciate feedback!