# Romes' Musings A, tentatively, interdisciplinary blog from a Haskell enthusiast and GHC contributor. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Running out of Disk Space in Production DevFeed: [Running out of Disk Space in Production]() Original publisher: [Read original article]() Published: 2026-04-01T00:00:00Z Content type: article Language: en Sources: [Romes' Musings]() Topics: [Nix](), [Server](), [clickhouse](), [Grafana](), [nginx](), [Haskell]() Tags: [analytics](), [disk-space](), [logs](), [production](), [reverse-proxy](), [storage]() ### AI overview An incident report about a small NixOS server running out of disk space after a surge of customers downloaded large Kanjideck files. The author investigates full-disk errors, identifies Plausible Analytics and the Nix store as major consumers, and tries clearing logs, the Nix store, and ClickHouse tables; the supplied excerpt ends while space is still being consumed. ### Source excerpt Last night I put up a simple server which allowed customers to download the digital Kanjideck files. This server is hosted on a small Hetzner machine running NixOS, at 4GB of RAM and 40GB of disk space. One of these downloadable files weights 2.2GB. The matter at hand boils down to a simple Haskell program which serves static files (with some extra steps regarding authorization) plus an nginx reverse proxy which proxies requests to a certain "virtual host" to the Haskell program. Fig 1. Simplified server architecture 1 First, Panic Not even minutes after I announced that the files were finally available, hundreds of customers visited my server all at once. As the logs started flying off of my screen with all the accesses, I started noticing a particularly interesting message, repeated over and over again: Mar 31 20:43:03 mogbit kanjideck-fulfillment[2528300]: user error (Unexpected reply to: MAIL "<...> at kanjideck.com", Expected reply code: 250, Got this instead: 452 "4.3.1 Insufficient system storage\r\n") Oh no. No one's able to access their files and I'm already receiving emails about it. I messaged the users explaining the server was having some issues that I was resolving. Grafana shows 40GB/40GB disk space used up, so does df -h have 100% usage of /dev/sda. I have to clear up space fast. I'm afraid at this point that I'm not even receiving the user complaints anymore since my mail could be getting dropped by lack of space. I rushed to run du -sh on everything I could, as that's as good as I could manage. The two larger culprits were /var/lib's Plausible Analytics, with a 8.5GB (clickhouse) database, and the /nix/store with the full server configuration, installation, and executables, at 15GB. (In hindsight, I should have stopped right here to think carefully about what could possibly be occupying the remaining 20GB. I assumed "the rest of the files", but looking back the "rest of the files" could hardly total 20GB.) Delete everything that I can. First off, t ## How I turned my Anki side project into a Kickstarter: A Walkthrough DevFeed: [How I turned my Anki side project into a Kickstarter: A Walkthrough]() Original publisher: [Read original article]() Published: 2026-01-30T00:00:00Z Content type: opinion Language: en Sources: [Romes' Musings]() Topics: [Learning]() Tags: [kickstarter](), [project](), [side-project]() ### AI overview A personal walkthrough of developing Kanjideck from an Anki side project into a physical product and launching it on Kickstarter. It covers manufacturing and testing, company formation, accounting, pricing, digital infrastructure, marketing, burnout, and seeking help as a solo entrepreneur. ### Source excerpt Contents 1 The initial idea (August 2024) 1.1 What if ? 2 Manufacturing physical cards (September 2024) 3 Starting a Company in the U.S. (October 2024) 3.1 Accounting and Taxes 4 Spreadsheets and Pricing (November 2024) 5 Digital Infrastructure (December 2024) 6 Marketing and Ads (January 2025) 7 Burn-out (March 2025) 8 Reaching out for help (October 2025) 9 Launching on Kickstarter (January 2026) 9.1 Murphy's Law 10 Conclusion I think this is my first non-Haskell related post on this blog! This time, I want to walk through how I successfully launched Kanjideck on Kickstarter starting from zero, in my spare time. I want to go over the initial side project, how that turned into a more ambitious idea, manufacturing and testing a physical product, setting up a company, spreadsheets, setting up the digital infrastructure for the business, marketing and ads, burn-out, launching, and reaching out for help as a solo entrepreneur. 1 The initial idea (August 2024) In the summer of 2024, with nothing to do after having finished reading "Babel" by R. F. Kuang (a book which happened to be about language and etymology and that I thoroughly enjoyed), I decided to get back to learning Japanese. Japanese is a challenging language to learn (at least in the West). Mostly, that's due to Kanji, one of the three types of characters used in written Japanese. Hiragana and Katakana are phonetic scripts, where to each symbol corresponds exactly one sound, and there are about 50 of each (these can be learnt in about a week). On the other hand, there are about 2,136 Kanji needed for fluency1. Each Kanji is a (potentially complex) symbol with one or more readings and one or more meanings. Anyway, that means there are a lot of Kanji to memorize. I'm a big fan of spaced repetition and Anki. If you don't know about spaced repetition, see "How to Remember Anything Forever-ish". I had tried to study Kanji seriously in the past, but the resources I was using at the time, despite using them consisten ## Haskell Debugger for GHC 9.14 DevFeed: [Haskell Debugger for GHC 9.14]() Original publisher: [Read original article]() Published: 2026-01-07T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [debugging](), [Haskell](), [Neovim](), [Visual Studio Code](), [Protocol (disambiguation)](), [GitHub Issues]() Tags: [bytecode](), [crashes](), [debugger](), [debugging](), [editor](), [haskell](), [issue](), [performance](), [protocol](), [vscode]() ### AI overview This article announces that the Haskell Debugger is ready for GHC 9.14 and explains how to install it and configure editors through the Debug Adapter Protocol. It covers VSCode and Neovim integration, project-based session configuration, robustness goals, current limitations, and planned callstack and multithreading support. ### Source excerpt This post was first published inline to the Haskell Discourse, where there was some discussion about the debugger: 1 The Haskell Debugger for GHC 9.14 The Haskell Debugger is ready to use with GHC-9.14! The installation, configuration, and talks can be found in the official website. The tl;dr first step is installing the debugger: $ ghc --version # MUST BE GHC 9.14 The Glorious Glasgow Haskell Compilation System, version 9.14.1 $ cabal install haskell-debugger \ --allow-newer=base,time,containers,ghc,ghc-bignum,template-haskell \ --enable-executable-dynamic # ON WINDOWS, DO NOT PASS --enable-executable-dynamic ... $ ~/.local/bin/hdb --version # VERIFY IT'S THE LATEST! Haskell Debugger, version 0.11.0.0 The second step is configuring your editor to use the debugger via the Debug Adapter Protocol (DAP). - For VSCode, install the haskell debugger extension. - For Neovim, install nvim-dap and configure it for haskell-debugger - For other editors, consult your DAP documentation and let others know how! Bug reports and discussions are welcome in the haskell-debugger issue tracker. My MuniHac 2025 talk also walks through the installation, usage, and design of the debugger. Do note much has been improved since the talk was given, and much more will still improve. 1.1 A little bit more info The debugger work is sponsored by Mercury. It's the project in which I've spent most of my full working days (for almost a full year now), with the invaluable help from my team at Well-Typed. The debugger is meant to work both on trivial files and on large and complex codebases1. It is a GHC application so all features are supported. Like HLS, it also uses hie-bios to automatically configure the session based on your cabal or stack project. Robustness is a main goal of the debugger. If anything doesn't work, or if you have performance issues, or something crashes, please don't hesitate to submit a bug. We've got a small but respectable testsuite, and have tested performance by debugging G ## Lazy Linearity for a Core Functional Language (POPL 2026) DevFeed: [Lazy Linearity for a Core Functional Language (POPL 2026)]() Original publisher: [Read original article]() Published: 2025-11-26T00:00:00Z Content type: article Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Compiler]() Tags: [compiler](), [evaluation](), [functional](), [haskell](), [language](), [optimisations](), [paper](), [types]() ### AI overview The article announces that the paper "Lazy Linearity for a Core Functional Language" will be published at POPL 2026. It explains a type system that captures linearity under Haskell's non-strict evaluation and is intended to support optimisations of linear Core programs. ### Source excerpt I'm very proud to announce that Lazy Linearity for a Core Functional Language, a paper by myself and Bernardo Toninho, will be published at POPL 26! [DOI, ACM]. The extended version of the paper, which includes all proofs, is available here [arXiv, PDF, DOI]. The short-ish story: In 2023, for my Master's thesis, I reached out to Arnaud Spiwack to discuss how Linear Types had been implemented in GHC. I wanted to research compiler optimisations made possible by linearity. Arnaud was quick to tell me: "Well yes, but you can't!" "Even though Haskell is linearly typed, Core isn't!"1 Linearity is ignored in Core because, as soon as it's optimised, previously valid linear programs become invalid. It turns out that traditional linear type systems are too syntactic, or strict, about understanding linearity - but Haskell, regardless of linear types, is lazily evaluated. Improving optimisations would have to wait. Our paper presents a system which, in contrast, also accepts programs that can only be understood as linear under non-strict evaluation. Including the vast majority of optimised linear Core programs (with proofs!). The key ideas of this paper were developed during my Master's, but it took a few more years of on-and-off work (supported by my employer Well-Typed) with Bernardo to crystalize the understanding of a "lazy linearity" and strengthen the theoretical results. Now, the proof of the pudding is in the eating. Go read it! Abstract Traditionally, in linearly typed languages, consuming a linear resource is synonymous with its syntactic occurrence in the program. However, under the lens of non-strict evaluation, linearity can be further understood semantically, where a syntactic occurrence of a resource does not necessarily entail using that resource when the program is executed. While this distinction has been largely unexplored, it turns out to be inescapable in Haskell's optimising compiler, which heavily rewrites the source program in ways that break syntactic l ## Automatically Packaging a Haskell Library as a Swift Binary XCFramework DevFeed: [Automatically Packaging a Haskell Library as a Swift Binary XCFramework]() Original publisher: [Read original article]() Published: 2025-07-05T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Swift](), [interoperability](), [Library](), [Automation](), [Framework](), [macOS]() Tags: [apple](), [automation](), [build](), [building](), [framework](), [haskell](), [interoperability](), [library](), [macos](), [swift]() ### AI overview This tutorial presents xcframework, a Haskell library released on Hackage that automates packaging Haskell code as a Swift binary XCFramework. It explains how to build the Haskell library with Cabal, create a Swift package from the resulting artifacts, and use the package from Swift projects through XCFramework bundles and headers. ### Source excerpt Contents 1 Announcing: xcframework 1.1 XCFrameworks 1.2 How to install xcframework 1.3 How to use the XCFramework in XCode 1.4 Building simple Swift package 1.5 Must use Cabal Foreign Library stanza 1.6 Conclusion I've written about Haskell x Swift interoperability before. Calling Haskell from Swift is about marshalling and the foreign function interface. But Creating a macOS app with Haskell and Swift tells the much messier tale of hijacking XCode to vodoo together the Haskell library, its headers, and two handfuls of other magic ingredients into one buildable SwiftUI application. Stop! Don't click on the last link. No, it turns out that my XCode sallies strayed very far from the yellow brick road. The IDE is confused. Recompilation bugs abound. Complexity is through the roof juggling .modulemaps, .xcconfig dynamic settings, and sketchy .sh scripts. Let's walk the happy path. 1 Announcing: xcframework Perhaps obvious in retrospect, the demon-less way to add a Haskell library to the dependencies of a Swift application is to build an independent Swift Package wrapping the Haskell library - something that can be done without XCode in sight. Easy peasy: Build the Haskell library using Cabal Create a Swift package from the Haskell artifacts Add the Swift package as a dependency to the project And it turns out that (1) and (2) can be merged together using Cabal SetupHooks! Moreover, I'm happy to announce I've neatly packaged and released that build process automation as a Haskell library called xcframework on Hackage. Onwards! - for what it does and how to use it. 1.1 XCFrameworks Apple introduced XCFramework bundles back in a WWDC19 session. An XCFramework is a multiplatform binary framework bundle. For our purposes, that means we can create a Swift Package just from a binary linkable artifact and a couple of header files. Then, any Swift project can depend on this binary Swift package and call the functions exposed to the headers and make sure the bundled library will ## Implementing Unsure Calculator in 100 lines of Haskell DevFeed: [Implementing Unsure Calculator in 100 lines of Haskell]() Original publisher: [Read original article]() Published: 2025-04-25T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Development](), [math]() Tags: [article](), [expression](), [haskell](), [list](), [monad](), [numbers](), [operations](), [range]() ### AI overview This tutorial implements an Unsure Calculator in Haskell. It introduces a range operator for uncertain values, models calculations with a probability monad and normal distributions, samples results using pseudo-randomness, and builds an embedded calculator expression language. ### Source excerpt Contents 1 Unsure Calculator 1.1 Sampling it up 1.2 Calculator Expressions 1.3 Showing up 1.4 Conclusion 1 Unsure Calculator The recently trendy Unsure Calculator makes reasoning about numbers with some uncertainty just as easy as calculating with specific numbers. The key idea is to add a new "range" operator (written ~) to the vocabulary of a standard calculator. The range x~y denotes that a real value is uncertain, but we are 95% sure that it falls between x and y1. Reading the notation is easy: when you see 10~15, you say: "ten to fifteen". Arithmetic operations and friends (e.g. sin, or log) transparently operate on ranges and literal numbers alike. Calculation results in a plot with a range of values that the input expression can take, and with what frequency. The motivation behind the original article is neat, so I'll just recommend you read it there to learn how and why you'd use such a calculator. Here's a real life example they used: 1400~1700 * 0.55~0.65 - 600~700 - 100~200 - 30 - 20 Now, let's implement it. 1.1 Sampling it up Summon a probability monad from the void2. data Dist a where Return :: a -> Dist a Bind :: Dist b -> (b -> Dist a) -> Dist a Normal :: Double -> Double -> Dist Double instance Monad Dist where (>>=) = Bind instance Applicative Dist where pure = Return; (<*>) = ap instance Functor Dist where fmap = liftM The monad instance is free: pure = Return and (>>=) = Bind. The Normal constructor denotes a normal distribution given the standard deviation and mean. With do-notation we can easily construct a complex tree mixing Returns, Binds, and Normals. For instance: d = do s <- Normal 0 1 return (5 + s) desugars to d = Bind (Normal 0 1) (\s -> Return (5 + s)) Then, embue meaning onto a Dist a by allowing an a to be sampled according to the distribution the Dist represents. We use StdGen from random as a source of uniform pseudo-randomness: sample :: StdGen -> Dist a -> a sample g d = case d of Return x -> x Normal mean std_dev -> n1 * std_dev ## Planning Weekly Workouts in 100 lines of Haskell DevFeed: [Planning Weekly Workouts in 100 lines of Haskell]() Original publisher: [Read original article]() Published: 2024-08-14T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Programming](), [Code]() Tags: [code](), [haskell](), [programming](), [script]() ### AI overview A short tutorial demonstrates how to build a standalone 100-line Haskell workout planner using the logict logic-programming monad. The program generates weekly schedules satisfying running and bodyweight-exercise constraints. ### Source excerpt Contents 1 A workout planner in 100 lines of Haskell I have recently started doing some outdoors bodyweight workouts. I also want to start running again, but I'm recovering from a minor knee injury until the start of next month. Tonight I decided to put together a weekly schedule to start following next month. The first pen and paper versions were fine, but I wasn't completely satisfied. The next logical step was to write a quick program to see what possible plans I was missing. The schedule must satisfy a few constraints, but the core of it is that I should do, every week, on one axis, one short run (high-intensity) and one long run (long distance), and, on the other axis, have two pull days (as in pull-ups), two push days (as in push-ups), and two leg days (as in squats). Finding a weekly workout that satisfies certain constraints is an answer-set-programming kind of problem, best solved by some kind of logic programming. Rather than turning to Prolog or Clingo, I decided to just stick to Haskell and use the logic-programming monad from logict! 1 A workout planner in 100 lines of Haskell What follows is mostly just the demonstration of using logict applied to this particular problem. I believe the weeklySchedule function can be easily understood in general, even by anyone unfamiliar with Haskell and/or logic programming - and that's the meat of this short post and program. Note that the program is a cabal shell script which can be run by executing the script file (as in ./ScheduleExercise, as long as cabal is in path). It is standalone, and exactly 100 lines (with comments, shebangs and everything). Feel free to try and modify it! #!/usr/bin/env cabal {- cabal: build-depends: base, logict -} import Control.Applicative import Control.Monad import Control.Monad.Logic import Data.List import Data.Maybe workout = ["Push day", "Pull day", "Leg day", "No workout"] running = ["Long run", "Short run", "No run"] weekdays = ["Seg.", "Ter.", "Qua.", "Qui.", "Sex.", "Sab.", " ## Calling Haskell from Swift DevFeed: [Calling Haskell from Swift]() Original publisher: [Read original article]() Published: 2024-04-02T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Swift](), [interoperability](), [data type](), [iOS](), [macOS](), [Xcode](), [SwiftUI]() Tags: [data-type](), [haskell](), [interoperability](), [ios](), [macos](), [metaprogramming](), [swift](), [swiftui](), [tutorial](), [xcode]() ### AI overview This tutorial explains how to call non-trivial Haskell functions from Swift in native macOS and iOS applications. It uses foreign function exports, argument and result marshaling, serialization of user-defined data types, and Swift interoperability so Haskell functions can be exposed through Swift structs, classes, and idiomatic interfaces. ### Source excerpt Contents 1 Introduction 2 Marshaling Inputs and Outputs 2.1 Haskell's Perspective 2.2 Swift's Perspective 3 Metaprogramming at the boundaries 3.1 Haskell's perspective 3.2 Swift's perspective 4 Remarks This is the second installment of the in-depth series of blog-posts on developing native macOS and iOS applications using both Haskell and Swift/SwiftUI. This post covers how to call (non-trivial) Haskell functions from Swift by using a foreign function calling-convention strategy similar to that described by Calling Purgatory from Heaven: Binding to Rust in Haskell that requires argument and result marshaling. You may find the other blog posts in this series interesting: Creating a macOS app with Haskell and Swift The series of blog posts is further accompanied by a github repository where each commit matches a step of this tutorial. If in doubt regarding any step, check the matching commit to make it clearer. This write-up has been cross-posted to Well-Typed's Blog. 1 Introduction We'll pick up from where the last post ended - we have set up an XCode project that includes our headers generated from Haskell modules with foreign exports and linking against the foreign library declared in the cabal file. We have already been able to call a very simple Haskell function on integers from Swift via Haskell's C foreign export feature and Swift's C interoperability. This part concerns itself with calling idiomatic Haskell functions, which typically involve user-defined datatypes as inputs and outputs, from Swift. Moreover, these functions should be made available to Swift transparently, such that Swift calls them as it does other idiomatic functions, with user defined structs and classes. For the running example, the following not-very-interesting function will suffice to showcase the method we will use to expose this function from Haskell to Swift, which easily scales to other complex data types and functions. data User = User { name :: String , age :: Int } birthday :: Use ## Computed Properties for Haskell Records DevFeed: [Computed Properties for Haskell Records]() Original publisher: [Read original article]() Published: 2023-11-30T00:00:00Z Content type: article Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [properties](), [data type](), [Swift](), [C]() Tags: [c](), [data-type](), [extension](), [haskell](), [properties](), [rust](), [swift]() ### AI overview This article explains Haskell record types and related syntax extensions, including OverloadedRecordDot and NamedFieldPuns. It then introduces computed properties by comparing Haskell records with properties in Swift, C#, and Java. ### Source excerpt Contents 1 Records in Haskell 1.1 Overloaded Record Dot 1.2 Named Field Puns 2 Computed Properties 3 Conclusion 1 Records in Haskell Haskell has so-called record types, which are also commonly known as structs, for instance, in C, Swift, and Rust. To define a square, one would write: data Point = Point { x :: Int , y :: Int } data Square = Square { topLeft :: Point , bottomRight :: Point } mySquare = Square{ topLeft = Point{x = 0, y = 0} , bottomRight = Point{x = 2, y = 2} } mySquareWidth = x (bottomRight mySquare) - x (topLeft mySquare) In Haskell record types are just syntactic sugar for ordinary product types paired with functions that get and set these fields. In essence, the above is not fundamentally different from having the following standard product types and functions: data Point = Point Int Int data Square = Square Point Point x, y :: Point -> Int x (Point px _) = px y (Point _ py) = py topLeft, bottomRight :: Square -> Point topLeft (Square tl _) = tl bottomRight (Square _ br) = br -- And setters... 1.1 Overloaded Record Dot However, by turning on the OverloadedRecordDot syntax extension, you can use more syntactic sugar to project the fields of a record instead of using the field name as a standard function: {-# LANGUAGE OverloadedRecordDot #-} mySquareWidth = mySquare.bottomRight.x - mySquare.topLeft.x which is neat! I like OverloadedRecordDot. It looks clean and feels more like using proper property of the record data type. It is also less ambiguous for an LSP to suggest the record properties of a data type by typing after the ., than it is to suggest functions to apply to the record type argument. 1.2 Named Field Puns Since I'm already writing about records, I'll mention another extension I quite enjoy: NamedFieldPuns. Traditionally, when matching on a record, you can list the field names and bind variables to the value associated with that field. Continuing the above example: area :: Square -> Int area Square{topLeft = tl, bottomRight = br} = (br.x ## Creating a macOS app with Haskell and Swift DevFeed: [Creating a macOS app with Haskell and Swift]() Original publisher: [Read original article]() Published: 2023-11-10T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Swift](), [SwiftUI](), [interoperability](), [Development](), [macOS](), [Library](), [iOS](), [iOS development](), [Xcode]() Tags: [development](), [haskell](), [interoperability](), [ios-development](), [library](), [macos](), [swift](), [swiftui](), [tutorial](), [xcode]() ### AI overview This tutorial series explains how to build a native Apple-platform application with a SwiftUI interface and Haskell-based data and logic. The first part covers setting up a Haskell foreign library, exposing a function through the C FFI, compiling and linking it with a Swift executable, and calling it from a SwiftUI app. ### Source excerpt Contents 1 Hello, Swift, it's Haskell! 1.1 Setting up the SwiftUI app 1.2 Setting up a Haskell foreign library 1.3 Linking the Haskell library with the executable 1.4 The RTS must be initialized 2 Remarks 2.1 Further Reading This is the first part of an in-depth guide into developing a native applications for Apple platforms (macOS, iOS, etc.) using Haskell with Swift and SwiftUI. This is the first in a series of blog posts - covering the set-up required to call Haskell functions from Swift in an XCode project using SwiftUI. In future installements of the series, I intend to at least discuss calling functions with idiomatic Haskell types with Swift ones (both with and without marshaling), SwiftUI observation, and iOS development which requires GHC to produce code for the iOS compilation target. At the time of writing I'm using XCode 15, Cabal 3.10, and GHC 9.8. There will be some features I use that are only available in these recent versions, however, the general idea of interoperability between Haskell and Swift stands on its own regardless - the now 7 year old swift-haskell-tutorial is still similarly relevant and greatly informed my approach, despite the end result being considerably different. The end goal is to create a multi-(apple)-platform application whose UI is programmed in Swift using SwiftUI while the data and logic of the application is implemented in Haskell which is called from Swift. The series of blog posts is further accompanied by a github repository where each commit matches a step of this tutorial. If in doubt regarding any step, simply checking the matching commit for absolute confidence you are understanding the practical step correctly. Visit this link to the haskell-x-swift-project-steps repository! Furthermore, I'm writing a build tool that will facilitate setting up and building a project like this without having to go through all the manual steps: haskell-swift. This write-up has been cross-posted to Well-Typed's Blog. 1 Hello, Swift, i ## Introducing ghc-toolchain to GHC DevFeed: [Introducing ghc-toolchain to GHC]() Original publisher: [Read original article]() Published: 2023-10-02T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [toolchain](), [Compiler](), [Haskell](), [Go Language]() Tags: [ci](), [compilation](), [compiler](), [toolchain](), [x86]() ### AI overview The article introduces ghc-toolchain, a new Haskell-based approach for configuring GHC compilation toolchains. It is intended to replace the existing ./configure logic, make toolchains configurable after GHC installation, improve maintainability and testing, and support GHC's longer-term goal of runtime retargeting for cross-compilation. ### Source excerpt Contents 1 Compiler Toolchains 2 The runtime-retargetable future of GHC 3 Introducing ghc-toolchain 4 Migration to ghc-toolchain 5 Future work 6 Conclusion GHC, like most high-level language compilers, depends upon a set of tools like assemblers, linkers, and archivers for the production of machine code. Collectively these tools are known as a toolchain and capture a great deal of platform-dependent knowledge. Traditionally, developers generate a ./configure script using the venerable autoconf tool, then users execute this script when they install a GHC binary distribution. The ./configure script determines the location of programs (such as the C compiler) and which options GHC will need to pass them. While this autoconf-centric model of toolchain configuration has served GHC well, it has two key issues: For cross-compiling to a different platform, it would be highly valuable to users if GHC would become a runtime-retargetable compiler (like rustc and go). That is, the user should be able to download a single GHC binary distribution and use it to compile not only for their local machine, but also any other targets that GHC supports. The ten-thousand-line sh file that is GHC's ./configure script has historically been challenging to maintain and test. Modifications to the ./configure script are among the most risky changes routinely made to the compiler, because it is easy to introduce a bug on some specific toolchain configuration, and infeasible to test all possible configurations in CI. To address these issues, we are introducing ghc-toolchain, a new way to configure the toolchain for GHC, which will eventually replace the existing toolchain configuration logic in the ./configure script. Its main goal is to allow new compilation toolchains to be configured for GHC at any point in time, notably after the compiler has been installed. For example, calling ghc-toolchain --triple=x86_64-w64-mingw32 will configure a compilation toolchain on the host machine capable of pr ## Writing prettier Haskell with Unicode Syntax and Vim DevFeed: [Writing prettier Haskell with Unicode Syntax and Vim]() Original publisher: [Read original article]() Published: 2023-06-21T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Vim]() Tags: [haskell](), [syntax](), [vim](), [writing]() ### AI overview This tutorial explains how GHC Haskell's UnicodeSyntax extension lets programmers use Unicode symbols for selected keywords and identifiers. It also shows how Vim digraphs provide convenient two-key input for Unicode symbols, with examples of common Haskell notation and configuration options. ### Source excerpt Contents 1 Haskell's Unicode Syntax Extension 2 Digraphs in Vim 3 Conclusion 1 Haskell's Unicode Syntax Extension Haskell (well, GHC Haskell) features an extension called UnicodeSyntax. When enabled, this extension allows the use of certain unicode symbols in place of their corresponding keywords. A great example is the forall keyword being equivalent to the unicode symbol ∀, the two of which can be used interchangebly when UnicodeSyntax is enabled. Furthermore, with Haskell being a unicode-friendly language, one can define common Haskell functions, operators or type variables using unicode symbols - which doesn't even require UnicodeSyntax to be enabled. For example, one can define the predicate ∈ on lists as an alias for elem as follows: -- 5 ∈ [1,3,5] == True (∈) :: ∀ α. Eq α => α -> [α] -> Bool (∈) = elem In practice, I use just a handful of unicode symbols both as keywords and as identifiers, but a mostly comprehensive list of the keywords that have unicode alternatives is presented in the GHC user's guide UnicodeSyntax extension page. Specifically, in most of my programs you can be sure to find the following: ∀ instead of forall, which is faster to input than the whole word. A lot of unicode type variables, α, β, τ, σ, δ, κ, ρ - they are really easy to type too. ⊸ instead of %1 ->, to use the so-called "lollipop" notation for linear functions. In my opinion, those are low-hanging niceties (with vim) that make the program look better overall, but there are others that I haven't yet reached for which you may still find good/useful. For example, there's a library in hackage, containers-unicode-symbols, which exposes multiple unicode variants of functions on containers (Maps,Sets,...) such as ∈,∉,∅,∪,∩,⊆,⊈. Finally, I usually add default-extensions: UnicodeSyntax to my cabal file to make the extension available by default on all modules. However, you can also enable it on a per module basis as usual with {-# LANGUAGE UnicodeSyntax #-} at the top of the module. 2 Dig ## Monthly Update on a Haskell Game Engine DevFeed: [Monthly Update on a Haskell Game Engine]() Original publisher: [Read original article]() Published: 2023-01-01T00:00:00Z Content type: opinion Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Game engine](), [Programming](), [shaders](), [glsl](), [Graphics]() Tags: [code](), [haskell](), [programming](), [render](), [shaders](), [technical](), [vulkan]() ### AI overview A monthly development update on Ghengin, an unreleased Haskell game engine. It describes a procedural-planets demo and outlines the engine's Vulkan renderer, FIR shaders embedded in Haskell, entity management, scene graph, render queue, and supporting libraries. ### Source excerpt Contents 1 Ghengin 1.1 Bullets on Technical Details 1.2 The Small Victories 1.3 A peek into the code 1 Ghengin I've been working the past month or two in a game engine titled Ghengin (pronounced /ɡɛn-ʤɪn/, never /ɡɛn-ɡɪn/). This is not yet a release, and version 0.1.0 is far into the future. However, I've come a long way and I'd like to share a few pictures of my progress. This post was migrated from the discussion at the Haskell Discourse The demo I've been working on is based on Sebastian Lague's series Procedural Planets. It is a showcase of procedurally generated planets you can move around in and tweak the procedural generation parameters of the planets to create oceans and continents. Fig 1. Screenshot of planets demo 1.1 Bullets on Technical Details I hope to, soon enough, write a more substantial explanation of the engine's technical challenges and overall design decisions so far, and on the game developer's facing side of the engine. In the meantime, here are a few key points regarding the technical feats of the engine along with the main libraries it currently depends on, which help create a picture of how it is working: The renderer is written using the great bindings to the Vulkan API The shaders are crucial in the overall design, and a lot of code depends on their definition (e.g. preparing render pipelines, allocating descriptor sets and textures, everything materials related ...). The shaders are written using FIR, an amazing shader language embedded in Haskell! The entity management, scene graph and render queue are done/created through the apecs entity component system. Vectors and matrices are from geomancy GLFW-b for window management and user input (used as the window backend for vulkan) The dear-imgui bindings for the GUI JuicyPixels for loading textures FIR is a really cool shader library and unlike any you've likely tried before (it's embeded in Haskell, but that's just the start). The shader's "interfaces" are defined at the type level, and in ## Equality Saturation in Haskell, a tutorial DevFeed: [Equality Saturation in Haskell, a tutorial]() Original publisher: [Read original article]() Published: 2022-08-23T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Tutorial](), [Math and Logic]() Tags: [haskell](), [mathematics](), [tutorial](), [types]() ### AI overview A Haskell tutorial introduces equality saturation and e-graphs through hegg, a Haskell-native library based on egg. It develops a simple symbolic mathematics library that simplifies numeric expressions using rewrite rules, covering syntax, language definitions, e-class analysis, cost functions, rewrite rules, and equality saturation. ### Source excerpt Contents 1 Symbolic Maths in E-graphs 1.1 Syntax 1.2 Language 1.3 Analysis 2 Equality saturation on symbolic expressions 2.1 Cost function 2.2 Rewrite rules 2.3 Equality saturation, finally hegg is a Haskell-native library providing fast e-graphs and equality saturation, based on egg: Fast and Extensible Equality Saturation and Relational E-matching. Suggested material on equality saturation and e-graphs for beginners egg: Fast and Extensible Equality Saturation in a 5m video egg's users guide To get a feel for how we can use hegg and do equality saturation in Haskell, we'll write a simple numeric symbolic manipulation library that can simplify expressions according to a set of rewrite rules by leveraging equality saturation. I hope to eventually write a better exposition that assumes less prior knowledge which introduces first e-graphs-only workflows, and only then equality saturation, from a hegg user's perspective. Until then, this rough tutorial serves as an alternative. 1 Symbolic Maths in E-graphs If you've never heard of symbolic mathematics you might get some intuition from reading Let's Program a Calculus Student first. First, we define our symbolic maths language and enable it to be represented by an e-graph using hegg. 1.1 Syntax We'll start by defining the abstract syntax tree for our simple symbolic expressions: data SymExpr = Const Double | Symbol String | SymExpr :+: SymExpr | SymExpr :*: SymExpr | SymExpr :/: SymExpr infix 6 :+: infix 7 :*:, :/: e1 :: SymExpr e1 = (Symbol "x" :*: Const 2) :/: (Const 2) -- (x*2)/2 You might notice that (x*2)/2 is the same as just x. Our goal is to get equality saturation to do that for us. Our second step is to instance Language for our SymExpr 1.2 Language Language is the required constraint on expressions that are to be represented in e-graph and on which equality saturation can be run: type Language l = (Traversable l, ∀ a. Ord a => Ord (l a)) To declare a Language we must write the "base functor" of SymExpr (i.e. ## Graphical Applications in Haskell with FRP and Reflex DevFeed: [Graphical Applications in Haskell with FRP and Reflex]() Original publisher: [Read original article]() Published: 2022-07-10T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Functional programming](), [Reflex FRP](), [ui](), [real-time](), [Programming](), [Declarative programming]() Tags: [functional](), [functional-programming](), [haskell](), [programming](), [reactive](), [reactive-programming](), [real-time](), [user-interface]() ### AI overview This article introduces functional reactive programming for interactive graphical user interfaces in Haskell. It explains how behaviours represent values that vary continuously over time and events represent occurrences at particular points in time, allowing programmers to describe reactive systems without handling time-related implementation details directly. The article also covers Reflex and building user interfaces with Reflex-Dom. ### Source excerpt Contents 1 Functional Reactive Programming 1.1 Behaviours 1.2 Events 2 Reflex 2.1 Building UIs with Reflex-Dom 2.2 Reflex Combinators 3 Example: 101companies 1 Functional Reactive Programming Functional reactive programming is a general paradigm well suited to programming real-time systems in a high-level and functional way. Real-time systems or reactive systems are those that handle continuous time-varying values, discrete events in real time, and react accordingly. A good example of these systems is a mobile robot. They must take into consideration continuous inputs like wheel speed, orientation, and discrete events such as detection of another object. The class of reactive systems we're interested in here is interactive graphical UIs. A user interface has multiple components that can be seen as discrete events and continuous time-varying values. An input box, where one might write their name, is an example of a time varying value (it continously changes - whenever the user types something); a button is an example of a discrete event in time: at certain points in time the user will click the button. This will make more sense with practice and code samples. So the promise of functional reactive programming is that we can program these complicated reactive systems in a pure functional way. But how? Functional Reactive Programming introduces two key concepts: Behaviours and Events. Behaviours are first-class values that vary over continuous time. That means a behaviour is a value that changes with time and can be passed to/returned by functions. Events are first-class values that occur at some points in time. They may refer, e.g., to happenings in the real world time - such as a mouse click or a key press. And then, it says that the FRP implementation will handle all time-related details so that the programmer can describe their reactive system without thinking about what happens at any particular point in time, but rather thinking about what happens accross all poin ## Graphical Applications in Haskell with MVC and Gloss DevFeed: [Graphical Applications in Haskell with MVC and Gloss]() Original publisher: [Read original article]() Published: 2022-06-27T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [mvc](), [Functional programming](), [Haskell](), [Graphics](), [Library](), [User Interfaces](), [Simulation]() Tags: [functional-programming](), [graphics](), [haskell](), [library](), [mvc](), [simulation](), [user-interfaces]() ### AI overview This article explains the model-view-controller pattern and how it maps to functional programming in Haskell. It uses the Gloss library to build a graphical application and illustrate the model, view, and event-handling components with a simple employee simulation. ### Source excerpt Contents 1 MVC 2 Functional MVC: Gloss 2.1 Picture 2.2 Event 2.3 Gloss 1 MVC Model-view-controller (MVC) is a software architectural pattern commonly used for developing user interfaces that divide the related program logic into three interconnected elements. MVC says that an interactive application should consist roughly of three main parts - Model, View, and Controller. The Model is the data and state that we need to keep track of to model our application. If you're programming a Chess game, the model could consist of the state of the board (which pieces are where), the time passed since the last player played, whose turn it is, etc... The View is the definition of how our model should be displayed to the user. Intuitively, you can think of it as a function Model -> UI (and begin to see how functional MVC might be interesting). For the above example, the view would define how the chess board can be shown to the user (a 3d object, a 2d ascii board, ...), where the time passed shows up in the screen, etc. The Controller handles all events and interactions with the application and how they modify the existing model. In chess, the controller could define that when a player drags a piece in the board, the position of that piece in the board model changes to the new position, the current turn changes to the other player, and the time passed is reset to zero. And the three relate in the following manner: MVC diagram from Wikipedia 2 Functional MVC: Gloss How does the model-view-controller idea translate into functional programming? It turns out to be quite simple because the three parts match basic FP concepts. We'll focus on the library Gloss to develop a graphical application. Gloss is very easy to setup, provides abstractions for drawing graphics, and outlines the MVC compoonents clearly. We'll implement a simple simulation of the 101companies employees to illustrate the concepts. To define the model, the structure which is updated thorought the program, we simply define ## Haskell 102 Lecture Notes DevFeed: [Haskell 102 Lecture Notes]() Original publisher: [Read original article]() Published: 2022-05-08T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Functional programming](), [Programming]() Tags: [code](), [function](), [functional-programming](), [haskell](), [programming](), [programming-languages](), [types]() ### AI overview Lecture notes introducing Haskell function types, currying, partial application, higher-order functions, laziness, recursion, recursive data structures, and type classes. ### Source excerpt Contents 1 Functions Types, Currying, Partial application, Higher-order functions 2 Laziness 3 Recursion: Inductive Method 4 Recursive data structures 5 Type Classes 6 Type Classes Kinds, Constraints 1 Functions Types, Currying, Partial application, Higher-order functions All functions have a type, the function type: length :: [a] -> Int length [] = 0 length (x:xs) = 1 + length xs The same way we think about the Either type constructor, and about the tuple type constructor (,), we can think about the function type type constructor (the arrow ->). They are all type constructors that take two arguments. data Either a b = Left a | Right b data (,) a b = (a, b) -- pseudo code data (->) a b = a -> b -- pseudo code This means that the (->) type constructor, when applied to two types a and b, creates a new type a -> b, where a is the input type and b the return type. This beggets the question, what is the type of a function that takes two arguments? There are two ways to define multi-argument functions. The first would be to think about functions that receive multiple arguments in a tuple. prepend :: (Char, String) -> String prepend (c, str) = c:str You could even use it like this prepend('h', "ello"), which somewhat resembles the imperative style function call. The second option is to have a function take one argument a, and return a function that takes another argument b and only then returns c. prepend :: Char -> (String -> String) prepend c = (\str -> c:str) And this is the most common way to have multi-argument functions in functional programming languages. In Haskell, thinking about two argument functions and functions that return functions is really the same thing. The most common way of writing the two argument function prepend in Haskell, read "prepend is a function that takes two arguments of type Char and String and returns String", would be prepend :: Char -> String -> String prepend c str = c:str The (Char, String) -> String version is said to be an uncurried ## Haskell 101 Lecture Notes DevFeed: [Haskell 101 Lecture Notes]() Original publisher: [Read original article]() Published: 2022-05-04T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Functional programming](), [Programming language](), [Programming]() Tags: [abstraction](), [constructor](), [function](), [functional-programming](), [haskell](), [pattern-matching](), [polymorphism]() ### AI overview Haskell 101 lecture notes introducing functions, function abstraction and application, expressions, values, types, algebraic data types, construction and deconstruction, pattern matching, polymorphism, and type constructors. ### Source excerpt Contents 1 Functions, Computations: Abstraction and application 2 Expressions, Values, Types 3 ADTs, Construction, Deconstruction 4 Polymorphism 5 Non-nullary type constructors, Kinds 1 Functions, Computations: Abstraction and application What is a function? f(x) = 4x + 2? And what's function application? f(x) = 4x + 2 f(5) = ? In mathematics, function application is the act of applying a function to an argument from its domain so as to obtain the corresponding value from its range. In this sense, function application can be thought of as the opposite of function abstraction. In functional programming languages, computations are based on function abstraction and application. An abstraction, a.k.a a function, is denoted through the lambda notation (\x -> ...). An application, a.k.a function application, is denoted by juxtaposition: an expression followed by another expression represents the application of the first expression to the following one. f = \x -> 4 * x + 2 -- `f` is an abstraction f 5 -- application of `f` to `5` 2 Expressions, Values, Types Haskell is a purely functional programming language. As such, all computations are done via the evaluation of expressions (syntactic terms) to yield values (abstract entities that we regard as answers). Every value has an associated type (intuitively, we can think of types as sets of values). 5 :: Integer 'a' :: Char inc :: Integer -> Integer [1,2,3] :: [Integer] ('b', 4) :: (Char, Int) sum [1,2,3] :: Integer inc 5 :: Integer sum :: [Integer] -> Integer The :: can be read "has type". All expression evaluate to a value, and all values have types, which means all expressions have types too. Above are some of the common types. Which of the following are expressions, and which are values? What are the types of the expressions? product [1,2,3] product [1,2,3] They are all expressions, and only the first two are values. The first one is a function abstraction, which is a value, the second one is a value constructed with the