Lisp and ML form two of the most significant branches of the functional programming language family tree, yet they have historically taken radically different approaches to program compilation and code loading. At first glance, GHC sits firmly in the latter camp: though it provides a dynamic environment via GHCi and has gained some features for package-aware compilation, at its core is a traditional, one-shot, static compiler that produces objects from compilation units in the traditional linking model.

However, developments in recent years have resulted in a slow but steady chipping away at GHC’s rigid adherence to this traditional approach. For one, Template Haskell and compiler plugins have both necessitated tighter integration between the core of the compiler and a dynamic environment. For another, development tools like the Haskell Language Server (HLS) increasingly require access to information that has historically been internal to GHC. These growing needs have resulted in a smattering of initiatives—from TTG extension points to a CoreExpr representation of Typed Template Haskell quotations to HIE files—to “open up” portions of the compiler to extension or reuse.

While several of these challenges are relatively new to GHC, they are hardly new to many of our Lisp-family cousins. In this talk, I will examine a selection of strategies used successfully by Racket for almost two decades to attack these problems and discuss how Racket’s approaches compare and contrast to those of GHC. In particular, I will highlight ways in which the two systems are not as radically different as they may at first appear, as well as present insights the Racket community has learned from experience that GHC can adapt and apply to its own unique challenges. Finally, I will note some of the key ways in which GHC’s approach to compilation fundamentally differs from Racket’s and how those differences result in a subtly different set of obstacles to overcome.