Zola 2026-08-04T00:00:00+00:00 https://blog.haskell.org/atom.xml 2026-08-04T00:00:00+00:00 2026-08-04T00:00:00+00:00 Unknown https://blog.haskell.org/revised-haskell-2010-report/ <p>The Haskell 2010 language report was released almost exactly 16 years ago, and although various attempts have been made, no further report has been released. This does not mean, however, that the language hasn't changed. On the contrary, the Haskell that we write today is quite different to the one we wrote 16 years ago, and the language has become more beautiful, consistent and ergonomic in the process. The specification, unfortunately, couldn't keep up.</p> <p>Many members of our community express some pessimism when it comes to the possibility of a new report. Sure, they would also love to have a new and updated report, but they think that it is either too hard or not worth the effort. I think that is not true. Having an up-to-date report is essential for the health of our community, and it is actually possible for us to get there in a reasonable amount of time with a reasonable amount of work. Here is my plan for how we can get there, and how we can finish the process before the new year.</p> <h2 id="why-we-need-a-new-report">Why We Need a New Report</h2> <p>The Haskell Language Report is an essential part of the documentation of the language. It is not the first thing that a beginner should consult when they learn Haskell, but it is an important resource for those who want to advance to being an intermediate or experienced Haskeller. If you want to learn about the precise syntax of floating point literals, the rules and desugaring for do-notation, or the meaning of <code>default</code> declarations, the report is the authorative resource where you can find answers. It is therefore unfortunate if the answers that you find in the report are wrong, or do not correspond to what compilers implement or the base library provides. In that case, you have to retrace the proposals and discussions that lead to the current state: The <a rel="noopener external" target="_blank" href="https://wiki.haskell.org/Functor-Applicative-Monad_Proposal">Functor-Applicative-Monad</a>, <a rel="noopener external" target="_blank" href="https://gitlab.haskell.org/haskell/prime/-/wikis/libraries/proposals/monad-fail">MonadFail</a>, <a rel="noopener external" target="_blank" href="https://wiki.haskell.org/Foldable_Traversable_In_Prelude">Foldable-Traversable</a> and <a rel="noopener external" target="_blank" href="https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return">Monad-of-no-return</a> proposals undoubtedly made the language better, but they also turn programmers looking for answers in the report into involuntary Haskell historians.</p> <p>If the language report were the only Haskell resource available to you, then any non-trivial Haskell 2010 program that you would write is almost guaranteed to be incompatible with what modern compilers like GHC or MicroHS expect. We can, and should, fix that.</p> <h2 id="how-to-get-the-cost-benefit-tradeoff-right">How to Get the Cost-Benefit Tradeoff Right</h2> <p>Writing a new report is a lot of work, and we want to avoid running into the problems that stalled previous attempts of writing one. It is therefore important that we set ourselves a goal that is both achievable and provides a tangible benefit for the Haskell community. The most obvious such goal is to start with a <strong>Revised Haskell 2010 Language Report</strong>:</p> <ul> <li>A revised report is eminently achievable: We have a very clear "todo list" in the documented discrepancies in the user guide (<a rel="noopener external" target="_blank" href="https://downloads.haskell.org/ghc/latest/docs/users_guide/bugs.html">GHC User Guide: Bugs and Infelicities</a>). Most of these listed discrepancies are already well-documented in the accepted proposals that lead to them.</li> <li>None of the changes that we have to implement are likely to be contentious: They reflect the Haskell that we are already writing today. Since the required changes are not contentious, we can use a lightweight decision process in the compilation of the revised report.</li> <li>There is a clear benefit for the community: The most important piece of our reference documentation is no longer outdated. We can refer people to the Haskell report without having to warn them to stay clear of parts of the report that no longer hold true.</li> <li>Since we don't define a new Haskell version with a new feature set, but only a revised version of a previous report, we don't generate any churn for the ecosystem or compiler writers. Taking inspiration from Tolkien who rewrote the Hobbit after he came up with the story of the Lord of the Rings, we can <a rel="noopener external" target="_blank" href="https://en.wikipedia.org/wiki/Retroactive_continuity">retcon</a> the report and pretend that the revised report is what we meant by <code>Haskell2010</code> all along. We can then simplify the GHC user guide and remove most of its section 16 which documents infelicities compared to the existing report.</li> </ul> <p>So here is the a target that we can set for ourselves: Every program that is valid according to the revised Haskell 2010 language report will be accepted by MicroHS and GHC using the <code>Haskell2010</code> language edition.</p> <h2 id="let-s-talk-technicalities">Let's Talk Technicalities</h2> <p>With the motivation and goal out of the way, let us discuss some technical details when it comes to working on the report, building it, and generating the final PDF and HTML documents.</p> <p>The Haskell 2010 language report is available both as a PDF and HTML document, and there are no obvious good reasons to change this. Working on a document of the complexity and length of the Haskell report can be made joyful if the authoring technology is right, and arduous if we are struggling with long compile times (Compiling long-ish PDFs with LaTeX can take minutes using the wrong tools and packages!), inscrutable error messages or a difficult scripting and programming model.</p> <p>The previous version of the Haskell report was written using a combination of command line tools (<code>sed</code>, <code>awk</code>, <code>perl</code>, <code>make</code>), a lexer/parser for preprocessing a custom <code>.verb</code> file format, <code>pdflatex</code> to compile the PDF, and <code>tex4ht</code> to generate HTML. In 2026 we can use technology that was not available in 2010 and simplify the process of authoring the report significantly. Of the available technologies, the <a rel="noopener external" target="_blank" href="https://typst.app/">Typst</a> typesetting system currently satisfies the constraints the best:</p> <ul> <li>It is open-source software available under the Apache 2.0 license. (An associated cloud service similar to Overleaf is proprietary, but entirely optional.)</li> <li>Typst is implemented in Rust and has compile times that are roughly an order of magnitude faster than tex. This allows to get instantaneous visual feedback when working on the report.</li> <li>Both PDF and HTML output is supported natively, with no need to use separate tools.</li> <li>The compiler emits fantastic error messages which point to the erroneous location in the code.</li> <li>Simpler technologies (like plain Markdown) also allow to target multiple output formats, but they lack the advanced features to generate high-quality technical documentation, especially when it comes to the typesetting of mathematics and complex figures.</li> </ul> <p>Using Typst means we have to convert the report from the custom <code>.verb</code> format to <code>.typ</code> files; fortunately this part of the work is completed, and the report can be compiled using a simple <code>typst compile</code> invocation. (The translation process did not involve LLMs, and was done manually using some <code>sed</code> and <code>awk</code> magic to facilitate the process.) Re-typesetting the BNF grammars also allowed to make them hyperlinked: It is now possible to navigate the grammar by clicking on non-terminal symbols and to jump to their definition.</p> <h2 id="documenting-the-standard-libraries">Documenting the Standard Libraries</h2> <p>The existing Haskell 2010 report consists of two parts: The first part documents the syntax and semantics of the language, and the second part documents the standard libraries. Documenting the standard libraries is an essential part of the report, because many aspects of the language can only be defined in terms of functions, types and type classes available in the libraries. For example, numeric literals are polymorphic and have to be defined in terms of the numeric hierarchy, do-notation has to be defined in terms of the Monad (and MonadFail) type classes, and the foreign function interface (FFI) makes extensive use of functions and types defined in the <code>Foreign.*</code> namespace.</p> <p>Maintaining hundreds of pages of standard library documentation in purely textual form (either as LaTeX or Typst files), and ensuring that they remain valid Haskell and consistent with each other is very hard. If we want to avoid typos and inconsistencies sneeking into the report, and if we want to keep the library specification maintainable, then we have to organize it in some form which is amenable to machine checking. The obvious solution is to document the API of the standard libraries using Haddock. The repository for the revised report contains a cabal package which exposes the precise API specified in the Haskell 2010 language report. (This package only specifies the public API: The functions and methods themselves do not have an implementation. A possible stretch goal would be to use tools like <code>api-diff</code> or <code>print-api</code> (<a rel="noopener external" target="_blank" href="https://discourse.haskell.org/t/maintain-a-golden-test-of-your-packages-api-with-diff-package-api-and-print-api/9997">Link</a>) to ensure that the API exposed by packages like <code>base</code> is a strict superset of the API defined in the report.)</p> <h2 id="what-process-shall-we-use">What Process Shall we Use</h2> <p>The Haskell Prime process worked using a combination of mailing list discussions and a Git repository which collected RFCs. Notably, the process did not work directly on the source code used for building the report. We can reduce a lot of the overhead by switching to a collaboration process that is modelled more closely on how we develop code: Changes to the report should primarily be discussed in the form of pull requests to the textual sources of the report itself. The repository to organize the writing of the report is now public: <a rel="noopener external" target="_blank" href="https://github.com/haskellfoundation/haskell-2010-revised-report">github.com/haskellfoundation/haskell-2010-revised-report</a>. Please start contributing by discussing the existing issues, by contributing new issues, and by helping fix issues with the technical infrastructure. We will not yet merge any actual changes to the report, since these changes will need to be confirmed by the new language committee that will be established, but we can start working on all other technical issues.</p> <h2 id="call-to-action">Call to Action</h2> <p>In order for the revised Haskell 2010 report to enjoy broad support from the community, we have established a new <a rel="noopener external" target="_blank" href="https://gitlab.haskell.org/hf/meta/-/blob/main/working_groups/revised-haskell-2010-report.md">working group</a> under the umbrella of the Haskell Foundation. We now need your help and participation, ideally by deciding to become a member of the working group tasked with compiling the revised report. If you do not want to become a member of the working group you can still join all the discussions in the repository, contribute issues, and open pull requests with changes to the report, but becoming a member gives you the right to cast your vote on which changes to the report shall be adopted.</p> <p>We will shortly be announcing a call to join the working group on the <a rel="noopener external" target="_blank" href="https://discourse.haskell.org/">Haskell Discourse</a>, and soon thereafter start the work on the revised report. If you always wished for Haskell to get a new report, or were discouraged by the lack of progress when it comes to standardization, now is your chance to contribute! With the clearly delimited scope set out above we can also be confident that the finish line is clearly in sight. And who knows, if the revised report is a clear success we might even have the appetite to follow up with something more ambitious...</p> 2026-07-28T00:00:00+00:00 2026-07-28T00:00:00+00:00 Unknown https://blog.haskell.org/quick-tips-for-fast-iteration-in-haskell/ <h2 id="introduction">Introduction</h2> <p>The Haskell community has recently been discussing how to achieve fast iteration times when type checking and compiling Haskell code. Fast feedback has always been important in software development, and we're seeing increased interest in the topic in recent months due to the rise in prominence of agentic coding.</p> <p>This article describes two techniques for fast iteration: using <code>ghci</code> to get fast feedback on the result of type checking an compilation, and speeding up builds with a careful choice of flags to <code>ghc</code> and <code>cabal</code>. These techniques can be run on any existing codebase. They don't require you to restructure your code in any way, so you can get an instant improvement to your iteration times. Let's dive in!</p> <h2 id="ghci-based"><code>ghci</code>-based</h2> <p>GHCi is <a rel="noopener external" target="_blank" href="https://ghc.gitlab.haskell.org/ghc/doc/users_guide/ghci.html">GHC's interactive interpreter</a> (executable name <code>ghci</code>) which comes bundled with every installation of GHC. It is a REPL ("<a rel="noopener external" target="_blank" href="https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop">read-eval-print loop</a>"), which means you can type expressions into it and it will run them, printing the result. <code>ghci</code> is a good starting point for fast feedback because it doesn't have to fully compile code, rather it generates executable bytecode and skips machine code generation, making it inherently faster than a normal build.</p> <p>There are a variety of ways to use <code>ghci</code>, from using barebones <code>ghci</code> itself directly to featureful wrappers.</p> <h3 id="ghci-itself"><code>ghci</code> itself</h3> <p>You can invoke <code>ghci</code> with a collection of source paths and it will compile and load those modules, for example:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>ghci src/Path/Module1.hs src/Path/Module2.hs</span></span></code></pre> <p>Or, perhaps more useful, use a <code>ghci</code> invocation wrapper that comes with your build tool, <code>cabal</code> or <code>stack</code>:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>stack ghci</span></span> <span class="giallo-l"><span>cabal repl</span></span></code></pre> <p>For a simple <code>ghci</code> workflow, make some changes to the files in your project, then navigate to your <code>ghci</code> window and type <code>:reload</code> (or <code>:r</code> for short). <code>ghci</code> will type check and compiles your changes, printing any errors or warnings from GHC. Simple!</p> <p>You might feel that continually typing <code>:r</code> ought to be automated away. If so then check out the next section on <code>ghcid</code>.</p> <h3 id="ghcid"><code>ghcid</code></h3> <p><a rel="noopener external" target="_blank" href="https://github.com/ndmitchell/ghcid"><code>ghcid</code></a> is a wrapper around <code>ghci</code> that automates issuing <code>:r</code> when any file in your project changes, so its workflow is even easier than that of <code>ghci</code>: make some changes to the files in your project and then merely <em>look at</em> your <code>ghcid</code> window; <code>ghcid</code> will have detected your changes and the result of type check and compilation will appear automatically.</p> <h4 id="automatically-running-tests">Automatically running tests</h4> <p><code>ghcid</code> also allows you to get more quick feedback than just the result of type checking and compilation: you can run tests (or indeed any code) when your source files change. There are two ways to do this:</p> <ol> <li> <p>Embed comments with expressions to be evaluated. For example add this comment to a source file to evaluate <code>expr</code> after loading:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>-- $&gt; expr</span></span></code></pre> <p>(Evaluating embedded comment expressions requires using the <code>--allow-eval</code> flag.)</p> </li> <li> <p>Pass an expression to the command line option <code>--test</code>, to run after the code is loaded successfully, for example:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>ghcid --test myTestFun</span></span></code></pre> <p>(By default the test expression will only run if the code is warning-free. To run the test expression even if there are warnings, also pass <code>--warnings</code>.)</p> </li> </ol> <p>For more information on these features, see the <a rel="noopener external" target="_blank" href="https://github.com/ndmitchell/ghcid#evaluation">Evaluation</a> section of the <code>ghcid</code> README.</p> <h4 id="installation">Installation</h4> <p><code>ghcid</code> is a normal executable package on Hackage, so you can install it with, for example, <code>cabal install ghcid</code>.</p> <h3 id="ghcid-check"><code>ghcid-check</code></h3> <p>One limitation of <code>ghcid</code>'s default behaviour is that it is not <em>programatic</em>. When you change source files, <code>ghcid</code>'s updates appear in the terminal in which it is already running. That's no good if you want to give fast feedback to a coding agent; ideally the coding agent would run a command line executable to obtain the feedback.</p> <p>That's fine, because <code>ghcid</code> supports that too, with its <code>--reload</code> and <code>--outputfile</code> options. But setting that up is a little fiddly, so here's a simple <code>ghcid</code> wrapper <code>bash</code> script called <code>ghcid-check</code>:</p> <ul> <li><a rel="noopener external" target="_blank" href="https://github.com/tomjaguarpaw/ghcid-check/">https://github.com/tomjaguarpaw/ghcid-check/</a></li> </ul> <p><code>ghcid-check</code> is very basic and you might want to customize it to meet your own particular needs.</p> <p>Beyond <code>ghcid</code>, there are another couple of projects based on a similar idea that bring new features: <code>ghciwatch</code> and Tricorder.</p> <h3 id="ghciwatch"><code>ghciwatch</code></h3> <p><a rel="noopener external" target="_blank" href="https://github.com/mercurytechnologies/ghciwatch#ghciwatch"><code>ghciwatch</code></a> is an updated take on <code>ghcid</code>, from the Haskell developers at <a rel="noopener external" target="_blank" href="https://mercury.com/blog/topics/engineering-blog">Mercury</a>. Compared to <code>ghcid</code> it has more sophisticated checking for new, removed and new modules, which sometimes trip up <code>ghcid</code>, as well as other new features.</p> <h3 id="tricorder">Tricorder</h3> <p><a rel="noopener external" target="_blank" href="https://github.com/tweag/tricorder#tricorder">Tricorder</a> is from Tweag and provides even more live status and diagnostic updates than <code>ghcid</code> or <code>ghciwatch</code>, including access to documentation and machine-readable output, and is designed from the ground up to be usable programatically by coding agents as well as interactively by humans.</p> <p>Check out the <a rel="noopener external" target="_blank" href="https://discourse.haskell.org/t/ann-tricorder-a-new-development-tool-for-haskell-and-llms/14208">announcement post</a> on the Haskell Discourse, which includes a short video of Tricorder functionality. <code>tricorder</code> is a normal executable package on Hackage, so you can install it with, for example, <code>cabal install tricorder</code></p> <h2 id="cabal-based"><code>cabal</code>-based</h2> <p>Let's now see how to speed up development builds using the <a rel="noopener external" target="_blank" href="https://www.haskell.org/cabal/"><code>cabal</code></a> build system. <code>cabal</code> has existed for a very long time, and you may be surprised by some of the things it offers!</p> <p>Speeding up development builds using <code>cabal</code> involves three broad optimizations:</p> <ul> <li>Tuning GHC's runtime options;</li> <li>Decreasing the amount of work <code>cabal</code> and GHC have to do by disabling compile-time optimizations;</li> <li>Increasing resource-sharing for more effective build parallelism.</li> </ul> <p>Before we describe the build optimizations above, it is worth understanding how cabal can be configured. Cabal uses <em>project</em> files to bundle configuration options related to multiple packages. The default configuration file, which is picked up automatically by <code>cabal</code>, is <code>cabal.project</code>. A typical <code>cabal.project</code> file for a project with three packages looks like:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>packages:</span></span> <span class="giallo-l"><span> packageA</span></span> <span class="giallo-l"><span> packageB</span></span> <span class="giallo-l"><span> packageC</span></span></code></pre> <p>Recent versions of cabal allow project files to import other projects files. Therefore, without changing our default <code>cabal.project</code> file, we'll create a new configuration file specifically for development builds. Let's call it <code>cabal.fast.project</code>:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>import: cabal.project</span></span></code></pre> <p>As we go through build optimizations below, we'll append to our <code>cabal.fast.project</code>. Then, a fast build will specify to use <code>cabal.fast.project</code>:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="shellscript"><span class="giallo-l"><span style="color: #4078F2;">$</span><span style="color: #50A14F;"> cabal build all</span><span style="color: #986801;"> --project-file=cabal.fast.project</span></span></code></pre> <p>That way, we have an easy set-up for fast builds. We could have project files for profiling builds, release builds, etc.</p> <p>Running the above command, we got a baseline compilation time on a private, commercial Haskell codebase of more than 150 000 lines of Haskell code. As we go through build optimizations below, we will report on the speedups achieved from this baseline.</p> <h3 id="tuning-ghc-s-runtime-options">Tuning GHC's runtime options</h3> <p>GHC is a wonderful piece of technology. In some ways, it might as well be from the future. However, compiling Haskell programs into performant executables is hard work, and GHC is itself a Haskell program. This means we must tune its runtime system to squeeze out more performance.</p> <p>Take a look at the <a rel="noopener external" target="_blank" href="https://downloads.haskell.org/ghc/9.14.1/docs/users_guide/runtime_control.html">GHC 9.14.1 user guide's section on runtime control</a>. In our experience, however, simply tuning the garbage collection allocation size is a great first step if your computer is somewhat recent. In particular, increasing the allocation size from the default of 4MB to 64MB, 128MB, er even 256MB may dramatically increase compilation throughput!</p> <p>Thus, we update our <code>cabal.fast.project</code> project file to pass the appropriate flag to GHC. We'll use an allocation area of 64MB, but do experiment on your own workloads:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>import: cabal.project</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>-- Step 1: tuning GHC</span></span> <span class="giallo-l"><span>program-options</span></span> <span class="giallo-l"><span> ghc-options: +RTS -A64m -RTS</span></span></code></pre> <p>Building with the above project file, we achieve a speedup of approximately 10%. Not huge, but not marginal either. Big gains remain!</p> <h3 id="disabling-compile-time-optimizations">Disabling compile-time optimizations</h3> <p>Even if GHC is given the appropriate resources to do its job more effectively, it still does a lot of work by default, since GHC's default optimization level is <code>-O1</code>. This means that GHC performs <em>some</em> optimizations, which necessarily requires more compilation time.</p> <p>But this is merely the <em>default</em> behavior, and this article is all about speed. Instead, we can disable optimizations via the <code>optimization</code> option in cabal project files:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>import: cabal.project</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>-- Step 1: tuning GHC</span></span> <span class="giallo-l"><span>program-options</span></span> <span class="giallo-l"><span> ghc-options: +RTS -A64m -RTS</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>-- Step 2: disable optimizations</span></span> <span class="giallo-l"><span>optimization: False</span></span></code></pre> <p>Note that this optimization flag only applies to your locally-built packages. Your third-party dependencies will be compiled using the default optimization level, <code>-O1</code>. This is generally considered acceptable since your third-party dependencies are rarely built, and it allows you to re-use them for other build profiles.</p> <p>At this stage, the codebase is building 2x faster!</p> <h3 id="better-resource-sharing-for-build-parallelism">Better resource-sharing for build parallelism</h3> <p>We've tuned GHC, and minimized the amount of work it needs to do. What is left is speed up the build across <em>multiple packages</em>.</p> <p><code>cabal</code> has an option for parallel builds called <code>--jobs</code>. You can either specify a number of capabilities to dedicate to the build (e.g. <code>--jobs=2</code>), or let <code>cabal</code> decide based on your hardware (using a bare <code>--jobs</code>). Higher is not <em>always</em> better; this depends on your build graph!</p> <p>In our experience, a number from 4 - 8 is appropriate to start with. We therefore update our <code>cabal.fast.project</code> project file:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>import cabal.project</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>-- Step 1: tuning GHC</span></span> <span class="giallo-l"><span>program-options</span></span> <span class="giallo-l"><span> ghc-options: +RTS -A64m -RTS</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>-- Step 2: disable optimizations</span></span> <span class="giallo-l"><span>optimization: False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>-- Step 3: build parallelism</span></span> <span class="giallo-l"><span>jobs: 6</span></span></code></pre> <p>We can do even better! If you use <code>cabal</code> 3.12+ in combination with GHC 9.8+, you can take advantage of a new flag, <code>--semaphore</code>, which allows <code>cabal</code> to share resources better with GHC. While <a rel="noopener external" target="_blank" href="https://well-typed.com/blog/2023/08/reducing-haskell-parallel-build-times/">Well-Typed has a full breakdown of the why and how</a>, we summarize the result here. In short, if cabal can take advantage of multiple parallel invocations of GHC, it will do so; however, under the <code>--semaphore</code> option, if cabal <em>cannot</em> take advantage of all the cores it was allocated, it can tell GHC to use more cores. This can result in compilation time reductions of up to 30%!</p> <p>We update our <code>cabal.fast.project</code> one final time:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>import: cabal.project</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>-- Step 1: tuning GHC</span></span> <span class="giallo-l"><span>program-options</span></span> <span class="giallo-l"><span> ghc-options: +RTS -A64m -RTS</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>-- Step 2: disable optimizations</span></span> <span class="giallo-l"><span>optimization: False</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>-- Step 3: build parallelism</span></span> <span class="giallo-l"><span>jobs: 6</span></span> <span class="giallo-l"><span>semaphore: True</span></span></code></pre> <p>Finally, our builds will be much faster:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="shellscript"><span class="giallo-l"><span style="color: #4078F2;">$</span><span style="color: #50A14F;"> cabal build all</span><span style="color: #986801;"> --project-file=cabal.fast.project</span></span></code></pre> <p>Compared to our baseline, we achieve a cumulative build speedup of 2.6x!</p> <h2 id="going-further">Going further</h2> <p>If you're eager for even more build time improvements and are willing to spend time adjusting the structure of your codebase, we can point you where to look next: watch of Teo Camarasu's talk at the 2026 Haskell Ecosystem Workshop, <a rel="noopener external" target="_blank" href="https://www.youtube.com/watch?v=nmE6aa_I5TU">Optimising for fast builds with GHC</a>.</p> <h2 id="conclusion">Conclusion</h2> <p>We hope you enjoyed our brief tour of using <code>ghci</code> and <code>cabal</code> for fast iterative development in Haskell. If you have any comments or questions, or have your own tips and techniques you can share with the community, then please post on <a rel="noopener external" target="_blank" href="https://discourse.haskell.org/">the Haskell Discourse</a>.</p> <h2 id="references">References</h2> <p>Lots of people have already written up their experience of workflows that <code>ghci</code>, including for fast iterative development. You might want to check them out.</p> <ul> <li><a rel="noopener external" target="_blank" href="https://ghc.gitlab.haskell.org/ghc/doc/users_guide/ghci.html">Using GHCi — GHC Users Guide</a></li> <li><a rel="noopener external" target="_blank" href="https://haskellweekly.news/episode/6.html">Fast Feedback</a></li> <li><a rel="noopener external" target="_blank" href="https://academy.fpblock.com/blog/2018/08/haskell-development-workflows-4-ways/">Haskell Development Workflows (4 ways)</a></li> <li><a rel="noopener external" target="_blank" href="https://www.parsonsmatt.org/2018/05/19/ghcid_for_the_win.html">ghcid for the win!</a></li> <li><a rel="noopener external" target="_blank" href="https://functor.tokyo/blog/2019-04-07-ghcid-for-web-app-dev">ghcid for Web App Development</a></li> <li><a rel="noopener external" target="_blank" href="https://mercury.com/blog/announcing-ghciwatch">Announcing ghciwatch 1.0</a></li> <li><a rel="noopener external" target="_blank" href="https://jeancharles.quillet.org/posts/2024-09-04-Haskell-dev-workflow-with-ghcid-and-neovim.html">Haskell dev workflow with ghcid and neovim</a></li> <li><a rel="noopener external" target="_blank" href="https://www.well-typed.com/blog/2023/03/cabal-multi-unit/">Multiple Component support for cabal repl</a></li> <li><a rel="noopener external" target="_blank" href="https://github.com/alexfmpe/semantic-satiation/blob/main/posts/002-cheaper.md">Cheaper: producing a program with less developer time</a></li> <li><a rel="noopener external" target="_blank" href="https://hackage.haskell.org/package/rapid/docs/Rapid.html">Rapid</a></li> </ul> 2026-07-16T00:00:00+00:00 2026-07-16T00:00:00+00:00 Unknown https://blog.haskell.org/enterprise-haskell-at-h-e-b/ <p><em>This article is the second installment of our series "<a href="/categories/haskellers-from-the-trenches/">Haskellers from the trenches</a>", where we invite experienced engineers to talk about their subjects of expertise, best practices, and production tales with Haskell</em></p> <h2 id="the-mainframe-problem">The mainframe problem</h2> <p>When I joined <a rel="noopener external" target="_blank" href="https://www.heb.com">H-E-B</a> back in 2018, I was entering a world far removed from any of my previous roles in technology. H-E-B is a <em>retail</em> company first, and the largest privately held company in Texas. Our customers care about full shelves, not the systems behind them, and for decades those systems delivered: rock-solid COBOL mainframes doing their job reliably, day in and day out. Reliability like that is no small thing. But customer expectations have shifted. Curbside pickup, home delivery, real-time inventory, in-store search, and many other tech-heavy features have really only emerged in the last 10 years, and meeting that demand means scaling supply chain operations across 435+ stores and the distribution centers that feed them. That kind of growth asks more of our core systems than they were originally designed to give, especially as the grocery business turns more digital and more competitive by the year.</p> <p>It's no secret that a lot of the world still runs on mainframes. There's usually little incentive to spend the capital on a massive lift-and-shift into the cloud when current systems maintain the status quo well enough. Copying code from one machine to another is hardly the real challenge here. Usually these kinds of projects fail to deliver because they lack the bespoke institutional knowledge encoded in decades of legacy business logic. How do you take a monolithic application operating on hundreds of tables and split it out into microservices, owned and operated by their own autonomous engineering teams? It's both a technological and political undertaking of enormous proportions, and an expensive one. Whatever product comes out on the other end, you can bet that the business owners don't want to repeat this process ever again.</p> <h2 id="enter-the-lambda">Enter the lambda</h2> <p>Haskell was originally pitched by consultants as the lingua franca for a new initiative to replace the largest mainframe application in the company. I came onto this new project in its infancy, ready and giddy to use Haskell on a real-world project with real-world impact. What started as an experiment grew into multiple production systems now running critical supply chain applications. Eight years on, those systems are still in production, with nearly a million lines of Haskell maintained by several teams across different domains. So there have been real successes, but also real struggles. I hope that my experience on these projects can translate into some valuable lessons for those who wonder about or may already be running Haskell programs in production.</p> <h2 id="why-haskell">Why Haskell?</h2> <p>Pitching a programming language as a business solution is an uphill battle. Haskell is not known for being an enterprise language, and while it thrives in programming-language research, it lost the foothold it once had in the intro course, despite Dijkstra's famous defense of it over Java in his <a rel="noopener external" target="_blank" href="https://www.cs.utexas.edu/~EWD/transcriptions/OtherDocs/Haskell.html">letter to the UT Austin Budget Council</a>. But "enterprise language" says more about market forces than language design. The same momentum that filled the intro course with Java fills the hiring pool and the vendor SDK lists, and nearly all of that momentum belongs to imperative languages, deemed easier to hire for, and these days, easier to prompt for. The enterprise cares not for laziness, pure functions, immutable data, or anything that weighs lambda calculus against object-oriented orthodoxy. The enterprise just wants another COBOL: a system that runs for 40 more years without null-pointer exceptions and with a lower maintenance burden. I firmly believe that Haskell fits into this niche. But it's not trivial to translate the benefits of a souped-up polymorphic lambda calculus and software-transactional memory into a business case.</p> <p>So what's my pitch?</p> <p>I can tell our CTO that a Haskell application will suffer fewer classes of runtime failure by default, ruling out the whole category of bugs that imperative and dynamically typed programs encounter on a daily basis. There will still be bugs, but the ones that remain tend to be the interesting ones in our business logic, rather than null-pointer exceptions and type confusion.</p> <p>In the face of multi-year strangler fig migrations of legacy systems, I can tell Haskell developers that <em>it's ok to make mistakes</em>. They can iterate while the business requirements are still taking shape, because GHC gives them the tools for painless refactoring. That freedom is what lets a migration run like an agile project instead of a waterfall. The business measures results incrementally, rather than paying up front for an incorrect, crystallized product that will be abandoned in a year.</p> <p>Integrating with legacy systems is bread-and-butter work for Haskell programs. By chance do you need to parse thousands of lines of fixed-width IBM copybooks? Parsers in Haskell are best in class. A legacy system that can't easily emit XML or JSON doesn't have to, because its native format becomes the contract. Need to hook into old services that only offer C libraries? Haskell has one of the best foreign-function interfaces in the game. We've written Haskell libraries around simdjson (C++), Oracle's ODPI-C, and IBM's MQ, to name a few.</p> <p>The dearth of Haskell SDKs in the wild looks like a showstopper at first. In practice, you take on the maintenance burden forever, and in exchange you own your contracts outright, avoid vendor lock-in, and never wait on an upstream maintainer to ship a fix. For critical dependencies, we've found that trade well worth making. Today the velocity gap is narrower than it looks, since porting your favorite Go library to Haskell is the kind of mechanical work a coding agent does well. Unfortunately, rote translations like that may not take full advantage of the type system without clever prompting.</p> <p>There's a subtler advantage that makes Haskell a compelling core enterprise language: its strength as a host for embedded DSLs. A central team can encode a domain model or business logic once in a Haskell eDSL and generate safe, typed code in whatever language other teams already use, letting them hook into your system without ever writing Haskell themselves. <a rel="noopener external" target="_blank" href="https://github.com/CategoricalData/hydra">Hydra</a>, an open-source project that grew out of graph-data work at Uber, is a striking example. It's a Haskell-bootstrapped DSL framework that generates semantically-equivalent implementations across Java, Python, Scala, and more, with a shared test suite guaranteeing parity. You keep Haskell's correctness guarantees at the source while meeting every other team where they already are.</p> <p>We've explored this embedded DSL idea in various ways at H-E-B. In one case, we prototyped a Haskell DSL for sensitive financial calculations that could be shared across our Haskell, TypeScript, and Java teams. In another, we built a Haskell DSL for bidirectional JSON schemas, similar in spirit to the <a rel="noopener external" target="_blank" href="https://hackage.haskell.org/package/autodocodec">autodocodec</a> library, but using a tagless final encoding that allows users to extend the core semantics with their own type classes. It lets our Haskell teams standardize on schema versioning strategies, documentation/OpenAPI generation, and regression/golden testing. For anything else, developers can write ad-hoc interpreters, e.g. converting a JSON schema to a PostgreSQL table definition, swapping in <code>simdjson</code> for <code>aeson</code>, or layering on additional validation.</p> <p>I could go on about what Haskell offers programmers in the way of type safety, purity, and elegant concurrency, but these days most modern languages offer many of the same features (some of them inspired by Haskell itself). The difference lies in the kind of engineering culture the language promotes. Ian Duncan's <a rel="noopener external" target="_blank" href="https://blog.haskell.org/a-couple-million-lines-of-haskell/">post</a> covers this territory well, and I risk parroting it here. Suffice to say, his general advice holds. Haskell attracts idealists who care about correctness and think carefully about the abstractions they build with. Hiring for a Haskell role has never been the problem that leaders think it will be. If anything, candidates came to us for the Haskell itself, even when they had no particular interest in supply chain.</p> <h2 id="why-not-haskell">Why not Haskell?</h2> <p>Let's get real for a little bit. Haskell has been around for a long time, it has warts, and it really pays to stay current with the latest GHC releases. Without an expert on your team, all it takes is one wart to fester and infect the entire project. In the beginning, we were fortunate to have consultants with extensive Haskell experience. We were prescribed guardrails and some basic rules to ensure we didn't get overwhelmed by language extensions and custom operator line noise.</p> <p>Back in those days we didn't yet have the GHC2021 or GHC2024 language editions, so a sane baseline of extensions was something each team had to curate by hand. That baseline was really a complexity budget - a cap on how much language a new hire has to absorb before they can contribute. And enforcing it turns out to be a losing game, because your dependencies spend the budget for you. Once you pull in something like <code>servant</code> or <code>haxl</code>, you've just blown through the whole budget on what the business sees as plumbing. Serving web requests with <code>servant</code> means encoding your API as a type-level DSL, and extending it with your own combinators drags in type families and the inscrutable errors that come with them. Batching concurrent operations with <code>haxl</code> means modeling every data source as a GADT indexed by its result type. These are elegant designs, but they are not free.</p> <p>As beginners become adepts and adepts become veterans, the perception of a complexity budget begins to fade. More advanced features become tempting to use, and their adoption weakens our promise to the business of easy maintainability. New hires need to understand GADTs, type families, generics, tagless final encodings, arrows, free structures, higher-kinded data type patterns, and other shenanigans on top of an already dense business domain. It wasn't that we started out wanting to use all of these advanced patterns and features of the language, nor could we really. Their viability emerged over time as engineers became more familiar with the ecosystem. And that gradual creep can really sneak up on you.</p> <p>"Boring" Haskell is easier to preach than to enforce at an organizational level. We engineers get, well, bored, and we are often tempted to leverage GHC features for problems that may not warrant them. The key point here is an intentional echo from Ian's post, which is that encapsulating advanced Haskell behind sane interfaces reduces the blast radius and scopes your complexity budget to smaller libraries maintained by a handful of experts. The risk of exploding complexity at the language level is hardly unique to Haskell, but few languages offer so much rope. The business may measure complexity in lines of code or tokens spent, but a better gauge for a Haskell project is how much of it will break with the next GHC upgrade.</p> <h2 id="trials-by-fire">Trials by fire</h2> <p>A sobering truth is that not all teams are created equal. Haskell can empower one team while disempowering another. If this were not true, we would have more Haskell teams than we do today. I've had to watch Haskell fail to stick on two separate projects, and for seemingly unrelated reasons. In one case, a nasty space leak brought the entire program to a halt. This was a team of seasoned developers with no Haskell experience at all, using a project template copied from a sibling team. They were simply hoping to follow the conventions they inherited, but without a strong Haskell developer to guide them along, the space leak was enough to kill the entire endeavor. In the other case, the engineers who advocated for Haskell and built the applications left to work on other projects - priorities shifted, nothing to do with the language.</p> <p>In both cases a fallback option was always available. Engineers gravitated back to what they wrote before Haskell, unconvinced that it was making them more productive. This is the consequence of viewing Haskell as just another means to an end, as just another programming language. The engineers learned the language well enough. They just never found a passion for it. Ultimately, as saccharine as it may sound, this is the differentiator for a successful Haskell project in the enterprise. Nobody will be motivated to diagnose a space leak if there's an escape hatch to a Spring Boot template, and now that LLMs can mechanically translate whole codebases, that escape hatch is wider than ever. No codebase is too clever to rewrite, so the only real defense is to build a team that would rather keep the Haskell.</p> <p>Even on teams that embrace Haskell, there were some harrowing moments that made us reflect on our choices. We ran into double-free errors stemming from <a rel="noopener external" target="_blank" href="https://github.com/hdbc/hdbc-postgresql/pull/52">custom reference counting logic</a>, and we disabled parallel garbage collection on one project because it was the only thing that fixed a runaway space leak. In the worst case, <a rel="noopener external" target="_blank" href="https://github.com/iand675/datadog/pull/33">infinite loops</a> are one of the scariest bugs simply because <a rel="noopener external" target="_blank" href="https://discourse.haskell.org/t/debugging-program-with-infinite-loop-somewhere/13111">finding them is hard</a>.</p> <p>The GHC runtime itself has never been the root cause of a production outage for us. In steady state, its throughput and memory footprint have been more than competitive for our workloads, and the war stories above were exceptions rather than the norm. What matters here is that engineers were able to fix these problems by tracing through segfault core dumps, garbage collection metrics, and heap profiles. A crucial lesson learned is that test coverage cannot be sacrificed in the name of a strong type system. In fact, I wager that Haskell applications are prime candidates for chaos engineering. Because whole categories of trivial errors are compiled away, injecting infrastructure faults surfaces the genuine logic and resource failures of your system instead of the noise that would dominate a dynamically typed program.</p> <h2 id="times-have-changed">Times have changed</h2> <p>When we started building our systems, we were on GHC 8.2. We had to write most of our own API clients and SDKs for popular platforms. The Haskell language server did not exist. GHCup was brand new. Profiling the runtime was a dark art. If you'd asked me back then whether Haskell would increase velocity, I'd have had some caveats. The business wants everything off the shelf, it doesn't want to pay to reinvent wheels, and we had to spend resources on building what we needed. Developers coming from their Java IDEs recoiled at the state of Haskell tooling. H-E-B even went so far as to sponsor development of Debug Adapter Protocol support for Haskell (for VS Code users).</p> <p>But now, after years of hard work on GHC and across the ecosystem, building production-grade Haskell applications has gone from merely viable to genuinely competitive.</p> <p>For tooling we have HLS, <code>ghcid</code>, <code>ghciwatch</code>, <code>static-ls</code>, <a rel="noopener external" target="_blank" href="https://github.com/atelier-hub/tricorder">tricorder</a>, and first-class code editor plugins for Haskell. Some of us at H-E-B use GHC plugins to facilitate richer GHCi-driven development, while some of us use VS Code and HLS, and we cherish the freedom of developers to use their preferred tools.</p> <p>For observability we now have <code>hs-opentelemetry</code>, and we use <a rel="noopener external" target="_blank" href="https://github.com/aaronallen8455/opentelemetry-auto">opentelemetry-auto</a>, a GHC plugin that autoinstruments Haskell functions with OTel spans. If the business says they'd prefer Java or Python for their instrumentation story, we can point at this and say Haskell has the same story.</p> <p>The library shelf has filled out as well. Our services run on workhorses like <code>warp</code>, <code>aeson</code>, <code>attoparsec</code>, <code>stm</code>, <code>conduit</code>, <code>servant</code>, and <a rel="noopener external" target="_blank" href="https://hackage.haskell.org/package/orville-postgresql">orville-postgresql</a>. Where we find gaps, we write our own. For example, <a rel="noopener external" target="_blank" href="https://github.com/velveteer/arbiter">arbiter</a>, a transactional PostgreSQL job queue I maintain, was born from our work at H-E-B and runs in production today.</p> <p>All of this means developers and operations can both stop shuddering when someone says "this application uses Haskell". It's only getting better as GHC improves its own runtime diagnostics, compiler performance, monitoring features (e.g. eventlog streaming), and <a rel="noopener external" target="_blank" href="https://well-typed.com/blog/2026/05/lay-annotation-land/">exception annotations</a>. For the record, I haven't feared a space leak since info table profiling landed in GHC 9.2.</p> <h2 id="haskell-culture">Haskell culture</h2> <p>Internal libraries matter a great deal in our organization, and we encourage developers to work on both internal and open-source projects. We've been running a Haskell meetup every other week for years, hoping to attract interest across the company, sometimes succeeding. The meetups serve as an open forum for engineers to share their own Haskell explorations and teach others. Cross-pollination of ideas and patterns matters, because silos are everywhere in the enterprise. This is also our answer to the bus-factor risk. The more engineers who can read and own a codebase, the less any single departure can sink it.</p> <p>How do we empower developers while simultaneously advocating for boring Haskell? Certainly we set some loose ground rules, but tech leads make the final decisions on how to spend their complexity budgets. If a team must store PII encrypted at rest, it will likely pay off to add type-level guarantees that make leaking sensitive data a compile error rather than a runtime incident, the kind of assurance security reviews actually care about. If a team is tiring of boilerplate and wants to consolidate four API contracts using a trees-that-grow pattern, it may not be worth obscuring the public-facing schemas with type families.</p> <p>For us, boring Haskell doesn't preclude type-level programming or advanced GHC features. It's more that we establish principled conventions and weigh the costs of straying from them. A big one is "no spooky action at a distance", e.g. no <code>TemplateHaskell</code> code generation, no <code>Generic</code>-derived serialization logic, etc. The convention in this case is to write boilerplate and keep everything explicit for the programmer. It's not as draconian as it sounds, since teams who want quasiquoters and deriving via <code>Generically</code> are not forbidden outright. We want healthy skepticism when an engineer implements the type-level state machine for a web form, or reaches for a GADT when a regular ADT would do. An engineer can argue that their complexity is essential, but it takes the whole team, and a culture where pushback is welcome, to spot when it's accidental.</p> <p>That said, there's plenty of advanced Haskell across our projects in both libraries and production applications. I think it goes to show that you don't have to stay bored forever. You just have to limit the scope of your playtime. We use Haskell because we want to work <em>and</em> play, and somewhere in the middle is where engineering happens.</p> <h2 id="the-road-ahead">The road ahead</h2> <p>I am incredibly optimistic about Haskell and GHC's future in industry. Through many years of using GHC we've found and reported a handful of bugs, none of which were game-breaking for us. Production incidents are rare, and the few we do see trace back to business logic far more often than to type errors or the runtime.</p> <p>There's also a new argument forming in Haskell's favor. Coding agents now write a growing share of our code, which shifts the bottleneck from writing code to verifying it, and a compiler like GHC is well suited to that job. The same type system that makes refactoring painless for humans gives an agent a tight feedback loop that rejects hallucinated code before it runs.</p> <p>We need more stories of Haskell's success, and I am grateful that the Haskell Foundation is making the effort to bring them to light.</p> 2026-06-29T00:00:00+00:00 2026-06-29T00:00:00+00:00 Unknown https://blog.haskell.org/overview-of-haskell-security-tooling/

