Unformed Delta - haskell

7 Haskell effect systems

Mon, 27 Apr 2026 06:40:00 +0000

An overview of Haskell’s effect systems that I’ve used.

This was written pretty hastily for Inkhaven. I hope to return to this and add more details later.

IO

The simplest “effect system” in Haskell that has been around since the beginning. As an effect system, this just divides functions into pure and impure.

This has a little bit of a special status because Haskell’s main function is declared main :: IO (), meaning that all other effect systems must eventually delegate to IO.

mtl

Monad transformers allow extending a monad with extra capabilities. This allows creating large stacks of monad transformers with a bunch of different effects, e.g. StateT AppState (ExceptT AppError (ReaderT Configuration IO a)).

This quickly gets unwieldy because effects from lower layers need to be lifted through the upper layers.

mtl adds type classes for common kinds of effects, e.g. MonadState, MonadError, MonadReader which can be implemented generically to avoid needing to lift through monad transformers.

As an added benefit this also makes it easier to test functions. A function requiring only MonadState can just as easily be implemented using a pure function.

The worst part about mtl is that declaring new effects requires implementing every relevant type class when declaring a new effect. Conversely, implementing a new type class requires adding an implementation for every relevant monad transformer.

This is called the \(n^2\) instances problem. It’s possible to work around this for the most part with Haskell: the OVERLAPPABLE MonadTrans instance pattern, but it still requires more boilerplate than other effect systems we will see.

ReaderT IO / unliftio

ReaderT IO makes the observation that most custom effects can easily be represented by IO anyways.

Instead of implementing MonadState with StateT it can just as easily be implemented by manipulating an IORef in IO. Why use separate exceptions from ExceptT when IO exceptions can achieve the same purpose?

Because extra parameters are still annoying to pass around, it’s common to still use the ReaderT type to remove boilerplate associated with passing them.

Finally, unliftio makes it easier to express higher order operations like bracket. Because ReaderT isn’t stateful it’s possible to “unlift” it, which makes it possible to represent more generic error handling operations.

It remains a little bit hard to define custom effects and reinterpret them flexibly with this approach. To implement a pure version of an effect, you still often end up stuck with the complexity of monad transformer stacks and the \(n^2\) instances problem.

polysemy

Algebraic effect systems attempt to get rid of the boilerplate involved in defining custom type classes for effects once and for all. They also try to implement fancier algebraic effect patterns.

Based on the weaving pattern introduced by Effect Handler’s in Scope, this library is based on free monads, keeping track of an open union of capabilities.

fused-effects

fused-effects is pretty much like polysemy but uses type classes instead of an open union. This provides a bit more efficiency at runtime trading off for greater boilerplate.

in-other-words

in-other-words is the most creative effect system I’ve seen so far. It provides a really ergonomic interface by providing granular primitive effects that encapsulate higher order effect patterns. User defined effects can be translated into these effects, which makes gets rid of some of the complexity imposed by polysemy and fused-effect’s weaving pattern.

In practice its biggest flaw is its lack of documentation, and the raw complexity of the effects it offers. Some of its effects are extremely general, and reasoning through how they can be instantiated into something useful is really hard.

effectful

Effectful is the application of ReaderT IO / unliftio’s lessons to algebraic effect systems. It implements everything in terms of IO, but wraps it up in a neat interface that makes it easier to work with.

It’s also able to provide a reasonably safe pure interface.

This is currently my favorite effect system for new projects.

an expressive programming language

Wed, 08 Apr 2026 05:43:00 +0000

Thanks to Alok Singh for the rough format and inspiration to write this post.

I tried naming as may programming languages as I could and came up with these before I got bored: C Rust Perl Bash Zsh Fish Zig C++ D Visual Basic Prolog Racket Elisp VimScript Lua Ruby Idris Agda Rocq C# F# F* Clojure Kotlin Scala Java ECMAScript TypeScript Raku Python OCaml Standard ML Jai Pony koka Cyclone Unison Swift Objective C Piet J APL Brainfuck Purescript Elm JIF (Java Information Flow) moss LLVM CUDA MLIR x86 ARM MIPS

But Haskell is my favorite.

Why?

It’s expressive. Things that other languages must implement as builtin features, can and are implemented as libraries. This gives you the power to customize the language however you see fit.

In most languages the and && operator needs special compiler treatment to ensure that false && doSomethingExpensive() doesn’t evaluate doSomethingExpensive() unnecessarily. In Haskell laziness gives you this for free. The && operator can be defined in the standard library just like any other function without any special compiler treatment:

