Why l (new runtime for k and q)

Summary

I have been working with K and Q since 2001, nearly twenty-five years now. I will say the obvious part first: Arthur Whitney is a genius. K and Q remain extraordinary languages. Their design is small, dense, and beautiful. But despite years of optimization, extension, and correction, the core implementation model is still rooted in Arthur’s original insight from the 1990s. I did not want to change the language. I am not arrogant enough to think I should invent a new one. What I wanted to do was reimagine the implementation for the machines we actually use today. Computers in 2026 are not the computers of 1997. CPUs are wider. Memory is relatively slower. Every machine has multiple cores. Many have GPUs, NPUs, AMX units, NEON, AVX, VNNI, and other specialized execution engines. The hardware has changed dramatically. The programming model has not kept up. l is my attempt to keep the language, K, Q, qSQL, IPC, the whole world of existing code, and rebuild the execution engine underneath it. The implementation is built around four ideas: SIMD, parallelism, fusion, and compression. SIMD as a first-class primitive I wanted every operator to take advantage of the hardware automatically. Before clusters, GPUs, or distributed systems, a simpler question: how fast can every primitive be on a single core? That means making every cycle count. It means treating SIMD not as an optional optimization but as the default path for primitive execution. If the hardware can process many values per instruction, the language should use that automatically, no rewrites, no vector intrinsics, no thinking about it. The primitive should just be fast. Parallelism by default Parallelism has always been natural for array languages. APL, K, and Q all express work as large, regular operations over arrays, exactly the structure modern CPUs can exploit. But I wanted to think about it from first principles. Instead of bolting threads on as an external tool, l treats parallel execution as part of the pr...