<p>Here is an overview of the Haskell security infrastructure, detailing the security team, the advisory database, the libraries developed for security metadata, and how downstream tools leverage this data.</p>

2026-06-12T00:00:00+00:00 2026-06-12T00:00:00+00:00 Unknown https://blog.haskell.org/making-ghc-upgrades-easy/

<h2 id="what-this-post-is-about">What this post is about</h2> <p>When a shiny new version of GHC comes out, it should be easy to upgrade. After all, the new compiler should be more capable than the previous version!</p>

2026-05-31T00:00:00+00:00 2026-05-31T00:00:00+00:00 Unknown https://blog.haskell.org/contributing-to-haskell-through-a-beginner-s-lens/

<p>October 2025 was when I wrote my first line of Haskell. Fast forward to May 2026, I am consistently contributing to the Haskell Language Server (HLS) and my Google Summer of Code proposal also got accepted. This blog is a mix of my personal experiences along with general learnings that could help beginners to start contributing to Haskell repositories.</p>

2026-04-30T00:00:00+00:00 2026-04-30T00:00:00+00:00 Unknown https://blog.haskell.org/hls-2-14-0-0/ <p>The HLS team is excited to announce the <code>2.14.0.0</code> Haskell Language Server release!</p> <p>You can install it today with GHCup: <code>$ ghcup install hls --set 2.14.0.0</code></p> <h2 id="features">Features</h2> <p>This new HLS version adds support for the <a rel="noopener external" target="_blank" href="https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/template_haskell.html#extension-ExplicitLevelImports"><code>ExplicitLevelImports</code></a> language extension, which was added in GHC 9.14.1 in <a rel="noopener external" target="_blank" href="https://github.com/haskell/haskell-language-server/pull/4846">#4846</a>.</p> <p>HLS now starts up faster in <code>sessionLoading: multipleComponents</code> mode and handles out-of-project files more gracefully thanks to <a rel="noopener external" target="_blank" href="https://github.com/haskell/haskell-language-server/pull/4445">#4445</a>.</p> <p><a rel="noopener external" target="_blank" href="https://github.com/haskell/haskell-language-server/pull/4791">#4791</a> adds lots of great quality of life improvements when using Notes such as hover information and autocompletions for note references and declarations.</p> <p>Additionally, this version introduces smart-case matching when completing modules and file paths in cabal files.</p> <p>As of <a rel="noopener external" target="_blank" href="https://github.com/haskell/haskell-language-server/pull/4621">#4621</a> is now able to recognise file types based on the provided language kind instead of by file ending only.</p> <h3 id="some-notable-bug-fixes">Some notable bug fixes</h3> <ul> <li>HLS will now only show linear arrows when the LinearTypes language extension is enabled <a rel="noopener external" target="_blank" href="https://github.com/haskell/haskell-language-server/pull/4862">#4862</a>.</li> <li>HLS will no longer offer 'Add Argument' for identifiers which include qualified names <a rel="noopener external" target="_blank" href="https://github.com/haskell/haskell-language-server/pull/4852">#4852</a>.</li> <li>When expanding nested records, HLS will now expand the record the cursor is pointing to instead of the outermost one <a rel="noopener external" target="_blank" href="https://github.com/haskell/haskell-language-server/pull/4813">#4813</a>.</li> <li>HLS now names the code action for <code>record syntax conversion</code> as such instead of it being called <code>wildcard expansion</code> <a rel="noopener external" target="_blank" href="https://github.com/haskell/haskell-language-server/pull/4819">#4819</a>.</li> </ul> <h3 id="supported-ghc-versions">Supported GHC versions</h3> <ul> <li>9.14.1</li> <li>9.12.4</li> <li>9.12.2</li> <li>9.10.3</li> <li>9.8.4</li> <li>9.6.7</li> </ul> <h2 id="things-to-look-forward-to-gsoc-2026">Things to look forward to - GSOC 2026</h2> <p>We are very happy to announce that HLS has two exciting upcoming projects our Google Summer of Code students will be working on this summer!</p> <p>@vidit-od will be working on <a rel="noopener external" target="_blank" href="https://summer.haskell.org/ideas.html#goto-third-party-deps">goto third-party definition</a>, which will enable developers to view source code of external libraries by clicking goto definition on them. Within external libraries, many of the usual intellisense will keep working such as hover or goto references.</p> <p>@Aster89 will be working on the much sought after <a rel="noopener external" target="_blank" href="https://summer.haskell.org/ideas.html#casesplit">case split plugin</a>. This plugin will add refactoring options for <code>case X of</code> which supplies holes for all possible constructors of <code>X</code>.</p> <h2 id="thank-you-haskell-community">Thank you, Haskell Community</h2> <p>We wish all Haskellers happy hacking while using the latest releases of the Haskell Language Server, and hope to see you in the issue tracker or even in some pull requests!</p> <p>Finally, a reminder that you can donate to the development of HLS via <a rel="noopener external" target="_blank" href="https://opencollective.com/haskell-language-server">OpenCollective</a>. The OpenCollective money pays for tedious, but important maintenance work and, sometimes, for getting new features over the finish line.</p> 2026-04-02T00:00:00+00:00 2026-04-02T00:00:00+00:00 Unknown https://blog.haskell.org/what-would-you-see-changed-in-haskell/ <p>This report condenses the free form answers to Question 77 of the <a rel="noopener external" target="_blank" href="https://discourse.haskell.org/t/state-of-haskell-2025-results/13755">State of Haskell Survey 2025</a>. Due to the phrasing of the question, we have received 553 answers, with varying degrees of precision, actionability, and relevance. A team of two people (Sawa &amp; Hécate) proceeded to quantitatively and qualitatively analyse the survey results, extracting trends and topics about what the community would like to see changed.</p> <h2 id="interpreting-the-answers">Interpreting The Answers</h2> <p>A qualitative analysis of survey answers entails the hard task of noticing trends and moods, as well as determining the relevance of answers. We needed to understand if an answer is an example of the <a rel="noopener external" target="_blank" href="https://en.wikipedia.org/wiki/XY_problem">XY Problem</a>, and if so establish what the deeper problem is. Some answers were simply too vague to be classified either as a trending mood, or an actionable suggestion. Finally, one important thing to do when performing such an analysis is to have empathy for the people who spent their time responding to the survey and not outright dismiss their answers.</p> <h2 id="major-topics">Major Topics</h2> <p>The following topics are the ones that have collected the most answers from the survey participants. They are presented in no particular order.</p> <h3 id="switching-apis-to-using-text-instead-of-string">Switching APIs to using <code>Text</code> instead of <code>String</code></h3> <p>A laser-focused suggestion that came up is the replacement of <code>String</code> by <code>Text</code> as the canonical type for textual data. In particular, one answer explains the reasoning:</p> <blockquote> <p>The <code>text</code> library must live from <code>base</code>, because none of the APIs of <code>base</code> can use <code>Text</code>, and when people look at base for examples of well-written Haskell code, they end up using <code>String</code>, which is not the right choice.</p> </blockquote> <p>This has been a common source of frustration for beginners and advanced users alike. The topic was especially discussed in 2022 on the Discourse: <a rel="noopener external" target="_blank" href="https://discourse.haskell.org/t/bringing-data-text-into-base-what-is-the-next-step/5016/"><em>Bringing Data.Text into <code>base</code>: What is the next step?</em></a></p> <h3 id="onboarding-of-beginners">Onboarding of Beginners</h3> <p>Concerns regarding the quality of resources for beginners have been expressed in large numbers. Up-to-date content, and a centralised entry point in the language are some of the most actionable suggestions that we received. The Haskell Wiki is especially well-referenced by search engines, but has seen a steady decrease in contributions. People are encouraged to apply for an account and contribute to the articles.</p> <h3 id="documentation">Documentation</h3> <p>This one will not be a surprise to anyone, but thankfully some of the insights that were received pointed to concrete improvements that could be made. Library authors are encouraged to provide more <em>working</em> examples, as well as documentation that goes beyond the scope of a simple API reference.</p> <p>Community gatherings lend themselves especially well to documentation contributions, as people needing the documentation can meet with people who are best positioned to write it.</p> <p>For more information about what types of documentation exist and when to use particular ones, you can read <a rel="noopener external" target="_blank" href="https://blog.haskell.org/documentation-best-practices-in-2024/">Documentation Best Practices in 2024</a>.</p> <h3 id="complexity-of-the-haskell-language">Complexity of the Haskell Language</h3> <p>We have noticed a trend amongst participants that the Haskell Language is perceived as too complex, riddled with historical cruft, and that there is a lack of consistency in how the language and its libraries have evolved over the decade.</p> <p>Avoiding partial functions in the Prelude and more generally sane / safe defaults are a recurring suggestion. People want to feel proud of the <code>base</code> library, where the strengths of Haskell can shine, and not be just a hodgepodge of convenient functions.</p> <p>There have been requests to stop adding language extensions to GHC or even re-design the existing ones with a holistic approach. This feedback is in line with answers asking for a new Haskell Language Report, which could take advantage of the extensions that GHC has introduced over the years</p> <h3 id="the-record-system">The Record System</h3> <p>A certain proportion of survey participants have expressed their dissatisfaction at the state of records in Haskell. Answers remained vague, which gives us a mood indicator more than an action plan, but there are notable requests for <code>OverloadedRecordDot</code> and <code>NoFieldSelectors</code> to be enabled by default.</p> <h3 id="tooling">Tooling</h3> <h4 id="compilation-times">Compilation times</h4> <p>“Make GHC 10x faster” is one of the prevalent moods amongst participants. Coming from end-users, these suggestions do not come with actionable advice or specific pain points in the compilation pipeline. Specific situations like underpowered laptops have been mentioned.</p> <h4 id="ecosystem-consolidation-developer-experience">Ecosystem consolidation, Developer Experience</h4> <p>As the Haskell language and its ecosystem are more than thirty years old, it’s normal that we see a certain degree of fragmentation in the tooling, as new people and ideas enter the community. However, they tend to also confuse newcomers, who do not wish to navigate the intricacies of the technical and political disagreements that produced the existing tooling ecosystem. Survey participants very helpfully directed our attention to projects like <a rel="noopener external" target="_blank" href="https://docs.astral.sh/uv/"><code>uv</code></a> for an example of a fully-integrated toolchain (tooling management and project management).</p> <p>Compilation error messages are also called confusing. This might be explained by a mismatch between the intended audience of those messages and the actual audience. Error messages may feel more intended for implementers than for end-users. Recent versions of GHC have started to direct users to the <a rel="noopener external" target="_blank" href="https://errors.haskell.org/">Haskell error index</a>, so we can expect some positive development in the coming years. However, we should keep improving error messages for end-users who are not in the know about implementation details.</p> <p>Lastly, the <a rel="noopener external" target="_blank" href="https://haskell-language-server.readthedocs.io/en/latest/what-is-hls.html#what-is-the-haskell-language-server">Haskell Language Server</a> is often mentioned when participants complain about development experience, mostly due to the fact that they have to directly interact with it. Memory usage and reliability are thus felt by most people.</p> <h3 id="program-performance">Program Performance</h3> <h4 id="pervasive-laziness">Pervasive Laziness</h4> <p>Anxiety about laziness is a recurring theme, indicating lasting difficulties developers have in reasoning about lazy evaluation. Resource blow-up due to misunderstood runtime behaviours make people anxious when it comes to deploying or distributing Haskell software. Actionable advice like eliminating lazy I/O was given, which is indeed known for tripping people up, when they may expect it to happen only when they use a streaming library.</p> <p>Some suggestions are more targeted, like having data structures strict by default, and only explicitly lazy when the developer wishes so, by means of the <a rel="noopener external" target="_blank" href="https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/strict.html#strict-by-default-data-types">StrictData extension</a>.</p> <h2 id="minor-topics">Minor Topics</h2> <p>These topics have been mentioned in lesser but still substantial amounts. This does not mean that they are worthless, just that other concerns seemed more pressing to most participants.</p> <h3 id="dependent-haskell">Dependent Haskell</h3> <p>When people are not thinking about what is bad, they start thinking about what could be better. The subject of Dependent Types has come up enough times to attract our attention. Dependent Haskell is viewed as a unified solution that can replace otherwise loosely related language extensions. You can see the progress of the implementation on the <a rel="noopener external" target="_blank" href="https://ghc.serokell.io/dh">Dependent Haskell Roadmap</a> page.</p> <h3 id="community">Community</h3> <p>The desire for community is ever present in human beings, and Haskellers are no exception. They want to see their community thrive, meet more people, and see higher regard for non-technical contributions.</p> <h3 id="effect-systems">Effect Systems</h3> <p>The past few years have seen an increase in the research and development of algebraic effect systems, meant to replace the shortcomings of the existing Transformers/MTL approaches. We are beginning to see an interest for <code>base</code> to provide such a thing out of the box. Participants wishing for more interoperability also expressed the desire to change most functions operating in the <code>IO</code> monad to instead make use of <code>MonadIO</code>.</p> <p>Participants expressed interest in having a coherent story when it comes to the architecture of Haskell programs, the choice of libraries, and the fragmentation of the ecosystem.</p> <h3 id="debugging">Debugging</h3> <p>Debugging is still a sore point for participants, but the <a rel="noopener external" target="_blank" href="https://well-typed.github.io/haskell-debugger/">Haskell Debugger</a> is mentioned and seems to address most of the pain points. “<code>HasCallStack</code> everywhere" is also mentioned, which we consider to be a symptom of the perception of the existing debugging tools and backtrace mechanisms.</p> <h2 id="academia-industry-hobbyists">Academia, Industry, Hobbyists</h2> <p>An underlying theme of many of the previously mentioned answers is the question of “To whom does Haskell cater?”. Historically an academic project to study non-strict evaluation and pure functional programming, Haskell has grown to be adopted by software engineers in industry, leading to different ways of learning and socialising. A certain proportion of industrial programmers feel disenfranchised by the academic focus of the ecosystem, especially those that do not have an academic background or formal education.</p> <p>One answer in particular elaborates on the subject:</p> <blockquote> <p>There needs to be a recognition that there is documentation produced for/by the type theory / heavy mathematics enthusiasts which doesn't translate well as developer documentation. When new developers are looking for best practices they are often pointed into the direction of blogs written by clever, well-meaning people who write in a verbose style, often from the vantage point of mathematical abstractions. Any documentation that is software engineering oriented is always welcomed, but surprisingly rare.</p> </blockquote> <h2 id="special-mentions">Special Mentions</h2> <p>Some answers had to be categorised in a way that had to reflect how incredible they were. Here are our favourites:</p> <h4 id="a-whole-other-language">"A whole other language"</h4> <p>Some survey participants just want another language, going beyond taking inspiration from others, with suggestions such as swapping the meanings of <code>::</code> and <code>:</code>, removing laziness, or a total language and tooling cleanup, scorched-earth style. <a rel="noopener external" target="_blank" href="https://lean-lang.org/">Lean</a> and <a rel="noopener external" target="_blank" href="https://www.idris-lang.org/">Idris</a> might be more up your alley.</p> <h4 id="i-don-t-know-how-but-make-it-better">"I don’t know how, but make it better"</h4> <p>The vague rants and self-admitted impossible ideas hold a special place in our heart. “Replace base”, “tooling like TypeScript”, and “fix the weird syntax” were pretty good. It's hard to imagine these changes being possible without the level of support given to large corporate projects, such as VS Code, TypeScript or Go.</p> <p>Special mention for “weird syntax”, which we can <strong>absolutely</strong> <strong>do</strong> something about, we just forgot to press the big red button that says “fix syntax”. Thanks for the reminder!</p> <h2 id="to-conclude">To conclude</h2> <p>This year’s survey has brought us a very valuable insight into the preoccupations of a certain proportion of Haskellers. Of course, the results are to be handled with care, as surveys are a self-selecting tool in the first place. We cannot possibly know what exactly the community thinks, only what the subset that answers the survey thinks. We had a variety of answers, ranging from one word (“base”) to several paragraphs that could be the start of a <a rel="noopener external" target="_blank" href="https://github.com/ghc-proposals/ghc-proposals/?tab=readme-ov-file#ghc-proposals">GHC Proposal</a> or a <a rel="noopener external" target="_blank" href="https://github.com/haskell/core-libraries-committee?tab=readme-ov-file#core-libraries-committee">Core Libraries Proposal</a>. Anyone can open one, and we encourage you to do so!</p> <p>Tooling is a common thread to many topics, from beginner onboarding to consolidation of the developer experience. There is a tension between a fully integrated development ecosystem and having a language with multiple implementations that are free to explore different paths.</p> <p>Thank you again for participating in this year’s survey. Each new edition gives us more data points to measure the community trends, and they help the various groups with crafting the best experience for Haskell developers.</p> 2026-03-30T00:00:00+00:00 2026-03-30T00:00:00+00:00 Unknown https://blog.haskell.org/a-couple-million-lines-of-haskell/ <p><em>The editors of the Haskell Blog are happy to announce a new series of articles called "<a href="/categories/haskellers-from-the-trenches/">Haskellers from the trenches</a>", where we invite experienced engineers to talk about their subjects of expertise, best practices, and production tales.</em></p> <p><em>Engineering rigour and artistic creativity are a fantastic combination, and this series aims to be the synthesis of these two aspects within the Haskell world.</em></p> <hr /> <p>I first heard about Haskell when I was sixteen, sitting in a high school computer science class where we were writing Java and learning, among other things, that <code>NullPointerException</code> was apparently a lifestyle choice if you decided to go into software development. While looking at the <code>/r/programming</code> subreddit after school, I stumbled across a reference to a language where null pointer exceptions simply could not happen, where the type system could prevent an entire category of bugs that I had been fighting with every week. Haskell. I was immediately, hopelessly enamored with the idea.</p> <p>I have been writing Haskell for nearly two decades now, and I still think the value proposition I fell in love with at sixteen was basically right. What took me longer to learn is what that promise looks like after a codebase gets large, the company grows faster than its documentation, and the system is allowed to touch money. Haskell earns its keep there in numerous, sturdy ways. It lets you pack operational knowledge into APIs, put dangerous machinery behind tight boundaries, and make the safe path the easy one. At a growing company, those aren't just matters of taste; they are how you keep a system understandable after the people who first understood it have moved on.</p> <p>Fast forward to today: I work at Mercury, a fintech company that provides banking services.* We serve over 300,000 businesses. We processed $248 billion in transaction volume in 2025 on $650 million in annualized revenue, and are, at the time of writing, in the process of obtaining a national bank charter in the USA from the OCC. We have around 1,500 employees. Our engineering organization largely hires generalists, and most of them have never written a line of Haskell before joining.</p> <p>My time working at Mercury has changed how I think about the language more than any sermon about purity ever did. Elegance is pleasant, but keeping your business alive is compulsory.</p> <p>Our codebase is roughly 2 million lines of Haskell, once you strip out comments and such.</p> <p>This is the part where you are supposed to recoil in horror.</p> <p>A couple million lines of Haskell, maintained by people who learned the language on the job, at a company that moves huge amounts of money? The conventional wisdom says this should be a disaster, but surprisingly, it isn't. The system we've built has worked well for years, through hypergrowth, through the SVB crisis that sent $2 billion in new deposits our way in five days,<sup class="footnote-reference"><a href="#svb">1</a></sup> through regulatory examinations, through all the ordinary and extraordinary things that happen to a financial system at scale.</p> <p>This article is about why it works. Not in the "Haskell is beautiful" sense, though it is. Not in the "the compiler will save us from ourselves" sense, though I frequently feel gratitude in that direction. I mean in the much less romantic and much more useful sense that we run this language in production, at scale, with a rapidly changing team, and have learned some hard lessons about what it takes to keep the whole enterprise afloat. The beauty of Haskell is charming enough, but there is a whole swath of operational and organizational reality beyond it, and if you ignore that reality for too long, your company will likely fire the whole Haskell team<sup class="footnote-reference"><a href="#zalora">2</a></sup> and start writing PHP or something instead.</p> <h2 id="how-we-think-about-reliability">How We Think About Reliability</h2> <p>Before diving into practical advice, a note on philosophy.</p> <p>There is a traditional way of thinking about system reliability that focuses on preventing failures. You enumerate the things that can go wrong. You add checks. You write tests for each bad case. You hunt for bugs. This is, of course, necessary work, and we do it. But it is not sufficient, and if you orient entirely around it you develop a specific blind spot: you get very good at cataloguing the ways things break and very bad at understanding why they ordinarily work.<sup class="footnote-reference"><a href="#safety-one">3</a></sup></p> <p>We try to think about it differently. A system operates reliably because it can <strong>absorb variation</strong>: it degrades gracefully, its operators can understand and adjust it, and the architecture makes the right thing easy and the wrong thing difficult.<sup class="footnote-reference"><a href="#safety-two">4</a></sup> Reliability is not just the absence of failure. It is the presence of adaptive capacity. It is a system's ability to keep functioning while reality continues its longstanding and regrettable habit of refusing to hold still.</p> <p>When you have hundreds of engineers working in a multi-million-line codebase, many of whom are six months into their Haskell careers, "adaptive capacity" stops being a nifty phrase from a resilience engineering paper and starts being a daily concern. Patrick McKenzie has observed that in a company growing at 2x per year, half of your coworkers will always have less than a year of experience. A year later, half of your coworkers will still have less than a year of experience. For very successful companies, this never stops being true.<sup class="footnote-reference"><a href="#patio11">5</a></sup> You become organizationally ancient very quickly, whether you like it or not, and the things you know become institutional dark matter: load-bearing, but invisible to most of the people around you.</p> <p>So the questions we ask are operational. Can the new hire on your team read this module and understand what it does? If the database is slow, does this service degrade or does it fall over and take its neighbors with it? If someone misuses an interface, does the compiler tell them, or do we find out when the on-call gets paged? If you don't have answers to those questions, you have a future incident quietly unfolding.</p> <p>This is why I increasingly think of the type system as an <strong>operational aid</strong> more than a correctness proof. Its value is not merely that it rules out certain classes of errors, though it does. Its value is that it encodes institutional knowledge in a form that survives the departure of the person who wrote it. In a fast-growing company, people leave, people transfer teams, people go on vacation or parental leave, people join, and the churn means that things people knew walk out the door with them unless you have written them down somewhere. Ideally, you have written them down in a form that the compiler can read, because the compiler is much more disciplined than the average wiki page.</p> <p>This extends beyond code. As a member of our stability engineering team, we constantly investigate the prospective production behavior of features and products. We do not do this to slow down product development, but in partnership with the team shipping the feature, to make sure we are prepared to deal with the fallout when it breaks and, if possible, to make that fallout boring rather than exciting. We ask things like: what is the blast radius if this fails? Which operations must be idempotent, and how? What does the rollback look like? What happens to in-flight work? Which systems will absorb the failure, and which ones will amplify it? The point is to have the conversation early enough that it shapes the design rather than merely auditing the launch after all the important decisions have already become expensive to revisit.<sup class="footnote-reference"><a href="#prr">6</a></sup></p> <p>Our philosophy, stated plainly: we are not the quality police. We are the people who would like to help you avoid being woken up at 4 AM to deal with the fallout of a broken feature. Rather than a deeply ideological stance, we simply desire to help people.</p> <p>So, in light of that, how do we make Haskell work in production?</p> <h2 id="purity-is-a-boundary-not-a-property">Purity Is a Boundary, Not a Property</h2> <p>My hot take: the first and most consequential misunderstanding about Haskell is that purity is not something the language <em>is</em>, so much as that it is something your interfaces enforce.</p> <p>Under the hood, Haskell is not a magical machine that performs side effects despite being pure. Behind every "pure" function in <code>bytestring</code>, <code>text</code>, and <code>vector</code> lies a cheerful little hellscape of mutable allocation, buffer writes, unsafe coercions, and other behavior that would alarm you if you discovered it in a junior engineer's side project. Behind the <code>ST</code> monad lies in-place mutation and side effects, observable within the computation. What makes it acceptable is that the side effects are encapsulated such that the boundary cannot be violated.</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #4078F2;">runST</span><span> :: (</span><span style="color: #A626A4;">forall</span><span style="color: #E45649;"> s</span><span>.</span><span style="color: #A626A4;"> ST</span><span style="color: #E45649;"> s a</span><span>) -&gt;</span><span style="color: #E45649;"> a</span></span></code></pre> <p>The rank-2 type (that is, the type <code>s</code> is scoped within the parenthesis and can't escape) of <code>runST</code> ensures that the mutable references created inside the computation cannot escape due to being tagged with the type <code>s</code>. Internally, all sorts of imperative nonsense may occur. Externally, the function is pure. The world outside the boundary gets none of the mutation, only the result.</p> <p>This is, I think, a wonderful design principle in the larger scheme of things when writ large: you can permit arbitrarily dangerous operations within a scope, provided the scope's exit is typed narrowly enough that the danger cannot leak. That principle applies everywhere in production. Your database layer uses connection pooling, retry logic, and mutable state internally. Your cache uses concurrent mutable maps. Your HTTP client probably has circuit breakers, pooled connections, and a small municipal government's worth of bookkeeping. None of this is a problem if the interface is tight enough to prevent misuse and the boundary holds.</p> <p>In production, the goal is often not to avoid mutation entirely, because that is not a serious proposition for most real systems. The goal is to contain mutation, make the containment legible, and verify that it stays contained. Often the right question is not "is this pure?" but "where is the impurity, and how much of the codebase is allowed to know about it?"</p> <p>For a new engineer who learned Haskell three months ago, "purity is a boundary you try to maintain" is much more useful than "Haskell is pure." One tells them what to do when they sit down to design a module. The other mostly sits there looking profound.</p> <p>This boundary-oriented view of purity sets up a more general pattern that recurs throughout production engineering in Haskell: dangerous things are tolerable when they are fenced in, carefully exposed, and hard to misuse. That is true of mutation. It is true of retries, transactions, state machines, distributed workflows, and type-level machinery. Much of what follows is really just this same idea, wearing different hats.</p> <h2 id="make-the-right-thing-easy">Make the Right Thing Easy</h2> <p>There is a pattern in large codebases where correctness depends on performing operations in a particular order, or including a particular step that has no visible connection to the main work.</p> <p>"Remember to flush the audit log after every transaction."</p> <p>"Always check the feature flag before calling this endpoint."</p> <p>"Make sure to enqueue the notification <em>inside</em> the database transaction, not after it."</p> <p>These are the incantations of operational lore. They live in wiki pages, onboarding documents, half-forgotten design reviews, and the memories of senior engineers who are now three teams away and booked solid until Thursday. In a company that is hiring aggressively, the half-life of tribal knowledge is alarmingly short. When an engineer leaves, the incantations fade. When a deadline approaches, they are the first thing skipped. When a new engineer joins, they often have no way to know the incantation exists at all. Nothing says "robust system design" quite like a critical invariant living in a Slack thread from nine months ago<sup class="footnote-reference"><a href="#slack">7</a></sup>.</p> <p>Haskell gives you tools to encode these incantations in types so they cannot be forgotten. This is, for my money, the single most valuable thing the language offers a production engineering organization.</p> <p>Consider a simplified version of a real pattern: you need to ensure that certain side effects (sending a notification, publishing an event) happen <em>transactionally</em> with a database write. Not before, not after, and not in a separate transaction. Together, or not at all.</p> <p>The naïve approach is to tell people to use the right function:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A0A1A7;font-style: italic;">-- Please use this one, not the other one</span></span> <span class="giallo-l"><span style="color: #4078F2;">writeWithEvents</span><span> ::</span><span style="color: #A626A4;"> Transaction</span><span> -&gt; [</span><span style="color: #A626A4;">Event</span><span>] -&gt;</span><span style="color: #A626A4;"> IO</span><span style="color: #986801;"> ()</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: #A0A1A7;font-style: italic;">-- Don&#39;t use this directly (but we can&#39;t stop you)</span></span> <span class="giallo-l"><span style="color: #4078F2;">writeTransaction</span><span> ::</span><span style="color: #A626A4;"> Transaction</span><span> -&gt;</span><span style="color: #A626A4;"> IO</span><span style="color: #986801;"> ()</span></span> <span class="giallo-l"><span style="color: #4078F2;">publishEvents</span><span> :: [</span><span style="color: #A626A4;">Event</span><span>] -&gt;</span><span style="color: #A626A4;"> IO</span><span style="color: #986801;"> ()</span></span></code></pre> <p>This is rookie-level engineering. It works until it doesn't, and "until it doesn't" tends to arrive on a Friday afternoon when the person who wrote the wiki page is on vacation and everybody else is discovering, in real time, that the wiki page was load-bearing.</p> <p>A better approach restructures the types so that the only way to <em>commit</em> work is through a path that includes event publication:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A626A4;">data Transact</span><span style="color: #E45649;"> a</span><span style="color: #A0A1A7;font-style: italic;"> -- opaque; cannot be run directly</span></span> <span class="giallo-l"><span style="color: #4078F2;">record</span><span> ::</span><span style="color: #A626A4;"> Transaction</span><span> -&gt;</span><span style="color: #A626A4;"> Transact</span><span style="color: #986801;"> ()</span></span> <span class="giallo-l"><span style="color: #4078F2;">emit</span><span> ::</span><span style="color: #A626A4;"> Event</span><span> -&gt;</span><span style="color: #A626A4;"> Transact</span><span style="color: #986801;"> ()</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: #A0A1A7;font-style: italic;">-- The *only* way to execute a Transact: commit and publish atomically</span></span> <span class="giallo-l"><span style="color: #4078F2;">commit</span><span> ::</span><span style="color: #A626A4;"> Transact</span><span style="color: #E45649;"> a</span><span> -&gt;</span><span style="color: #A626A4;"> IO</span><span style="color: #E45649;"> a</span></span></code></pre> <p>Now the incantation is the only door in the room. You cannot forget it because there is nothing else to do. The type system has not proven anything especially deep about your events. It has done something more practical: it has made the correct operational procedure the path of least resistance.</p> <p>That distinction matters. In production, there are plenty of places where we do not need a theorem. We need a design that makes it difficult for an ordinary busy engineer to accidentally do the wrong thing while trying to do a dozen other perfectly reasonable things. The compiler is not merely checking logic here; it is preserving institutional memory and turning it into a hard-edged interface.</p> <p>When a new engineer joins and asks "how do I write a transaction?", the type system answers them. When a senior engineer leaves, the answer remains. The institutional knowledge survived not because someone documented it beautifully, though documentation is pleasant when available, but because someone encoded it in a form the compiler enforces. Again, the compiler is a better custodian of operational lore than the average wiki and less prone to people forgetting to update it as the reality of the system changes.</p> <h2 id="durable-execution">Durable Execution</h2> <p>The pattern above — structuring types so that the correct operational procedure is the only procedure — works well within a single transaction. Financial systems, unfortunately, have never felt obligated to remain inside a single transaction.</p> <p>They are full of processes that span multiple steps, multiple services, and multiple failure modes. Send a payment, wait for a partner to acknowledge it, update the ledger, notify the customer, handle cancellation, handle timeout, handle the case where the partner said yes but your worker died before recording the answer, handle the case where the partner said nothing because the network briefly entered a higher plane of existence and declined to tell you about it. If any step fails, you need to know where you were, what has already happened, and what still needs to happen. You need state. You need retries. You need timeouts. You need idempotence. You need all of these things to keep working across process crashes and deployments. Very quickly, what began as "just some business logic" amasses a remarkable amount of one-off repeats of common operational concerns.</p> <p>Previously at Mercury, we coordinated these processes with database-backed state machines driven by cron jobs and background workers, with retry logic and timeout handling scattered across the codebase. It worked. It also required the sort of vigilance usually associated with defusing unexploded ordnance. It was fragile, difficult to reason about, and the source of a disproportionate share of our operational incidents.</p> <p><a rel="noopener external" target="_blank" href="https://temporal.io">Temporal</a> is our durable execution framework, and adopting it was one of the better infrastructure decisions we have made. You write your workflow as ordinary sequential code, and the platform records every step in an event history. If a worker crashes mid-workflow, another worker replays the deterministic prefix to reconstruct the state, then continues from where it left off. Retries, timeouts, cancellation, and error handling are provided by the platform rather than each team reimplementing them poorly.</p> <p>I think of Temporal as Frankenstein's monster, in the flattering sense: assembled from excellent parts, animated by improbable effort, and smarter than many of the people alarmed by it. It takes durable history, replay, and determinism (things some platforms get natively,) and bolts them onto runtimes that were never born knowing how to do any of this. Most of us are not going to rewrite our companies in Erlang. Temporal is a prosthetic for the rest of us. It gives ordinary languages a shot at some of the same operational virtues by slightly mad but highly effective means.</p> <p>The alignment with Haskell dovetails nicely with the virtues often attributed to Haskell: A Temporal workflow is, in an important sense, a pure function over its event history. Temporal Workflows have a determinism requirement — that a replayed workflow must produce the same sequence of commands as the original — which is exactly the same constraint Haskell imposes on pure code: same inputs, same outputs. Side effects are isolated into <em>activities</em>, which are the workflow's equivalent of <code>IO</code>. The workflow orchestrates; the activities execute. If you have spent any time thinking about pure core / impure shell, this is that model with the platform enforcing the separation rather than relying on sheer discipline.</p> <p>We built and open-sourced <a rel="noopener external" target="_blank" href="https://github.com/MercuryTechnologies/hs-temporal-sdk"><code>hs-temporal-sdk</code></a>, our Haskell SDK for Temporal, which wraps the official Core SDK (Rust, via FFI) and provides a Haskell-native API for defining workflows, activities, and workers.</p> <p>I gave a <a rel="noopener external" target="_blank" href="https://www.youtube.com/watch?v=FdGMaLcEP2M">talk about our adoption patterns at Temporal's Replay conference</a>, and the short version is: Temporal has let us replace fragile chains of cron jobs and database-backed state machines with durable workflows where the platform handles the coordination. The operational improvement has been substantial. It is difficult to overstate how pleasant it is to delete a hand-rolled distributed state machine and replace it with something whose failure semantics were not improvised during sprint planning.</p> <p>This, again, is adaptive capacity in a different costume. A system that can survive worker crashes, process restarts, and long-lived coordination without losing its place is a system whose operators have more leverage and fewer mysteries to unwind during an incident.</p> <h2 id="design-for-your-domain-not-your-transport">Design for Your Domain, Not Your Transport</h2> <p>As your production system grows, a common mistake I've observed is letting the invoking system leak into the domain model.</p> <p>We have code that throws HTTP status code exceptions which return those results directly to the user on the frontend. This made sense when the code was written, because it ran in an HTTP request handler. Then, as happens in any growing codebase, pieces of that code got extracted and reused. Now it also runs in cron jobs. It runs in queued background workers. It runs in Temporal workflows. And it still throws <code>StatusCodeException 409 "Conflict"</code> when something goes wrong, which is an absolutely unhinged thing for a cron job to do. A cron job does not have a caller waiting for a 409. Nobody is reading that status code. The error has propagated through the system simply because the original abstraction was coupled to its transport layer.</p> <p>The fix is conceptually simple: model your domain errors as domain types. A payment that fails because of insufficient funds should be an <code>InsufficientFunds</code>, not a 402. A duplicate request should be a <code>DuplicateRequest</code>, not a 409. These are things your business logic can match on, retry against, log meaningfully, and handle differently depending on context.</p> <p>Then you write thin translation layers at each boundary:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A626A4;">data PaymentError</span></span> <span class="giallo-l"><span> =</span><span style="color: #986801;"> InsufficientFunds</span></span> <span class="giallo-l"><span> |</span><span style="color: #986801;"> DuplicateRequest</span><span style="color: #A626A4;"> RequestId</span></span> <span class="giallo-l"><span> |</span><span style="color: #986801;"> PartnerTimeout</span><span style="color: #A626A4;"> Partner</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: #4078F2;">toHttpError</span><span> ::</span><span style="color: #A626A4;"> PaymentError</span><span> -&gt;</span><span style="color: #A626A4;"> HttpResponse</span></span> <span class="giallo-l"><span>toHttpError </span><span style="color: #986801;">InsufficientFunds</span><span> = err402 </span><span style="color: #50A14F;">&quot;Insufficient funds&quot;</span></span> <span class="giallo-l"><span>toHttpError (</span><span style="color: #986801;">DuplicateRequest</span><span> _) = err409 </span><span style="color: #50A14F;">&quot;Duplicate request&quot;</span></span> <span class="giallo-l"><span>toHttpError (</span><span style="color: #986801;">PartnerTimeout</span><span> _) = err502 </span><span style="color: #50A14F;">&quot;Partner unavailable&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: #4078F2;">toWorkerStrategy</span><span> ::</span><span style="color: #A626A4;"> PaymentError</span><span> -&gt;</span><span style="color: #A626A4;"> WorkerAction</span></span> <span class="giallo-l"><span>toWorkerStrategy </span><span style="color: #986801;">InsufficientFunds</span><span> =</span><span style="color: #986801;"> Fail</span><span style="color: #50A14F;"> &quot;Insufficient funds&quot;</span></span> <span class="giallo-l"><span>toWorkerStrategy (</span><span style="color: #986801;">DuplicateRequest</span><span> _) =</span><span style="color: #986801;"> Skip</span></span> <span class="giallo-l"><span>toWorkerStrategy (</span><span style="color: #986801;">PartnerTimeout</span><span> _) =</span><span style="color: #986801;"> RetryWithBackoff</span></span></code></pre> <p>Nothing novel about it. But it is remarkable how often it gets skipped in practice, because the first version of any code is written for <em>one</em> context, and by the time you realize it will be called from three others, the status code exceptions are load-bearing because someone decided to catch those exceptions as part of business logic and nobody wants to refactor them.</p> <p>The earlier you make this separation, the less it costs. The later you make it, the stranger the resulting behavior becomes. Eventually you wind up with cron jobs hurling 409s at Sentry and background workers interpreting HTTP-specific exceptions as business semantics, which is how abstractions let you know they have escaped containment.</p> <p>This is the same principle as purity, expressed in domain language rather than operational language. Your transport concerns belong at the edges. Your domain model should survive being invoked from a web handler, a CLI, a cron job, a background worker, or a workflow engine without having to drag an HTTP status code behind it like a tin can tied to a wedding car.</p> <h2 id="the-type-encoding-tradeoff">The Type Encoding Tradeoff</h2> <p>Here is the part where I tell you not to do too much of the thing I just told you to do.</p> <p>Encoding invariants into types is powerful. It is also expensive. Not at runtime, but in cognitive overhead, in the rigidity it introduces, and in the difficulty of changing things later when the requirements shift. And the requirements <em>will</em> shift. If you work at a company where they do not, I would like to know your secret, and also your stock ticker.</p> <p>Every invariant you push into the type system is a constraint on every future engineer who touches that code. If violating the constraint would cause data loss, financial errors, regulatory trouble, or a poor soul's pager to go off, then the cost is justified. If the constraint is "we currently happen to do things this way," or "I read this article about dependent types and I <em>simply must</em> apply that to my authorization logic," you have likely just made your codebase harder to change for no operational benefit. The next person to encounter it will either spend a week refactoring the types or, more likely, find a way around them that is worse than what you were trying to prevent.</p> <p>There is a spectrum, and production codebases must live on it honestly.</p> <p>At one end: you encode everything. Your types are a faithful model of your domain. Illegal states are unrepresentable. Refactoring takes weeks because changing a business rule means threading a type change through fifty modules. New engineers stare at the type signatures and wonder what they have done to deserve this, then quietly begin discussing their career options with a therapist. You have built a cathedral. Cathedrals are beautiful. They are also expensive, cold, and not especially famous for how quickly one renovates the plumbing.</p> <p>At the other end: you encode nothing. Your types are <code>String</code> and <code>IO ()</code> and, in the worst case, <code>Dynamic</code>. The code is easy to change because there are no contracts to violate. The system works because the people who built it are still around and remember what the strings mean. When they leave, it stops working, and nobody knows why. You have built a tent. Tents are flexible, portable, and, under certain weather conditions, a very direct way to learn about the sky. This is, of course, one of the reasons many Haskell developers flee to Haskell in the first place — to avoid the suffering that comes from this approach.</p> <p>The sweet spot is somewhere in the middle. A few heuristics I think are useful:</p> <p><strong>Encode invariants that protect against silent corruption.</strong> If a violation would produce wrong data without any immediate error (a transaction committed without its events, a payment processed without an audit log, a state transition that looks plausible but is semantically impossible), put it in the types. The feedback loop for silent failures is too long to rely on human diligence.</p> <p><strong>Use runtime checks for invariants that fail loudly.</strong> If a violation would produce an immediate, obvious error (a 500 response, a failed assertion, a type mismatch at a JSON boundary), a runtime check with a good error message may be enough. You will catch it before production, or very quickly after.</p> <p><strong>Resist the urge to model your entire domain in types.</strong> Your domain is messy. It has edge cases, grandfather clauses, rules that contradict each other, and special behavior for three specific customers that dates back to 2018 and that nobody fully understands. The type system wants crispness. Your business does not provide it. Nor will it ever.</p> <p><strong>Remember that types are for the team, not just for the compiler.</strong> The compiler is one tool among many. Tests, documentation, code review, examples, playbooks: these all combine to provide defense in depth. The goal is not to win an argument with the type checker. The goal is to build a system that a team of humans, including humans who learned Haskell this year, can operate, extend, and maintain.</p> <p>That said, intense type-level machinery is sometimes exactly what you need. We have internal libraries where the types are genuinely hairy: GADTs, type families, phantom types tracking state transitions. These tend to be mechanisms where getting it wrong means money goes to the wrong place or a regulatory invariant is violated. The complexity is absolutely essential here.</p> <p>The key thing, if you want to do this sustainably, is that we <em>encapsulate</em> the complexity. The module that implements the type-level state machine typically has a small number of authors who understand it deeply and, ideally, a thorough test suite. The module that <em>uses</em> it has a surface API that looks like five normal functions with normal types. A product engineer on another team can call those functions without knowing or caring that underneath there is a small type-level theorem prover ensuring they cannot commit a transaction in the wrong state. The proof obligations are discharged inside the boundary, not leaked across it.</p> <p>This is the same containment principle as purity, applied one level up. The complexity itself is fine, because it buys you something valuable. What causes problems is complexity that leaks across module boundaries into code maintained by people who did not sign up for it. We catch this in code review more than anywhere else. Someone opens a PR that touches a module they do not own, and the diff is full of type annotations they had to cargo-cult from a neighboring file just to make the compiler stop screaming. That is usually a sign the abstraction has become a form of friendly fire.</p> <h2 id="designing-for-introspection">Designing for Introspection</h2> <p>If reliability is about adaptive capacity, introspection is one of the ways you buy it. Operators cannot understand what they cannot see. Teams cannot adapt systems whose internals are opaque. Observability is not a garnish you sprinkle on at the end. It is part of the design surface of the software.</p> <p>This matters a great deal in Haskell, because Haskell does not have monkey patching. You cannot, at runtime, reach into a library and replace its HTTP client with one that records timings, or swap its database calls for ones that emit OpenTelemetry spans. This is not unique to Haskell, of course. Rust has the same fundamental constraint: no monkey patching, no runtime method swizzling, no language-level "let me just interpose here real quick" escape hatch. The orphan rule even prevents you from adding trait implementations for types you do not own. The difference is that the Rust ecosystem has largely converged on the <code>tower</code> middleware pattern as the answer, while Haskell's ecosystem is still fragmented across several approaches. The constraint is the same; the question is whether your ecosystem gives you a conventional escape hatch or leaves every team to improvise one.</p> <p>So, if a library exposes its functionality as a set of concrete top-level functions, your options for instrumenting it are limited to wrapping those functions in a new module and hoping nobody forgets to import yours instead of the original. Hope, it should be said, is not one of the stronger architectural patterns.</p> <p>A point generalizeable for any language: <strong><em>You cannot operate what you cannot see.</em></strong> If your traces have large opaque gaps because a library does something expensive and provides no hooks for you to measure it, you will find out what is slow when a customer complains, not when your dashboards tell you. If the dashboards tell you because the customer has already complained, then you are already paying interest on that design decision.</p> <p>The solution I reach for most often is <strong>records of functions</strong>. Instead of exposing a module full of concrete functions, you expose a record whose fields are the functions. The caller can then wrap, instrument, mock, or replace any individual function without touching the rest. I wrote about this at length in <a rel="noopener external" target="_blank" href="https://www.iankduncan.com/articles/2024-01-26-records-of-effects">Embracing Flexibility in Haskell Libraries</a>, but the short version is:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A0A1A7;font-style: italic;">-- A concrete module gives you no leverage:</span></span> <span class="giallo-l"><span style="color: #4078F2;">sendRequest</span><span> ::</span><span style="color: #A626A4;"> Request</span><span> -&gt;</span><span style="color: #A626A4;"> IO Response</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: #A0A1A7;font-style: italic;">-- A record of functions gives you all of it:</span></span> <span class="giallo-l"><span style="color: #A626A4;">data HttpClient</span><span> =</span><span style="color: #986801;"> HttpClient</span></span> <span class="giallo-l"><span> {</span><span style="color: #E45649;"> sendRequest</span><span> ::</span><span style="color: #A626A4;"> Request</span><span> -&gt;</span><span style="color: #A626A4;"> IO Response</span></span> <span class="giallo-l"><span> ,</span><span style="color: #E45649;"> getManager</span><span> ::</span><span style="color: #A626A4;"> IO Manager</span></span> <span class="giallo-l"><span> }</span></span></code></pre> <p>With the record, you can wrap <code>sendRequest</code> with timing instrumentation and return a new <code>HttpClient</code>. You can inject faults for testing. You can swap the implementation for a mock. You can add retries, tracing, request rewriting, tenant-specific behavior, or whatever other cross-cutting concern production has discovered for you this quarter. All at runtime, without touching the library's source code. WAI got this right with <code>type Middleware = Application -&gt; Application</code>: composable transformation of behavior is massively useful across a wide variety of systems, and systems are rarely kind enough to present all of their cross-cutting needs up front.</p> <p>There is a nice algebraic property hiding in this pattern that deserves more attention. I promise this is not me sneaking category theory into the room in a fake moustache; it is genuinely practical. Middleware and interceptor types almost always admit <code>Semigroup</code> and <code>Monoid</code> instances. WAI's <code>Middleware</code> is <code>Application -&gt; Application</code>, an endomorphism, and endomorphisms form a monoid under composition with <code>id</code> as the identity. A record of interceptor hooks, where each field is itself an endomorphism (or a continuation-passing function with a similar shape), gets a fieldwise <code>Semigroup</code> instance for free: <code>a &lt;&gt; b</code> composes each field independently, and <code>mempty</code> is the record where every field is the identity (pass the call through unchanged).</p> <p>This turns composition from an engineering problem into almost a non-problem. You do not write bespoke plumbing to combine your tracing interceptor with your timeout interceptor with your task queue rewriting interceptor. You <code>mconcat</code> them:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span>appTemporalInterceptors =</span></span> <span class="giallo-l"><span> mconcat</span></span> <span class="giallo-l"><span> [ retargetingInterceptor</span></span> <span class="giallo-l"><span> , otelInterceptor</span></span> <span class="giallo-l"><span> , sentryInterceptor</span></span> <span class="giallo-l"><span> , sqlApplicationNameInterceptor</span></span> <span class="giallo-l"><span> , loggingContextInterceptor</span></span> <span class="giallo-l"><span> , statementTimeoutInterceptor</span></span> <span class="giallo-l"><span> , teamNameInterceptor</span></span> <span class="giallo-l"><span> , clientExceptionInterceptor</span></span> <span class="giallo-l"><span> , workflowTypeNameInterceptor</span></span> <span class="giallo-l"><span> ]</span></span></code></pre> <p>Each interceptor is defined in isolation, in its own module, by someone who only needs to think about one concern. Individual interceptors are built from <code>mempty</code> with one or more fields overridden — everything else passes through. Composition is just <code>(&lt;&gt;)</code>. There is no hidden wiring. There is no coordination tax beyond agreeing on the shape of the hooks. Ordering is explicit in the list. New cross-cutting concerns are added by appending one more element; existing interceptors are never touched.</p> <p>This is the <code>Monoid</code> pattern at its most practical. The abstraction does not exist for elegance, though elegance is a nice side effect. It exists because it makes the operational task of "combine N independent cross-cutting concerns" trivially correct by construction. If your middleware type supports <code>mempty</code> and <code>(&lt;&gt;)</code>, you can hand it to fifteen engineers and tell them each to write one piece, and the pieces will compose naturally.</p> <p>Effect systems (<code>effectful</code>, <code>polysemy</code>, <code>fused-effects</code>, <code>cleff</code>, etc.) offer another route. You define an effect type describing the available operations, then provide interpreters that can be swapped at the call site. One for production, one for testing, one that wraps the production interpreter with tracing. The reinterpretation capabilities are particularly nice: intercept an effect, record a metric or inject a delay, and re-send it to the real handler. I wrote a guide to <a rel="noopener external" target="_blank" href="https://github.com/fused-effects/fused-effects/blob/main/docs/reinterpreting_effects.md">using this for fault injection and observability</a> in the <code>fused-effects</code> documentation, and the core ideas transfer to any effect system. The tradeoff is that effect systems add machinery (type-level effect lists, handler stacks, sometimes gnarly type errors) where records of functions are simple enough that a new hire can understand the pattern in an afternoon. Both work. The important thing is that you pick one and use it consistently enough that your operability story is not itself an archaeological dig.</p> <p>The <code>persistent</code> library is the canonical positive example, for me. Its <code>SqlBackend</code> type is a record of functions: <code>connPrepare</code>, <code>connInsertSql</code>, <code>connBegin</code>, <code>connCommit</code>, <code>connRollback</code>, and so on. When I implemented OpenTelemetry instrumentation for <code>persistent</code>, I could add tracing spans around every database operation by wrapping the relevant fields. No fork required. Almost no source changes. A few lines of code and we had full visibility into our database layer. That is what a good operational escape hatch looks like.</p> <p>Libraries that do not do this are the ones that cost us the most operational pain. At Mercury, we very rarely use web API client bindings published on Hackage. This is not because they are necessarily poorly written (some are quite good). The problem is that we cannot trust code we cannot instrument. If a third-party binding makes HTTP calls through concrete functions, we have no way to add tracing, no way to inject timeouts tuned to our SLOs, no way to simulate partner outages in testing, and no way to explain the 400ms gap in a trace except by squinting at it and developing theories. So we write our own. More work upfront, but the clients we write are observable by construction, because we built them that way from the start.</p> <p>There is also a milder ecosystem tax that people do not always mention. Some of the libraries you depend on are not abandoned, exactly; abandoned is too clean a word. They are still in service, structurally important to the ecosystem, maintained enough that the things continue to run, and not obviously owned by anyone whose full-time job is to improve them.</p> <p>This has a few causes. Some of the people who built large parts of the modern Haskell ecosystem have, quite reasonably, gone on to other things. A handful of prolific authors of widely used libraries and frameworks seem to have shifted much their attention towards Rust, for example. Their libraries still work, still get support to a degree, and still have users who depend on them. But the stewardship model becomes less clear. Nobody is obviously in charge in the way a fast-moving production team would mean "in charge," and that creates understandable hesitation around making breaking changes, even when experience has taught us better ways to design these systems.</p> <p>Diffuse stewardship has technical consequences. Old interfaces tend to persist. Libraries are often stable in the sense that they still function, but not especially alive in the sense of incorporating newer ideas about observability, boundary design, or operability. They may also lag behind advances you would like to take for granted. <code>http-client</code>, for example, still only supports HTTP/1.1 directly, which is perfectly serviceable right up until it isn't. You can work around this. But it means some parts of the ecosystem feel less like actively evolving products and more like public infrastructure: useful, durable, and mildly resistant to renovation.</p> <p>This is not a complaint about volunteer maintainers. It is simply one of the ambient risks of building serious systems on a smaller ecosystem. The code may not be abandoned. It may just be standing there, somewhat stoically, waiting for someone with enough context and enough appetite for downstream breakage to renovate the station while the trains are still running.</p> <p>If you are writing a Haskell library, leave escape hatches. Provide records of functions, or effect types, or callbacks, or <em>something</em> that lets the consumer of your code inject behavior without modifying it. Haskell's type system is wonderful for enforcing constraints. But it can also, if you are not careful, seal a system so tightly that the people who have to operate it cannot see inside. The perfect abstraction, if it is operationally opaque, simply cannot be used in production.</p> <h3 id="a-note-to-package-authors">A note to package authors</h3> <p>Please consider taking <a rel="noopener external" target="_blank" href="https://hackage.haskell.org/package/hs-opentelemetry-api"><code>hs-opentelemetry-api</code></a> as a dependency and adding instrumentation to your package. The API package is designed to be a good citizen: we are conservative about breaking changes, and it is completely inert when the OpenTelemetry SDK is not initialized by the application. Minimal performance overhead, and no unexpected exceptions or logging in your users' applications. In the interest of honesty, the dependency footprint is not yet as minimal as we want it to be, and we are actively working on that. But even a handful of spans around your key <code>IO</code> operations would make a real difference to anyone running your library in production.</p> <p>And please, we beg you, do not log directly from library code. Do not import a logging framework and write to <code>stdout</code> or <code>stderr</code>. Provide a logging callback, or accept a logger as a parameter, or expose your log messages as a data type the caller can route wherever they want. The moment a library decides where logs go, it has made a decision about the operational environment that belongs to the application. At Mercury, we route logs through structured pipelines that feed into our observability stack. When a library writes directly to <code>stderr</code>, those messages bypass everything, and we have to write bespoke plumbing to account for them being dumped into what is otherwise a stream of JSON lines, which is a ridiculous way to spend anyone's finite time on Earth. A callback costs you almost nothing. Let the application decide how to be operated.</p> <p>One more thing for library authors: consider exposing <code>.Internal</code> modules. This is somewhat controversial advice. Others have argued, reasonably, that <code>.Internal</code> modules create implicit API surface that users depend on, making it harder to refactor your library's internals without breaking downstream code. The concern is legitimate, but it rests on a degree of confidence that you have gotten your public API exactly right, that you have anticipated every use case your users will encounter. In my experience, that confidence is rarely justified.</p> <p>A well-documented <code>.Internal</code> module with an explicit stability warning ("this module's API may change without notice between minor versions") is vastly preferable to the alternative, which is that your users fork your package, vendor it into their codebase, and now maintain a divergent copy that will never receive your upstream fixes. The Haskell ecosystem's best libraries already do this (<code>containers</code>, <code>text</code>, <code>unordered-containers</code>). It costs almost nothing to provide, and it turns "I need to fork this library" into "I need to import one unstable module," which is often a better situation for everyone involved.</p> <p>One thing to watch out for here is that exposing internal modules may mean that you don't hear feedback from consumers, who have quietly popped the hood to get at what they need instead. Sometimes that is fine. Sometimes it means your public API's missing pieces remain missing because nobody bothers to tell you.</p> <h2 id="what-we-don-t-put-in-the-types">What We Don't Put in the Types</h2> <p>Not all production Haskell is beautiful.</p> <p><code>unsafePerformIO</code> is used in libraries you depend on daily. The <code>bytestring</code> and <code>text</code> libraries use it internally to allocate mutable buffers, write into them, and freeze the result. The types say nothing about what happened during construction. The containment is maintained by convention, by careful reasoning, and by code review. You will encounter this in any production Haskell codebase. You will <em>write</em> this, when the type-safe alternative imposes an unacceptable performance or complexity cost. When you do, be honest about it. Document the invariants that the types are not checking. Be appropriately uncomfortable. Periodically revisit whether the type-safe alternative has become practical. Production Haskell is not the absence of compromise. It is the disciplined containment of compromise.</p> <p>Then there is the testing situation. An alarming number of Haskell libraries on Hackage have few or no tests. The implicit (and sometimes disastrously explicit) argument is that if it compiles, it works. This is sometimes true for small pure code with tight types. It is certainly a common early Haskell experience: you make illegal states unrepresentable, the compiler catches a shocking amount, and you briefly begin to suspect you may have transcended ordinary software failure.</p> <p>This feeling should not be trusted.</p> <p>It is almost never true for IO-heavy code, for code that interacts with external systems, or for code where the interesting bugs live in the <em>semantics</em> rather than the <em>structure</em>. Types can tell you that a function returns an <code>Either ParseError Transaction</code>. They cannot tell you whether it parses the <code>amount</code> field as cents or dollars. They cannot tell you whether your partner API interprets an omitted field differently from a null field. They cannot tell you whether your retry logic doubles charges under exactly one timing window on leap day. In a production context, you are building on top of these libraries, and you are inheriting their untested assumptions. Worth knowing about, and worth compensating for with integration tests at your own layer.</p> <p>Other ugly bits of Haskell crop up too: orphan instances, partial functions that you swear are total in context, <code>error</code> calls that you promise are unreachable, awkward FFI wrappers, hand-rolled exceptions hierarchy shennanigans, places where the ideal abstraction lost a knife fight with the real one. These accumulate. Operating Haskell in production is the act of tending a living system, and living systems accrete compromises. What you can do is enforce discipline in code review, by way of documentation and examples and tests, so that you know where every compromise is, why it was made, and what would break if it were removed. The goal is not moral purity. The goal is to avoid discovering, during an incident, that half the system's assumptions existed only as oral tradition.</p> <h2 id="why-bother-with-haskell-at-all">Why bother with Haskell at all?</h2> <p>There is a question that comes up whenever someone considers Haskell for a production system: <strong>is it worth it?</strong></p> <p>Not on day one.</p> <p>On day one, you are slower. The current Haskell ecosystem simply does not have the power of Next.js or Rails to dump a batteries-included hot-reloading development environment onto your desk. Projects like IHP may eventually get there, but inevitably, the library you need does not exist, or exists but is maintained by one person in their spare time. The error messages occasionally read like the screed of a madman who knows exactly what is wrong and deeply resents having to explain it to you.</p> <p>The hiring concern, though, is overstated. Our CTO Max Tagher has said publicly that backend Haskell engineer is the <em>easiest</em> role to hire for in all of Mercury.<sup class="footnote-reference"><a href="#max">8</a></sup> There is more demand for Haskell jobs than the market provides, which inverts the usual recruiting dynamic. Interest in Haskell acts as a decent proxy for baseline developer quality (Paul Graham's <a rel="noopener external" target="_blank" href="http://www.paulgraham.com/pypar.html">Python Paradox</a>, applied one language further up the abstraction ladder), and it attracts people who are genuinely excited about the work rather than indifferent to it. We hire people with deep Haskell experience and people with no Haskell experience at all, and we have a training program that gets the latter group productive in six to eight weeks. The hiring pool problem is real if you need a hundred Haskell experts tomorrow. It is much less real if you are willing to hire good generalists and invest in teaching them.</p> <p>The hiring risk that nobody warns you about is not the size of the pool. It is the <em>disposition</em> of the pool.</p> <p>Haskell attracts idealists. This is mostly a strength: you get people who care about correctness, who think carefully about abstractions, who read papers for fun, and who are willing to interrogate assumptions other ecosystems accepted years ago out of pure exhaustion. But idealism, left unchecked, becomes a production liability. The engineer who wants to rewrite the database layer using a novel type-level encoding of relational algebra is not helping you ship features. The engineer who refuses to merge code that uses <code>String</code> instead of <code>Text</code> in a throwaway script is not helping you hit a deadline. The engineer who treats every design discussion as an opportunity to advocate for a total rewrite in the style of a paper they read last week is, however brilliant, making the team slower.</p> <p>You have to actively cultivate a culture of pragmatism. Haskell gives you powerful tools. Using all of them all the time is not pragmatism; it is self-indulgence. The type system is a power tool, not a religion, and production systems are not the place to treat every feature as an excuse to invent a novel mechanism to solve a problem that already has a perfectly good solution.</p> <p>The return comes later, but it does come. You see it when a refactor that would take weeks in a dynamically typed codebase takes hours, because the compiler threads the change through every call site and tells you exactly what you missed. There is a particular pleasure to mechanical refactoring in Haskell that is hard to convey until you have experienced it: you change a type, and the compiler hands you an exhaustive list of everywhere that needs to adapt. You work through it methodically — no searching, no guessing, no wondering whether you missed a call site in a module you forgot existed — and when it compiles, you are done. It is one of the few programming experiences that feels genuinely <em>complete</em> rather than <em>probably complete</em>. You see it when a new hire reads a module's type signatures and understands its contracts without asking anyone, which in a company that has grown from fifty engineers to several hundred is not a convenience but a survival tactic. You see it when a production incident does <em>not</em> happen because an impossible state was actually impossible, not just considered unlikely by someone in a hurry.</p> <p>We have found that the investment pays off on the order of months, not years. This is particularly true in financial services, where the cost of a data integrity bug is measured not in user complaints but in regulatory findings and in other people's money. The type system does not eliminate these risks. But it gives you the tools to make them harder to introduce by accident, and in a fast-growing codebase, "by accident" is where most of the risk lives.</p> <p>We have been running Haskell in production for years now, at a scale and in a domain where getting things wrong carries tremendous consequences, both for our customers and for us. It has not been painless. Some of the pain was the language's fault, some was the ecosystem's, and a good deal of it was our own. But the system works, and it keeps working as the team grows and changes around it, and that is not something I can say about every technology choice I have made in my career.</p> <p>When I was sixteen, what captivated me about Haskell was the promise that some bugs could be made impossible. I still love that premise, but what I understand now is that the deeper production value is broader and, in a way, more interesting. Haskell lets you preserve hard-won operational knowledge after the people who discovered it have gone home, changed teams, or left the company. It lets you draw hard boundaries around dangerous machinery. It lets you make the safe path the easy path. In a system that has to keep working while the organization around it changes, that surpasses academic elegance and provides solid engineering leverage.</p> <p>If you are considering Haskell for production, I hope this has given you a realistic picture of what that looks like: not a silver bullet, not a moral crusade, but a genuinely powerful set of tools even when wielded by a team that with a broad range of Haskell expertise.</p> <hr /> <p><em>Ian Duncan is an engineer on the Stability team at <a rel="noopener external" target="_blank" href="https://mercury.com">Mercury</a>, where he works on reliability infrastructure, including Mercury's Temporal SDK, OpenTelemetry instrumentation, and making sure production doesn't keel over and die when he isn't looking. He has been writing in assorted functional programming languages professionally since 2014. He lives in The Hague with his family and has strong opinions about coffee, power metal, and system architecture. You can find him on <a rel="noopener external" target="_blank" href="https://bsky.app/profile/iankduncan.com">Bluesky</a> and at <a rel="noopener external" target="_blank" href="https://iankduncan.com">iankduncan.com</a>.</em></p> <hr /> <div class="footnote-definition" id="svb"><sup class="footnote-definition-label">1</sup> <p>In March 2023, Silicon Valley Bank collapsed in what turned out to be the second-largest bank failure in U.S. history. Mercury gained over 8,700 new customers and $2 billion in deposits in five days, because nothing stress-tests your infrastructure quite like the entire startup ecosystem simultaneously deciding to move their money to you. See <a rel="noopener external" target="_blank" href="https://techcrunch.com/2023/07/07/mercury-says-it-gained-nearly-26k-new-customers-in-the-four-months-after-svbs-collapse/">"SVB's collapse drove 26K customers to Mercury in 4 months"</a> (TechCrunch, 2023). 95% of them stayed.</p> </div> <div class="footnote-definition" id="zalora"><sup class="footnote-definition-label">2</sup> <p>It's a thing that I've seen happen to at least three or four companies at this point!</p> </div> <div class="footnote-definition" id="safety-one"><sup class="footnote-definition-label">3</sup> <p>The distinction between studying failure and studying success in complex systems is the central thesis of Erik Hollnagel's <a rel="noopener external" target="_blank" href="https://www.routledge.com/Safety-I-and-Safety-II/Hollnagel/p/book/9781472423085"><em>Safety-I and Safety-II</em></a> (Ashgate, 2014). The traditional approach ("Safety-I") focuses on preventing things from going wrong. The alternative ("Safety-II") focuses on understanding why things ordinarily go <em>right</em> and ensuring the conditions for success are maintained.</p> </div> <div class="footnote-definition" id="safety-two"><sup class="footnote-definition-label">4</sup> <p>"Adaptive capacity" as the foundation of resilient systems comes from the resilience engineering literature, particularly David Woods' work. See <a rel="noopener external" target="_blank" href="https://www.routledge.com/Resilience-Engineering-Concepts-and-Precepts/Woods-Hollnagel-Leveson-Cook/p/book/9780754649045"><em>Resilience Engineering: Concepts and Precepts</em></a> (Ashgate, 2006) and Woods' <a rel="noopener external" target="_blank" href="https://doi.org/10.1016/j.ress.2018.01.004">"Four Concepts for Resilience and the Implications for the Future of Resilience Engineering"</a> (<em>Reliability Engineering &amp; System Safety</em>, 2015).</p> </div> <div class="footnote-definition" id="patio11"><sup class="footnote-definition-label">5</sup> <p>Patrick McKenzie (patio11), <a rel="noopener external" target="_blank" href="https://www.kalzumeus.com/2020/10/09/four-years-at-stripe/">"What Working At Stripe Has Been Like"</a> (2020). At a company growing fast enough, the majority of your colleagues will <em>always</em> be new, which means anything you know that isn't written down in code or docs is effectively secret knowledge.</p> </div> <div class="footnote-definition" id="prr"><sup class="footnote-definition-label">6</sup> <p>Our process is informed by Google's production readiness review model, described in Betsy Beyer et al.'s <a rel="noopener external" target="_blank" href="https://sre.google/sre-book/table-of-contents/"><em>Site Reliability Engineering</em></a> (O'Reilly, 2016), Chapters 32-33. Our adaptation emphasizes collaborative review over gatekeeping.</p> </div> <div class="footnote-definition" id="slack"><sup class="footnote-definition-label">7</sup> <p>Incidentally, Slack at Mercury now has a message lifespan of like a couple years or something before it gets deleted. So, you eventually reach a point at large orgs where deep lore begins to evaporate entirely unless it is written down somewhere more permanent.</p> </div> <div class="footnote-definition" id="max"><sup class="footnote-definition-label">8</sup> <p>Max Tagher, <a rel="noopener external" target="_blank" href="https://serokell.io/blog/haskell-in-production-mercury">"Haskell in Production: Mercury"</a> (Serokell, 2022) and <a rel="noopener external" target="_blank" href="https://serokell.io/blog/haskell-mercury-functionalfutures">"Haskell in Mercury"</a> (Functional Futures, 2024).</p> </div> <hr /> <p><em>*Mercury is a fintech company, not an FDIC-insured bank. Banking services provided through Choice Financial Group and Column N.A., Members FDIC. (At the time of writing.)</em></p> 2026-01-26T00:00:00+00:00 2026-01-26T00:00:00+00:00 Unknown https://blog.haskell.org/hls-2-13-0-0/