(&&) :: Bool -> Bool -> Bool
True  && b = b
False && _ = False

If you evaluate False && someExpensiveComputation, laziness means that the second clause never evaluates someExpensiveComputation, the computation only needs to see that the first argument is False to produce its result.

But there’s a problem with laziness. It makes it hard to predict what order things will get evaluated in, because you need to look at the implementation of your function to know what order its arguments will be evaluated in. For IO like reading a file or printing to the console you need a way to guarantee the order things run in. Haskell adopted do notation and monads for this purpose. But it turns out that it’s a very general abstraction that generalizes exception handling, async/await, generators (e.g. yield), and many other things.

But so far we’ve only listed two language features: laziness and monads. By “avoiding success at all costs” Haskell has accumulated decades of experimental language features produced by programming languages research. This allows Haskell to absorb features and express patterns invented in pretty much any other programming language.

RSpec is a Ruby library for writing unit tests. It lets you describe the behaviors of your program using near natural language syntax.

RSpec.describe Order do
  it "sums the prices of its line items" do
    order = Order.new
    order.add_entry(LineItem.new(:item => Item.new(
      :price => Money.new(1.11, :USD)
    )))
    order.add_entry(LineItem.new(:item => Item.new(
      :price => Money.new(2.22, :USD),
      :quantity => 2
    )))
    expect(order.total).to eq(Money.new(5.55, :USD))
  end
end

Without even needing to resort to macros HSpec embeds a very similar syntax:

spec :: Spec
spec = describe do
  it "sums the prices of its line items" do
    let order = orderFromEntries
      [ LineItem
          { price = Money { value = 1.11, currency = USD }
          , quantity = 1
          }
      , LineItem
          { price = Money { value = 2.22, currency = USD }
          , quantity = 2
          }
      ]
    orderTotal order `shouldBe` Money { value = 5.55, currency = USD }

There’s even database libraries like squeal that embed SQL syntax in a type safe way without needing macros:

