Imagine you have a world-class factory that builds cars — but the factory's last mile, the final assembly and paint shop, is stuck using 1990s robotics. Everything upstream is superb: the design, the machining, the quality control. But that final stage is locked to one toolchain, and nobody else can plug in a better robot arm. Edward Kmett just built a replacement robot arm in a week, and it fits the same conveyor belt. THC — Turbo Haskell Compiler — is a JIT and AOT compiler for GHC Core that runs on Truffle/GraalVM. It does not replace GHC's parser, typechecker, desugarer, or optimizer. It replaces the backend: the code generation and execution stage. GHC still does the hard intellectual work of turning Haskell source into optimized Core; THC takes that Core and runs it on the JVM, using the Truffle framework and Graal's adaptive JIT to generate machine code. The approach descends from Kmett's earlier Cadenza project, which demonstrated that typed functional languages can run efficiently on Truffle's partial evaluation infrastructure. The coverage is startling for a one-week project. THC implements every one of GHC 9.14.1's prim-ops, supports Template Haskell, Linear Haskell, Cabal package resolution including Backpack, and can JIT- or AOT-compile pandoc, happy, alex, and GHC itself. It offers polyglot FFI to Python, Ruby, R, and JavaScript via GraalVM's polyglot layer, with zero-copy UTF-8 string conversion for Data.Text. C/C++ FFI goes through Sulong, LLVM-on-JVM. The practical implication: a Haskell program can call a Python data frame library or a D3.js visualization and get the result back without serialization overhead. The tail-call story is the most technically inventive piece. Previous JVM functional languages (Eta, Scalaz trampolines) used trampoline mechanisms — essentially, returning a thunk instead of making a call, then looping. THC instead uses a Bloom-filter-based detection scheme during tracing to identify recursive tail calls, then rewrites them into tight loops via custom Truffle nodes and Graal's compilation. False positives cost slow-path work but don't break correctness. When stack frames accumulate anyway, THC compacts them using a technique reminiscent of CHICKEN Scheme's garbage-collection-as-stack-management strategy. On Data.Map benchmarks, this produced roughly 66 fallback trampoline calls versus several million fast-path calls. Performance sits in a credible but unfinished range. Early Data.Map benchmarks showed 3× faster to 3× slower than native GHC after warmup, mostly clustering around 10-20% slower. A recent push for broader coverage introduced a ~10× regression on some easy benchmarks, which the team is actively fixing. Compressed oops (32-bit heap references with 8-byte alignment, capping heap at ~32 GB) are supported for cache-friendliness. The honest gap: stack growth bounds on non-tail-call paths remain unverified. The strategic bet here is that GraalVM's adaptive JIT can close the gap with GHC's static backend while gaining JVM ecosystem access — garbage collection tuning, profiling, polyglot interop, JIT warmup intelligence — for free. If the performance envelope stabilizes near parity, THC would give Haskell programmers something GHC cannot: runtime adaptivity, polyglot library access, and a path to AOT via Native Image that doesn't require maintaining a separate LLVM or NCG backend. The risk is that functional-language workloads hit JVM pathologies (megamorphic dispatch, object header overhead, GC pressure from closures) that Truffle can't fully paper over. This is not a paper. It is a working artifact, one week old, written by one of the most technically capable people in the Haskell ecosystem while visiting another one. The code is public. The claims are empirical and hedged honestly. What makes it remarkable is not any single technique but the speed of integration: a full prim-op implementation, Cabal support, polyglot FFI, and self-hosting in seven days. Whether it becomes a production tool depends entirely on whether the performance regression is a bump or a wall.