<p>The HLS team is happy to announce the 2.13.0.0 Haskell Language Server release which introduces two new exciting features!</p>

2025-12-25T00:00:00+00:00 2025-12-25T00:00:00+00:00 Unknown https://blog.haskell.org/a-comment-preserving-cabal-parser/ <p><em>This article was originally posted on my blog <a rel="noopener external" target="_blank" href="https://confusedcompiler.org/articles/2025-12-comment-preserving-cabal-parser">here</a>.</em></p> <hr/> <h1 id="motivation">Motivation</h1> <p>Cabal <sup class="footnote-reference"><a href="#1">1</a></sup> is the standard package system for Haskell software, it is similar to Cargo from the Rust world, or OPAM if you come from OCaml.</p> <p>Cabal reads cabal package manifests in the cabal format (with the extension <code>.cabal</code>). However, it is currently unable to modify it loselessly: comments are lost, imports are fused and written in place, <code>elif</code> in a conditional will be desugared to a nested <code>if</code> in an <code>else</code>. A tracking issue was opened in cabal's repository since 2021 <a rel="noopener external" target="_blank" href="https://github.com/haskell/cabal/issues/7544">here</a>.</p> <p>For this reason, critical features such as adding modules to the .cabal manifest or generating package dependency bounds are implemented poorly. For example, cabal emits a warning when a module is not listed in the manifest, but it can't apply the fix the warning indicates for you. Furthermore, <code>cabal gen-bounds</code> (which generates dependency bounds that are not specified) doesn't write dependency bounds information directly to the cabal file, it dumps them to the terminal. Frustrating!</p> <p>If we use the current pretty printer in cabal to try to implement these features, the resulting cabal manifest will be mangled. This is because cabal can't do <em>exact printing</em> yet. Concretely this means the spaces and empty lines, comments, common stanzas, and if conditions that you add will be lost. Adding an exact printer will allow cabal to modify the cabal files automatically and loselessly!</p> <p>An exact printer is a special kind of pretty printer. It uses concrete syntax information in the in-memory representation to output a file that is byte-to-byte identical to the file originally parsed. To do that, its corresponding parser must store enough information in the in-memory representation. Formally, the exact parser/printer combination obeys the law presented below.</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span>forall cabalFile.</span></span> <span class="giallo-l"><span style="color: #986801;"> IsValid</span><span> cabalFile =&gt;</span></span> <span class="giallo-l"><span> exactPrint (exactParse cabalFile) == cabalFile</span></span></code></pre> <p>This reads as "for all valid cabal manifests, the operation <code>exactPrint . exactParse</code> should output a file that is byte-to-byte identical to the original".</p> <p>Furthermore, we also aim to allow modification to the in-memory representation. Unmodified parts of the representation will be printed out verbatim to the original parsed cabal file.</p> <p>This property is crucial for tools to be able to manipulate cabal files programmatically: adding dependency, export a module, or generate package bounds just to name a few.</p> <p>In order to achieve introducing an exact printer, the first step is to preserve concrete syntax information. For example, comments must not be altered, comma style in comma-separated fields must be preserved, blank spaces and blank lines should be preserved.</p> <p><a rel="noopener external" target="_blank" href="https://jappie.me/">Jappie</a> started doing a prototype that works well since 2024 Zurihac. The proposal has matured enough and was accepted by the Haskell Foundation, the current step is to implement it in Cabal. =D</p> <p>The following sections will be talking about handling comments in the parser and lexer.</p> <h1 id="how-the-cabal-parser-works">How the cabal parser works</h1> <p>There are three main parts to the cabal parser, namely the lexer, the field parser, and the field grammar parser.</p> <p>The lexer is written in <a rel="noopener external" target="_blank" href="https://haskell-alex.readthedocs.io/">Alex</a>, a lexer generator for Haskell. Using a lexer generator has the advantage to write a set of production rules without thinking about their ordering or ambiguity, Alex will detect inconsistencies during the generation of the lexer. The lexer produces a stream of <code>Token</code>s.</p> <p>The field parser is written in plain Haskell. It calls the code generated by Alex, consuming the produced <code>Token</code>s. The top-level (entry point) of field parsers is <code>readFields</code>. It produces a stream of <code>Field ann</code> where <code>ann</code> holds some annotation related to the field. Before this work on comment preservation, <code>ann</code> is instantiated as <code>Position</code> which represents the row and column of the source code where the field is seen.</p> <p>The field parser not only interacts with the lexer by consuming <code>Token</code>s, but also by changing its state. Modeled as an automaton, Alex allows users to set "state", or "start codes". Each production rule in Alex can switch state and either produce a <code>Token</code> or nothing (drop the token for the parser to never see it). The field parser sets the state of the lexer upon seeing certain <code>Token</code>s that give hint to the following context. This has the benefit of producing better lexical error messages because the lexer "is more knowledgable" thanks to the parser, but also makes the logic a bit intertwined and less straightforward. In cabal's case, certain states are inaccessible without the parser deciding to transition to it.</p> <p>The lexer and the field parser together handles the cabal envelope format. Imagine if today cabal were to not use its own format and uses something like TOML like Cargo from Rust does, this format is the equivalent of TOML.</p> <p>The inner format is founded on the "field grammar", it handles things like "which field should be defined for a cabal file to be a package description", "which field can be defined multiple times with its values merged together", "which fields contains comma separated values or dependency bound description", and so on.</p> <p>This inner format is handled by the field grammar parser. It is a lot less straightforward than the two aforementioned parts and is primarily defined with type classes. The <code>FieldGrammar</code> type class describes how the pretty printer and parser should behave, two birds one stone! <sup class="footnote-reference"><a href="#2">2</a></sup></p> <h1 id="how-we-achieved-comment-preserving-parsing">How we achieved comment-preserving parsing</h1> <p>Prior to the work on comment-preserving parsing, comments are dropped by the lexer and no other parts down the pipeline can see any comments. To preserve comments, we must go against this prior design by making the lexer emit comments.</p> <p>We also needed to store the comments somewhere in the output of <code>readFields</code> which outputs <code>[Field Position]</code>.</p> <p>The <code>Field ann</code> data type is defined as follows</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A626A4;">data Field</span><span style="color: #E45649;"> ann</span></span> <span class="giallo-l"><span> =</span><span style="color: #986801;"> Field</span><span> !(</span><span style="color: #A626A4;">Name</span><span style="color: #E45649;"> ann</span><span>) [</span><span style="color: #A626A4;">FieldLine</span><span style="color: #E45649;"> ann</span><span>]</span></span> <span class="giallo-l"><span> |</span><span style="color: #986801;"> Section</span><span> !(</span><span style="color: #A626A4;">Name</span><span style="color: #E45649;"> ann</span><span>) [</span><span style="color: #A626A4;">SectionArg</span><span style="color: #E45649;"> ann</span><span>] [</span><span style="color: #A626A4;">Field</span><span style="color: #E45649;"> ann</span><span>]</span></span> <span class="giallo-l"><span style="color: #A626A4;"> deriving</span><span> (</span><span style="color: #A626A4;">Eq</span><span>,</span><span style="color: #A626A4;"> Show</span><span>,</span><span style="color: #A626A4;"> Functor</span><span>,</span><span style="color: #A626A4;"> Foldable</span><span>,</span><span style="color: #A626A4;"> Traversable</span><span>,</span><span style="color: #A626A4;"> Generic</span><span>)</span></span></code></pre> <p>Originally, Jappie's prototype adds another constructor <code>Comment !ByteString</code> to hold a comment. This was quite straightforward (exactly what we want in a prototype!) but it also introduced subtle footguns: all code that depend on the <code>Field</code> data type now has to deal with with <code>Comment</code>s.</p> <p>With help from <a rel="noopener external" target="_blank" href="https://github.com/andreabedini">Andrea Bedini</a>, we changed the design to maintain the original definition of <code>Field ann</code>, while instantiating <code>ann</code> differently. Previously this type variable was <code>Position</code>; by changing it to <code>([ByteString], Position)</code>, we were able to store comments without polluting all usages of <code>Field ann</code> with the <code>Comment</code> constructor! Concretely we decided to give this pattern a type to disallow uses of <code>Data.Bifunctor.first</code> and <code>Data.Bifunctor.second</code>, as it can be less straightforward. The <code>WithComments ann</code> type is as follows:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A626A4;">data WithComments</span><span style="color: #E45649;"> ann</span><span> =</span><span style="color: #986801;"> WithComments</span></span> <span class="giallo-l"><span> {</span><span style="color: #E45649;"> justComments</span><span> :: ![</span><span style="color: #A626A4;">Comment</span><span style="color: #E45649;"> ann</span><span>]</span></span> <span class="giallo-l"><span> ,</span><span style="color: #E45649;"> unComments</span><span> :: !</span><span style="color: #E45649;">ann</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span style="color: #A626A4;"> deriving</span><span> (</span><span style="color: #A626A4;">Show</span><span>,</span><span style="color: #A626A4;"> Generic</span><span>,</span><span style="color: #A626A4;"> Eq</span><span>,</span><span style="color: #A626A4;"> Ord</span><span>,</span><span style="color: #A626A4;"> Functor</span><span>)</span></span></code></pre> <p>A minor downside with the <em>comments-in-<code>ann</code></em> model is that a file with no field but only comments can't be represented. However we don't consider this case because such a file won't be a valid cabal file.</p> <p>We changed the top-level field parser <code>readFields</code> as follows:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A0A1A7;font-style: italic;">-- Old definition is kept with the same type</span></span> <span class="giallo-l"><span style="color: #4078F2;">readFields</span><span> :: B8.</span><span style="color: #A626A4;">ByteString</span><span> -&gt;</span><span style="color: #A626A4;"> Either ParseError</span><span> [</span><span style="color: #A626A4;">Field Position</span><span>]</span></span> <span class="giallo-l"><span>readFields = (fmap . map . fmap) unComments . readFieldsWithComments</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: #A0A1A7;font-style: italic;">-- New comment-preserving alternative for the exact printer (and/or other future tooling interested in comments)</span></span> <span class="giallo-l"><span style="color: #4078F2;">readFieldsWithComments</span><span> :: B8.</span><span style="color: #A626A4;">ByteString</span><span> -&gt;</span><span style="color: #A626A4;"> Either ParseError</span><span> [</span><span style="color: #A626A4;">Field</span><span> (</span><span style="color: #A626A4;">WithComments Position</span><span>)]</span></span> <span class="giallo-l"><span>readFieldsWithComments = fmap fst . readFieldsWithComments&#39;</span></span></code></pre><h1 id="tracing-out-lexer-states">Tracing out lexer states</h1> <p>The current cabal already "handles" comments, the problem is that it drops them. This is good news because we only needed to change the right hand side of the production rule to retain the comments from the lexer. We didn't have to worry that our modifications will alter the syntax of cabal.</p> <p>I traced out the automaton graph to see where comments can occur, and added them to the field parser. The lexer state diagram svg is generated with graphviz, the source code is available <a href="https://blog.haskell.org/a-comment-preserving-cabal-parser/./lexer_states.dot">here</a>. <img src="https://blog.haskell.org/a-comment-preserving-cabal-parser/./lexer_states.svg" alt="Lexer States" /></p> <p>The start state is used to handle BOM only once and for the purpose of comment parser we can ignore it. In the graph, edges with red labels are transitions made by the lexer with its own information; on the other hand, edges with blue labels are transitions made by the field parser knowing what token it just saw. The states colored in yellow can emit comments.</p> <p>Having this diagram is very useful as it tells us how the different contexts relate to each other, and clarifies which locations can contain comments in a Cabal file.</p> <p><code>FieldLayoutOrBraces</code> and <code>FieldInlineOrBraces</code> would start in <code>in_section</code> state, switch to <code>in_field_layout</code> or <code>in_field_braces</code> depending on the context and run a parser, and finally switch back to <code>in_section</code>. To annotate this we use a double ended edge because the transition condition isn't visible from the lexer context.</p> <h1 id="functor-multiplicity-is-a-footgun">Functor multiplicity is a footgun</h1> <p><code>Field ann</code> is a functor, so doing <code>fmap</code> on <code>Field (WithComments Position)</code> we can alter the annotation on a field, right? Hold on! Let's look at the <code>Field ann</code> type again.</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A626A4;">data Field</span><span style="color: #E45649;"> ann</span></span> <span class="giallo-l"><span> =</span><span style="color: #986801;"> Field</span><span> !(</span><span style="color: #A626A4;">Name</span><span style="color: #E45649;"> ann</span><span>) [</span><span style="color: #A626A4;">FieldLine</span><span style="color: #E45649;"> ann</span><span>]</span></span> <span class="giallo-l"><span> |</span><span style="color: #986801;"> Section</span><span> !(</span><span style="color: #A626A4;">Name</span><span style="color: #E45649;"> ann</span><span>) [</span><span style="color: #A626A4;">SectionArg</span><span style="color: #E45649;"> ann</span><span>] [</span><span style="color: #A626A4;">Field</span><span style="color: #E45649;"> ann</span><span>]</span></span> <span class="giallo-l"><span style="color: #A626A4;"> deriving</span><span> (</span><span style="color: #A626A4;">Eq</span><span>,</span><span style="color: #A626A4;"> Show</span><span>,</span><span style="color: #A626A4;"> Functor</span><span>,</span><span style="color: #A626A4;"> Foldable</span><span>,</span><span style="color: #A626A4;"> Traversable</span><span>,</span><span style="color: #A626A4;"> Generic</span><span>)</span></span></code></pre> <p><code>ann</code> is used everywhere, especially in <code>[FieldLine ann]</code> and <code>[Field ann]</code>. This means if we <code>fmap</code> and attach comments to a <code>Field</code>, its first and second arguments will all have the same comments attached!</p> <p>I think there's no way to avoid this, since it's still convenient to have a functor instance. The moral of the story is that you must have a clear understanding of the instances of the data types you're using.</p> <h1 id="conclusion-and-future-work">Conclusion and future work</h1> <p><code>GenericPackageDescription</code> is the final representation of a parsed cabal file. To preserve <code>Eq</code> extensionality <sup class="footnote-reference"><a href="#3">3</a></sup>, we wrapped it with a data type which isn't an instance of <code>Eq</code>. Otherwise, a <code>GenericPackageDescription</code> would be considered different when the comments are different!</p> <p>We duplicated the top-level parsing functions so we have one entry-point that parses annotation (<code>parseAnnotatedGenericPackagedescription</code>), and another one that doesn't (<code>parseGenericPackageDescription</code>) to provide backward compatibilty.</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A626A4;">data AnnotatedGenericPackageDescription</span><span> =</span><span style="color: #986801;"> AnnotatedGenericPackageDescription</span></span> <span class="giallo-l"><span> {</span><span style="color: #E45649;"> exactComments</span><span> ::</span><span style="color: #A626A4;"> Map Position ByteString</span></span> <span class="giallo-l"><span> ,</span><span style="color: #E45649;"> unannotatedGpd</span><span> ::</span><span style="color: #A626A4;"> GenericPackageDescription</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span style="color: #A626A4;"> deriving</span><span> (</span><span style="color: #A626A4;">Show</span><span>,</span><span style="color: #A626A4;"> Data</span><span>,</span><span style="color: #A626A4;"> Generic</span><span>)</span></span></code></pre> <p>Since the position of all comments should not overlap, we store the comments in a map indexed by their <code>Position</code> in the source file. This is necessary to reconstruct the comments in the source file and achieve exact print.</p> <p>This change to the lexer and parser is isolated, meaning you can already use the comments when this is merged. However more work needs to be done for a complete exact print feature! Namely we need to stop common stanzas from being merged in. Currently I am working on a prototype to retain trivia in field grammar parser, so the spaces in dependency bounds won't be dropped, for example.</p> <p>Please tell me if you have any thoughts on this work. :)</p> <p>I want to thank the the Haskell Foundation and Jappie for allowing this work to happen. I appreciate greatly the opportunity to work on cabal and solve a problem that helps Haskell programmers. :) I also want to thank the people in my life who believed in me when I needed help, without you I wouldn't be who I am today. :)</p> <hr /> <div class="footnote-definition" id="1"><sup class="footnote-definition-label">1</sup> <p>Common Architecture for Building Applications and Libraries, <em>Cabal</em></p> </div> <div class="footnote-definition" id="2"><sup class="footnote-definition-label">2</sup> <p>The printer part doesn't even work like we mentioned in the pre-amble, Jappie told me to say to you all it's a lovecraftian horror. It's Gods justice for our collective sin. If you wonder what an abyss of despair looks like, Jappie invites you to open <a rel="noopener external" target="_blank" href="https://hackage-content.haskell.org/package/Cabal-syntax-3.16.0.0/docs/Distribution-FieldGrammar-Class.html">pandora's box</a>. This is your humanity. The face of God. To know it is to know madness.</p> </div> <div class="footnote-definition" id="3"><sup class="footnote-definition-label">3</sup> <p><a rel="noopener external" target="_blank" href="https://en.wikipedia.org/wiki/Extensionality">https://en.wikipedia.org/wiki/Extensionality</a></p> </div> 2025-11-30T00:00:00+00:00 2025-11-30T00:00:00+00:00 Unknown https://blog.haskell.org/investigating-language-extension-semantics/ <p>Hi I'm <a rel="noopener external" target="_blank" href="https://jappie.me">Jappie</a> and I volunteer for the <a rel="noopener external" target="_blank" href="https://blog.haskell.org/stability-working-group/">Haskell Foundation Stability Working Group</a>. Recently we analyzed the <a rel="noopener external" target="_blank" href="https://gitlab.haskell.org/ghc/head.hackage">head.hackage</a> patches to understand why code breaks on new GHC releases. "head.hackage" is a repository of patches for Hackage. GHC engineers use these to test out new GHC builds on a wide range of Hackage packages without having to upstream<sup class="footnote-reference"><a href="#upstream">1</a></sup> a patch, which can take time. Instead, they can put the patch in "head.hackage" and immediately test it on a wide range of packages. Surprisingly, most breakage wasn’t caused by <a rel="noopener external" target="_blank" href="https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/template_haskell.html">Template Haskell</a>, it came from deeper semantic changes in language extensions. The meaning of (some) language extensions changed between GHC releases. This post walks through the main categories of breakage, why they happened, and what they tell us about long-term stability. If you care about a smoother upgrade path for Haskell users, we invite you to participate in the <a rel="noopener external" target="_blank" href="https://blog.haskell.org/stability-working-group/">Haskell Foundation Stability Working Group</a>.</p> <p>Extending our initial <a rel="noopener external" target="_blank" href="https://jappie.me/analyzing-haskell-stability.html">investigation</a>, We're also interested in understanding <em>why</em> breakage occurs. So we've recently done further analysis on <a rel="noopener external" target="_blank" href="https://ghc.gitlab.haskell.org/head.hackage/">head.hackage</a>, and learned surprisingly enough that the root cause of a lot of breakage isn't Template Haskell, but seems to be from language extension semantics<sup class="footnote-reference"><a href="#meaning">2</a></sup>. We're doing this investigation to understand better where efforts should be focused in improving stability.</p> <p>This gave us the following table:</p> <table><thead><tr><th>Name</th><th>Cause</th><th>Had warnings?</th></tr></thead><tbody> <tr><td>Cabal-2.4.1.0.patch</td><td>simplified subsumption</td><td>no</td></tr> <tr><td>Cabal-3.0.2.0.patch</td><td>simplified subsumption</td><td>no</td></tr> <tr><td>Cabal-3.2.1.0.patch</td><td>simplified subsumption</td><td>no</td></tr> <tr><td>data-r-tree-0.6.0.patch</td><td>parser change (see 1)</td><td>no</td></tr> <tr><td>drinkery-0.4.patch</td><td>simplified subsumption</td><td>no</td></tr> <tr><td>ghc-lib-parser-9.8.1.20231121.patch</td><td>rename forall identifiers (2)</td><td>yes</td></tr> <tr><td>hgeometry-ipe-0.13.patch</td><td>Instances moved due to splice enforcement</td><td>no</td></tr> <tr><td>singletons-3.0.2.patch</td><td>add TypeAbstractions as a language extension</td><td>yes</td></tr> <tr><td>singletons-base-3.1.1.patch</td><td>add TypeAbstractions as a language extension</td><td>yes</td></tr> <tr><td>vector-space-0.16.patch</td><td>Star is type (4)</td><td>yes</td></tr> </tbody></table> <p><code>th-compat-0.1.4.patch</code> was miscounted so I left that out. Simplified subsumption appears a lot but 3 are for Cabal, so it's only 2 real occurrences. I'd expect that to appear a lot however, because it was one of <em>the</em> motivating changes for a <a rel="noopener external" target="_blank" href="https://blog.haskell.org/stability-working-group/">stability working group</a>.</p> <h2 id="simplified-subsumption">Simplified subsumption</h2> <p>For the blissfully ignorant reader simplified subsumption causes you to do this under certain existential conditions:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="diff"><span class="giallo-l"><span>--- a/Distribution/Simple/Utils.hs</span></span> <span class="giallo-l"><span>+++ b/Distribution/Simple/Utils.hs</span></span> <span class="giallo-l"><span>@@ -1338,7 +1338,7 @@ withTempFileEx opts tmpDir template action =</span></span> <span class="giallo-l"><span> (\(name, handle) -&gt; do hClose handle</span></span> <span class="giallo-l"><span> unless (optKeepTempFiles opts) $</span></span> <span class="giallo-l"><span> handleDoesNotExist () . removeFile $ name)</span></span> <span class="giallo-l"><span style="color: #E45649;">- (withLexicalCallStack (uncurry action))</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ (withLexicalCallStack (\x -&gt; uncurry action x))</span></span></code></pre> <p>You have to insert a lambda, which apparently has some performance impact. This had a big impact on <a rel="noopener external" target="_blank" href="https://www.yesodweb.com/book">Yesod stacks</a>, whose code generation helpfully created the database alias in the template:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="haskell"><span class="giallo-l"><span style="color: #A626A4;">type DB</span><span style="color: #E45649;"> a</span><span> =</span><span style="color: #A626A4;"> forall</span><span> (</span><span style="color: #E45649;">m</span><span> ::</span><span style="color: #A626A4;"> Type</span><span> -&gt;</span><span style="color: #A626A4;"> Type</span><span>).</span></span> <span class="giallo-l"><span> (</span><span style="color: #A626A4;">MonadUnliftIO</span><span style="color: #E45649;"> m</span><span>) =&gt;</span><span style="color: #A626A4;"> ReaderT SqlBackend</span><span style="color: #E45649;"> m a</span></span></code></pre> <p>Normally this is quite convenient, however with the simplified subsumption change, any code that interacts with the database now has to insert those lambdas. As you can imagine this would in many places for a commercial code base. Causing a lot of compile errors for industrial users. Instead of inserting lambdas, you can also delete those existential aliases to solve the problem. Or you can enable the language extension: <a rel="noopener external" target="_blank" href="https://downloads.haskell.org/~ghc/9.12.2/docs/users_guide/exts/rank_polymorphism.html#extension-DeepSubsumption">DeepSubsumption</a>. Which restores the original behavior.</p> <h2 id="moving-of-instances-due-to-template-haskell">Moving of instances due to Template Haskell</h2> <p>This change forces you to put the instances above the splice where they are being used in the same module. A dear colleague decided to generate instances in Template Haskell. That was quite the puzzle! I asked the GHC devs why they did this, and it turns out this was a soundness issue in the typechecker. Here, soundness means the type system can't be tricked into allowing invalid programs. So the community is better off, despite this causing a fair bit of work.</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="diff"><span class="giallo-l"><span>--- a/src/Ipe/Content.hs</span></span> <span class="giallo-l"><span>+++ b/src/Ipe/Content.hs</span></span> <span class="giallo-l"><span>@@ -288,6 +288,14 @@</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: #50A14F;">+instance Fractional r =&gt; IsTransformable (IpeObject r) where</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ transformBy t (IpeGroup i) = IpeGroup $ i&amp;core %~ transformBy t</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ ...</span></span> <span class="giallo-l"><span> makePrisms &#39;&#39;IpeObject</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>@@ -303,14 +311,6 @@</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: #E45649;">-instance Fractional r =&gt; IsTransformable (IpeObject r) where</span></span> <span class="giallo-l"><span style="color: #E45649;">- transformBy t (IpeGroup i) = IpeGroup $ i&amp;core %~ transformBy t</span></span> <span class="giallo-l"><span style="color: #E45649;">- ...</span></span></code></pre><h2 id="1-parser-change">(1) Parser change</h2> <p>The parser is the component of the compiler that transforms text into a memory structure the compiler can work with. This structure is called an abstract syntax tree.</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="diff"><span class="giallo-l"><span style="color: #E45649;">- Node4 {getMBB :: {-# UNPACK #-} ! MBB, getC1 :: ! (RTree a), getC2 :: ! (RTree a), getC3 :: ! (RTree a), getC4 :: ! (RTree a) }</span></span> <span class="giallo-l"><span style="color: #E45649;">- | Node3 {getMBB :: {-# UNPACK #-} ! MBB, getC1 :: ! (RTree a), getC2 :: ! (RTree a), getC3 :: ! (RTree a) }</span></span> <span class="giallo-l"><span style="color: #E45649;">- | Node2 {getMBB :: {-# UNPACK #-} ! MBB, getC1 :: ! (RTree a), getC2 :: ! (RTree a) }</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ Node4 {getMBB :: {-# UNPACK #-} !MBB, getC1 :: !(RTree a), getC2 :: !(RTree a), getC3 :: !(RTree a), getC4 :: !(RTree a) }</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ | Node3 {getMBB :: {-# UNPACK #-} !MBB, getC1 :: !(RTree a), getC2 :: !(RTree a), getC3 :: !(RTree a) }</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ | Node2 {getMBB :: {-# UNPACK #-} !MBB, getC1 :: !(RTree a), getC2 :: !(RTree a) }</span></span> <span class="giallo-l"><span> | Node {getMBB :: MBB, getChildren&#39; :: [RTree a] }</span></span> <span class="giallo-l"><span style="color: #E45649;">- | Leaf {getMBB :: {-# UNPACK #-} ! MBB, getElem :: a}</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ | Leaf {getMBB :: {-# UNPACK #-} !MBB, getElem :: a}</span></span> <span class="giallo-l"><span> | Empty</span></span> <span class="giallo-l"></span></code></pre> <p>This is a change from all the way back in 2020, where the <em>core</em> language changed by disallowing <code>!</code> before parens. Here the bang <code>!</code> indicates strict fields. Technically this doesn't fit into the category because the core language isn't a language extension. But semantics did change! Actually I don't think we expected to find something like this at all. I'm not sure how relevant this is to discuss further because it appears quite rare for someone to do this. You can enable <a rel="noopener external" target="_blank" href="https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/strict.html#extension-StrictData">StrictData</a> in your Cabal file and delete all those bangs!</p> <h2 id="2-rename-forall-identifiers">(2) Rename forall identifiers</h2> <p>This changes the forall identifier into a keyword at term level. It already was at the type level. The issue is discussed <a rel="noopener external" target="_blank" href="https://gitlab.haskell.org/ghc/ghc/-/issues/23719">here</a></p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="diff"><span class="giallo-l"><span> hintExplicitForall :: Located Token -&gt; P ()</span></span> <span class="giallo-l"><span> hintExplicitForall tok = do</span></span> <span class="giallo-l"><span style="color: #E45649;">- forall &lt;- getBit ExplicitForallBit</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ forAll &lt;- getBit ExplicitForallBit</span></span> <span class="giallo-l"><span> rulePrag &lt;- getBit InRulePragBit</span></span> <span class="giallo-l"><span style="color: #E45649;">- unless (forall || rulePrag) $ addError $ mkPlainErrorMsgEnvelope (getLoc tok) $</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ unless (forAll || rulePrag) $ addError $ mkPlainErrorMsgEnvelope (getLoc tok) $</span></span> <span class="giallo-l"><span> (PsErrExplicitForall (isUnicode tok))</span></span></code></pre><h2 id="3-typeabstractions">(3) TypeAbstractions</h2> <p>From what I understand from the <a rel="noopener external" target="_blank" href="https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/type_abstractions.html#type-abstractions">manual</a> is that part of the syntax for type abstractions landed in GHC 9.2, however 9.8 and onwards requires you to enable this language extension. This appeared because certain new functionality was introduced behind an old language extension flag, according to <a rel="noopener external" target="_blank" href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst#4type-arguments-in-constructor-patterns">this proposal</a>. It says we don't want to introduce new functionality behind established extensions, so that's why we require TypeAbstractions now, where previously ScopedTypeVariables and TypeApplications were enough.</p> <p>This extension enables you to bind type variables in pattern matches. I don't know why this happened like this, but it happened in 2023:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="diff"><span class="giallo-l"><span style="color: #50A14F;">+-- Invisible type binders in type declarations, such as</span></span> <span class="giallo-l"><span style="color: #50A14F;">+--</span></span> <span class="giallo-l"><span style="color: #50A14F;">+-- type family Sing @k</span></span> <span class="giallo-l"><span style="color: #50A14F;">+--</span></span> <span class="giallo-l"><span style="color: #50A14F;">+-- require the TypeAbstractions extension.</span></span> <span class="giallo-l"><span style="color: #50A14F;">+#if __GLASGOW_HASKELL__ &gt;= 909</span></span> <span class="giallo-l"><span style="color: #50A14F;">+{-# LANGUAGE TypeAbstractions #-}</span></span> <span class="giallo-l"><span style="color: #50A14F;">+#endif</span></span> <span class="giallo-l"><span style="color: #50A14F;">+</span></span></code></pre><h2 id="4-star-is-type">(4) Star is type</h2> <p>This change was announced via a warning. It tells users to write <code>Type</code> instead of <code>*</code> for kinds representing types. A kind is essentially the type of a type, and as a concept is used for type-level programming type safety.</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="diff"><span class="giallo-l"><span style="color: #E45649;">- type Basis v :: *</span></span> <span class="giallo-l"><span style="color: #50A14F;">+ type Basis v :: Type</span></span></code></pre><h2 id="conclusion">Conclusion</h2> <p>Often these breakages are annoying and frustrating. But if we look deeper, we find that each of them has a little story and good reasons for being introduced. If you find this all as interesting as I do, please consider joining some of the stability working group meetings!</p> <div class="footnote-definition" id="upstream"><sup class="footnote-definition-label">1</sup> <p>Upstreaming is the process of sending a patch to the “maintainers” of an open-source project. The maintainers will then make the patch ‘official’ by merging it. In principle, the process is simple, but in practice, the burden of proof (especially for larger projects) is on the person who submitted the patch. They have to convince the maintainers that the patch is useful, which takes time in the form of communication</p> </div> <div class="footnote-definition" id="meaning"><sup class="footnote-definition-label">2</sup> <p>The precise meaning of features enabled by language extensions. I guess parser changes also count.</p> </div> 2025-11-24T00:00:00+00:00 2025-11-24T00:00:00+00:00 Unknown https://blog.haskell.org/gsoc-2025/