getUsers :: Statement DB () User
getUsers = query $ select_
  (#u ! #name `as` #userName :* #e ! #email `as` #userEmail)
  ( from (table (#users `as` #u)
    & innerJoin (table (#emails `as` #e))
      (#u ! #id .== #e ! #user_id)) )

Personally that’s too many operators and too complicated types even for me, but I like the idea that it’s possible in the programming language I use. Maybe someday I’ll have a problem for which that complexity is worth it. The thing that I love the most about Haskell is that people do these things even if its not worth it.

Through clever encodings, it’s even possible to do anything you can do in a dependently typed programming language/proof assistant like Lean and Rocq with a little bit extra boilerplate.

The languages with features I envy

When writing Haskell, there’s still some languages left with features that I envy:

Any programming language with fast compile times: I used to work at a company with a ~2 million lines of code Haskell codebase. It took 3-4 hours to compile from scratch.
True dependently typed programming languages (like Lean, Idris, Agda, Rocq) are way more ergonomic for any kind of advanced type level programming. Haskell’s working on becoming Dependent Haskell, but it’s still a really long way off.
Languages with better macro systems, mostly Racket, who’s macro system is powerful enough to implement Hackett, a #lang pragma that more or less implements Haskell in Racket.
Rust: while Haskell has linear types, they are not nearly as mature as Rust’s uniqueness types for resource management.
Prolog: logic programming can be more declarative than laziness.

My dream is a programming language that can subsume all of these features.

Epilogue

I’m not sure there is a perfect programming language, nor will there probably ever be. Perhaps someday there’ll be a programming language that combines all the features I like. Perhaps Lean will be perfected. But who knows, for now Haskell is still my favorite programming language.

Haskell: the re-export module X pattern

Sat, 04 Apr 2026 22:46:00 +0000

Haskell’s syntax for declaring module exports is clunky and second-class. Exports must be declared after the module header either by name, or re-exporting an entire module:

module Foo
  ( bar,
    module Baz,
  )
where

import Baz

bar :: Int
bar = 42

This re-exports all of the identifiers exported by Baz. If instead you only wanted to re-export some of the identifiers, naively you would need to list them all out individually:

module Foo
  ( bar,
    baz1
  )
where

import Bar
import Baz

Just reading the export list, it can be unclear which module the identifiers are being imported from: e.g. is bar actually exported by Bar or is it actually provided by Baz.

The re-export module X pattern is a simple trick to solve this problem. Instead of re-exporting identifiers individually, use a qualified import to say up front which identifiers you plan to re-export:

module Foo
  ( module X,
  )
where

import Bar as X (bar)
import Baz as X (baz1)

This makes it easy to see which modules and which identifiers we are re-exporting identifiers from, no matter how many. X is conventionally used as the module name, i.e. eXport.

There’s two primary scenarios where I reach for this pattern:

building a custom prelude: Custom preludes need to re-export lots of identifiers from lots of different modules. To provide some internal organization and make your prelude more discoverable it’s often useful to break them into submodules, e.g. MyPrelude.Effects, MyPrelude.MaybeEither.
building a utility module extending another module: Maybe you have a custom combinator for operating on maps not provided by Data.Map.Strict. I like putting this kind of combinator in a Utils.Map module, and then also re-exporting everything I want to use from Data.Map.Strict. Then you can just import qualified Utils.Map as Map instead of needing to also import qualified Data.Map.Strict as Map.

The following example demonstrates a couple of important gotchas:

module Foo
  ( module X,
  )
where

import Bar as X (bar)
import qualified Baz as X (baz1)

bar :: Int
bar = 42

Perhaps unexpectedly, this example exports Bar.bar instead of Foo.bar. Also, if you try using (e.g. bar + 1) or re-exporting (e.g. adding bar or module Foo to Foo’s export list) bar you’ll get Ambiguous occurrence ‘bar’. You can disambiguate by exporting the fully qualified module name, i.e. adding Foo.bar or Bar.bar to the export list (instead of doing import Bar as X (bar)).

Additionally, though Foo looks like it might, it doesn’t actually re-export baz1. In order for an identifier to be re-exportable, it must be imported unqualified.

Here’s an example that demonstrates a couple of useful tricks:

module Foo
  ( module X,
  )
where

import Bar
import Bar as X (bar)
import Baz as X hiding (bar2)

Note that you can have multiple imports of the same module, here Bar. This can be useful when you’re providing some functions that work with the types in an existing module, but don’t want to re-export the whole original module.

Finally, note that using hiding lets you re-export a whole module less some identifiers, here Baz. This can be useful when you want to re-export everything but one of your identifiers conflicts.

Haskell: Strict vs Lazy ByteString

Mon, 01 Sep 2025 04:35:00 +0000

The Haskell ecosystem’s preferred way of representing binary data is the ByteString type. The bytestring introduces its two variants like so:

Strict ByteStrings keep the string as a single large array. This makes them convenient for passing data between C and Haskell.

Lazy ByteStrings use a lazy list of strict chunks which makes it suitable for I/O streaming tasks.

Otherwise, the documentation expresses little preference between strict and lazy ByteStrings.

The broader library ecosystem often offers functions for working with both lazy and strict ByteStrings. For example, in aeson exposes decode which decodes a json value from a lazy ByteString in addition to a strict variant decodeStrict. From this, it’s reasonable to assume that lazy ByteString is the default, because aeson exposes it unqualified, while relegating strict to a section with “Variants for strict bytestrings”.

However, as a general rule, I recommend sticking to strict ByteStrings as a default:

more memory efficient: lazy ByteStrings include extra bookkeeping overhead for maintaining its list of strict ByteString chunks.
reads are faster: in a strict ByteString, reading any position in the string is just reading from an offset in memory. For a lazy ByteString its necessary to follow pointers for values later in the bytestring.
O(1) conversion to lazy ByteStrings: converting a lazy ByteString to a strict one is O(n), requiring copying the lazy ByteString’s chunks into a single contiguous block of memory. Strict ByteStrings don’t need to be split into smaller chunks, the existing memory reused.
avoid lazy IO: while often convenient seeming, lazy IO leads to hard to diagnose bugs, like IOExceptions being thrown from pure code. You’re generally better off using a streaming framework like conduit, pipes or streamly together with strict ByteStrings.

Output oriented APIs, like serialization, are the one scenario where lazy ByteStrings make a good amount of sense:

builders produce lazy ByteStrings: Data.ByteString.Builder only exposes toLazyByteString for converting a Builder into an actual ByteString. It takes an O(n) conversion to turn the result into a strict ByteString.
concatenation of lazy ByteStrings is more efficient: lazy ByteString’s list of chunks allows appending new chunks without copying entire buffers of data. Use a builder instead of concatenating lazy ByteStrings directly to avoid creating lots of small inefficient chunks if possible though!
APIs for encoding/serializing often produce lazy ByteStrings: because of the above its common for serialization operations like aeson’s encode to only expose versions producing a lazy ByteString.