<p>The Haskell.org committee is pleased to present the results of Haskell's participation in the Google Summer of Code 2025. This marks our 14th time taking part in GSoC!</p>

2025-08-19T00:00:00+00:00 2025-08-19T00:00:00+00:00 Unknown https://blog.haskell.org/ghc-9-14-1-alpha1/ <p>The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at <a rel="noopener external" target="_blank" href="https://downloads.haskell.org/ghc/9.14.1-alpha1">downloads.haskell.org</a>.</p> <p>GHC 9.14 will bring a number of new features and improvements, including:</p> <ul> <li> <p>Significant improvements in specialisation:</p> <ul> <li> <p>The <code>SPECIALISE</code> pragma now allows use of type application syntax</p> </li> <li> <p>The <code>SPECIALISE</code> pragma can be used to specialise for expression arguments as well as type arguments.</p> </li> <li> <p>Specialisation is now considerably more reliable in the presence of <code>newtype</code>s</p> </li> <li> <p>the specialiser is now able to produce specialisations with polymorphic typeclass constraints, considerably broadening its scope.</p> </li> </ul> </li> <li> <p>Significant improvements in the GHCi debugger</p> </li> <li> <p>Record fields can be defined to be non-linear when <code>LinearTypes</code> is enabled.</p> </li> <li> <p><code>RequiredTypeArgments</code> can now be used in more contexts</p> </li> <li> <p>SSE/AVX support in the x86 native code generator backend</p> </li> <li> <p>A major update of the Windows toolchain</p> </li> <li> <p>... and many more</p> </li> </ul> <p>A full accounting of changes can be found in the <a rel="noopener external" target="_blank" href="https://downloads.haskell.org/ghc/9.14.1-alpha1/docs/users_guide/9.14.1-notes.html">release notes</a>. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.</p> <p>Due to unexpected complications, this initial prerelease comes a bit later than expected. Consequently, we expect to have three condensed alphas prior to the release candidate. We expect the next alpha will come the week of 9 Sept. 2025, while the third will come 23 Sept. 2025, with the release candidate coming 7 Oct. 2025.</p> <p>We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.</p> <p>As always, do give this release a try and open a <a rel="noopener external" target="_blank" href="https://gitlab.haskell.org/ghc/homepage/-/issues/new">ticket</a> if you see anything amiss.</p> 2025-07-24T00:00:00+00:00 2025-07-24T00:00:00+00:00 Unknown https://blog.haskell.org/cabal-3-16-0-0-release/ <p>The Cabal release team brings you a new release of the cabal-install tool and accompanying libraries, version 3.16.0.0. This release supports the (not yet available) GHC 9.14, including its upcoming alpha. We expect to publish cabal-install 3.16.1.0 soon after GHC 9.14 is out and address any discovered issues and incompatibilities that can be fixed in the respective timeframe.</p> <p>The binaries for cabal-install are available:</p> <ul> <li>In the GHCup main channel (we thank the GHCup maintainers for the swift support of our release).</li> <li><a rel="noopener external" target="_blank" href="https://downloads.haskell.org/cabal/cabal-install-3.16.0.0/">On our website</a> (the same set of binaries can also be installed via the GHCup vanilla channel); these binaries are signed by "Francesco Ariis <a href="mailto:francesco@ariis.it">francesco@ariis.it</a>" (fingerprint: <code>DAFB 4D8A F684 1435 18D5 051F A9AF 0AAA 6B87 EC51</code>; the key is hosted on keyserver.ubuntu.com).</li> <li>As usual, <code>cabal update &amp;&amp; cabal install cabal-install-3.16.0.0</code> is an option too.</li> </ul> <h3 id="what-s-new">What's new</h3> <p>Some of the cool features in the release:</p> <ul> <li>The new <a rel="noopener external" target="_blank" href="https://cabal.readthedocs.io/en/stable/cabal-commands.html#cabal-target"><code>cabal target</code></a> command;</li> <li>Faster Git clones;</li> <li><code>cabal haddock-project</code> handles user-provided CSS;</li> <li>Multiple <code>flags</code> stanzas in <code>cabal.project</code> accumulate values instead of using the last one;</li> <li><code>cabal gen-bounds</code> works with multi-package projects (i.e., embraces the <code>v2</code>-commands infrastructure);</li> <li>Cabal multi-repl supports reexported-modules with renaming for GHC &gt;= 9.12, and more!</li> </ul> <p>See the <a rel="noopener external" target="_blank" href="https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.16.0.0.md">cabal-install release notes on Github</a> for the full changelog. Power users may be interested in <a rel="noopener external" target="_blank" href="https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.16.0.0.md">Cabal-the-library notes</a> too.</p> <h3 id="3-16-0-0-contributors">3.16.0.0 Contributors</h3> <p>The credits go to: Andreas Abel, Andreas Klebinger, Artem Pelenitsyn, Benjamin, Benjamin McRae, Berk Özkütük, Bodigrim, brandon s allbery kf8nh, Bryan Richter, Francesco Ariis, Francesco Gazzetta, Gleb Popov, Hécate Moonlight, James Blackburn, Jaro, Jasper Van der Jeugt, Javier Sagredo, Jens Petersen, Kazu Yamamoto, Kevin Quick, Leonid Znamenok, malteneuss, Matthew Pickering, Matt Parsons, Mike Pilgrem, Mikolaj Konarski, Moritz Angermann, noiioiu, parsonsmatt, Peter Becich, Phil de Joux, PHO, Praneya Kumar, Rebecca Turner, Rodrigo Mesquita, Sdywolf, Serge S. Gulin, Sergey Vinokurov, sheaf, Sylvain Henry, Teo Camarasu, theGhostJW, Tom Smeding, Trevis, Troels Henriksen, Yi Fang, Yuto Takano, zlonast, Zubin Duggal.</p> <p>We thank all the contributors as well as our reviewers, QA testers, devops, and others without whom this release wouldn’t be possible.</p> <h3 id="feedback">Feedback</h3> <p>Please report any issues you notice with the 3.16.0.0 release on our GitHub: <a rel="noopener external" target="_blank" href="https://github.com/haskell/cabal/issues">https://github.com/haskell/cabal/issues</a></p> <p>— Cabal release team (Artem, Brandon, Francesco, Mikołaj)</p> 2025-07-07T00:00:00+00:00 2025-07-07T00:00:00+00:00 Unknown https://blog.haskell.org/ghc-lts-releases/ <h1 id="ghc-will-start-maintaining-an-lts-release-branch-in-the-near-future">GHC will start maintaining an LTS release/branch in the near future</h1> <p>A release being designated LTS (Long Term Support) in this case means we plan to support it over a longer timeframe than usual.</p> <p>Concretely the plan is to provide updates for a LTS releases for <em>at least</em> two years. Most likely we will support LTS releases for even longer than that, aiming for a support window of three years currently.</p> <p>During this time we will be providing minor releases fixing bugs as with any other release. The main difference being that we will do so for a longer period of time.</p> <p>There are no plans to backport any new features to LTS releases after their initial release.</p> <p>In terms of frequency of LTS releases we plan to have an overlap between LTS support windows of different LTS series of six months.</p> <p>A potential timeline might then look like this:</p> <pre class="giallo" style="color: #383A42; background-color: #FAFAFA;"><code data-lang="plain"><span class="giallo-l"><span>2025 Aug - LTS 9.14 released</span></span> <span class="giallo-l"><span>2028 Spring - LTS 9.22 released</span></span> <span class="giallo-l"><span>2028 Summer - LTS 9.14.X - last 9.14 point release</span></span> <span class="giallo-l"><span>2031 Spring - LTS 9.X released</span></span> <span class="giallo-l"><span>2031 Summer - Last 9.22 point release</span></span> <span class="giallo-l"><span>…</span></span></code></pre><h1 id="non-lts-releases">Non-LTS releases</h1> <p>GHC will continue to release new major non-lts releases on a ~6 Month cadence. We expect to cut back on the lifetime of these releases slightly, dedicating the resources freed up this way to enable a longer support window for the LTS releases.</p> <h1 id="why-lts-releases">Why LTS releases?</h1> <p>In practice some releases always saw more adoption than others by users. The GHC Team has not been blind to this fact and has at times informally extended the life of a certain release based on this as well.</p> <p>This resulted in a sort of informal "post-hoc LTS" status of releases. At times with support windows not much shorter than our proposed minimum of two years.</p> <p>This worked reasonable well for people who were confident to stay on a fairly old release, only upgrading to a newer "post-hoc LTS" once the dust settled. It also worked out for those who picked one of those "post-hoc LTS" releases by happenstance before it was clear the release would end up as "post-hoc LTS".</p> <p>However users who adopted major releases which did not end up as "post-hoc LTS" often had to choose between upgrading earlier than expected, or risk running into a show stopping bug after the support window of the release had already ended. Similarly much of this was based on informal community sentiment and rarely written down explicitly. Making this information hard to access for members not deeply involved in the day to day of the haskell community.</p> <p>By designating a major release as LTS ahead of time we hope that users can make a informed decision about which GHC version they pick. Making it clear what the tradeoffs will be. With a clear choice between a longer support window or the newest features.</p> <h1 id="why-not-make-post-hoc-lts-releases-official-instead">Why not make post-hoc LTS releases official instead?</h1> <p>This is a question that has come up a lot in discussion. The major downsides of this are a lack of predictability, and that a lot of time might be lost between the initial release and any such decision. If we declare a release as LTS 9 months after its .1 release we essentially shaved off months from the LTS support window.</p> <p>On the flip side if we announce it ahead of time everyone knows that a given release will be the new LTS. So the hope is that this encourages more and quicker support for the release by the community. Hopefully compressing the timeline of bug fixing, testing and eventual widespread adoption.</p> <p>Overall I'm hopeful that LTS releases being explicit will remove a lot of ambiguity around GHC versions. And while the guaranteed LTS support window might not be as long as one might hope having LTS releases with longer guaranteed support window should still be helpful to people working on long running haskell projects.</p> <h1 id="next-steps">Next steps</h1> <p>The first LTS release will be GHC 9.14, which will be released this summer!</p> 2025-04-15T00:00:00+00:00 2025-04-15T00:00:00+00:00 Unknown https://blog.haskell.org/hls-2-10-0-0/

<p>The HLS Team is proud to announce the new release of the Haskell Language Server <code>2.10.0.0</code>!</p>

2025-03-31T00:00:00+00:00 2025-03-31T00:00:00+00:00 Unknown https://blog.haskell.org/stability-working-group/

<p>What is stability? What has the Haskell Foundation Stability Working Group been working on?</p>

2025-01-08T00:00:00+00:00 2025-01-08T00:00:00+00:00 Unknown https://blog.haskell.org/case-study-foreign-integration-js-browser/

<p>GHC since version 9.8 allows us to create callbacks from JS to Haskell code, which enables us to create full-fledged browser apps. This article shows how to use the JS backend with foreign component libraries.</p>

2025-01-06T00:00:00+00:00 2025-01-06T00:00:00+00:00 Unknown https://blog.haskell.org/ghc-9-12-cabal-3-14/

<p>To conclude the year 2024, the GHC and Cabal teams are happy to announce the releases of GHC 9.12 and cabal 3.14.</p>

2024-12-23T00:00:00+00:00 2024-12-23T00:00:00+00:00 Unknown https://blog.haskell.org/how-to-collect-performance-statistics-with-cabal/

<p>The <a rel="noopener external" target="_blank" href="https://cabal.readthedocs.io/en/latest/">Cabal Manual</a> now has a guide on how to collect performance statistics of Haskell applications.</p>

2024-11-21T00:00:00+00:00 2024-11-21T00:00:00+00:00 Unknown https://blog.haskell.org/gsoc-2024/

<p>The Haskell.org committee is pleased to present the results of Haskell's participation in the Google Summer of Code 2024. This marks our 13th time taking part in GSoC!</p>

2024-09-25T00:00:00+00:00 2024-09-25T00:00:00+00:00 Unknown https://blog.haskell.org/haskell-foundation-and-committee-merger/ <p>The members of the Haskell.org Committee (the Committee) and the directors of the Haskell Foundation (the Foundation) are pleased to announce that we have joined forces, with the aim (subject to regulatory approval) of merging Haskell.org, Inc. and Haskell Foundation, Inc. into a single not-for-profit corporation. Together we continue our common mission to advance functional programming and to advocate for the Haskell language, its ecosystem, and its community.</p> <h2 id="the-committee">The Committee</h2> <p>The Committee has a long history of supporting the Haskell community and ecosystem, supervising the resources under the "haskell.org" domain, including the www.haskell.org website, Hackage, Discourse, and the Haskell mailing lists, as well as organizing events such as Haskell.org’s participation in Google Summer of Code and the Haskell Summer of Code.</p> <h2 id="the-foundation">The Foundation</h2> <p>The Foundation is a newer organization, dedicated to broadening the adoption of Haskell by supporting its ecosystem of tools, libraries, education, and research. It has had similar goals to Haskell.org, and been engaged in complementary activities. Amongst its activities, it facilitates cross-team collaboration on fundamental tooling (e.g. Cabal, Stack, GHCup and the Haskell Language Server), hosts Stackage, financially supports the development of essential ecosystem components (e.g. the GHCup project and Botan bindings), runs workshops that help new contributors to fundamental tooling, and actively seeks financial sponsorship to help fund these efforts.</p> <p>Both corporations are Not-for-Profit corporations and Haskell.org Inc. has also been recognised as exempt from taxation in the USA. For that reason, most of the transactions of the Foundation are conducted by Haskell.org, Inc. One of the biggest factors in the desire to merge corporate entities is to make it easier to manage the legal and financial responsibilities around non-profit status and holding funds. Having only one corporation would also address a source of confusion for donors and sponsors.</p> <h2 id="what-next">What Next?</h2> <p>The Committee will continue to serve the community as an important committee of the Foundation. The Committee will retain all its current responsibilities, including independent editorial control of the Haskell.org website. It will also continue to oversee much of the Haskell community infrastructure and manage Haskell's participation in Google Summer of Code.</p> <p>Joining forces allows us to better share resources and work together while at the same time allowing the Committee (as part of the Foundation) to retain its independence over its domain.</p> <p>The Committee members and the directors of the Foundation remain deeply grateful for the opportunity to serve the Haskell community. We look forward to continuing this support with greater effectiveness and efficiency as a single unified organization.</p> <p>Sincerely,<br /> The Haskell.org Committee and The Haskell Foundation</p> 2024-09-15T00:00:00+00:00 2024-09-15T00:00:00+00:00 Unknown https://blog.haskell.org/documentation-best-practices-in-2024/

<p>In the Haddock team, part of our mission is to help with writing documentation, and promoting best practices. This article will help you write the best documentation you can!</p>

2024-09-15T00:00:00+00:00 2024-09-15T00:00:00+00:00 Unknown https://blog.haskell.org/report-of-js-code-minification/

<p>The JavaScript world has been battling for low bundle size from the very beginning. It is now our turn to enter the battle</p>

2024-09-15T00:00:00+00:00 2024-09-15T00:00:00+00:00 Unknown https://blog.haskell.org/the-haskell-playground/

<p>The playground (<a rel="noopener external" target="_blank" href="https://play.haskell.org">play.haskell.org</a>) allows you to run single-file Haskell programs right from your browser, and share them with others. In this post, I will introduce the playground and give some implementation details.</p>

2024-09-14T00:00:00+00:00 2024-09-14T00:00:00+00:00 Unknown https://blog.haskell.org/intro/ <p>The Haskell Ecosystem plays host to some amazing projects. Talented developers spend significant amounts of time, often their free time, helping develop, maintain, and support this ecosystem that all Haskell developers use. This space is for all of the developer teams that work on Haskell core infrastructure and power the Haskell Ecosystem.</p> <p>This blog will provide a space for these efforts to communicate with the wider Haskell community. Things you might see here: calls for volunteers, project updates, requests for comments/feedback.</p> <p>Blogs also form a key part of an ecosystem’s documentation. We’d like to take this idea to its conclusion in the Haskell ecosystem and provide a place for this high-value documentation to live and be maintained. In addition to helping out with editing, by hosting the posts here we’ll also have shared responsibility for maintaining the blog posts, helping prevent the all-too-common bit-rot that occurs on blog posts.</p> <p>There are already a few posts to get the ball rolling. We’re really excited to share these thoughts with you all.</p> <p>Happy Hacking,</p> <p>José Manuel Calderón Trilla</p>