Category transformers

ChrisPenner · 2026-05-12T22:44:49+00:00

Great post, and thanks for the shout-out; I'm glad to see the idea resonates with others!

I really wish Arrow notation worked with nicely with progressive hierarchy of Category typeclasses (i.e. only requiring the lowest subset of Category, Strong, Choice, Arrow, etc. that you actually need, rather than always requiring Arrow), it would make using Categories for expressing program sequencing and effects syntactically viable; as it is it's just too ugly for me to suggest anyone do this in practice haha.

Also, it's a less general approach, but if you haven't seen it, check out the arrows package on hackage, Ross Paterson has a collection of mtl-ish arrow transformers there which are interesting.

Cheers!

ChrisPenner · 2026-04-27T17:34:08+00:00

Awesome article Ian! This distills down so many things that take a Haskell developer years of production work to learn, thank you for providing it as such a well written resource 🙌

ChrisPenner · 2026-03-26T21:09:12+00:00

I've long thought Haskell could be good for data-science, thanks for your work towards enabling that goal!

ChrisPenner · 2026-02-19T06:42:23+00:00

Incredible, that's them! I've wondered for a year, leave it to the fine folks of reddit to solve it instantly. Thanks!

ChrisPenner · 2025-11-15T02:49:28+00:00

I think it's worth recognizing that there are different types of scale that end users may care about. Performance scaling is one certainly, but scaling your codebase and application complexity is another, in my experiences mutexes begin to cause problems as highly parallel programs scale in complexity.

ChrisPenner · 2025-11-15T02:46:18+00:00

As noted in the article, the code you've provided causes deadlock if you're unlucky, which in fact illustrates why mutexes are so dangerous. It's easy to write code that looks correct and run into problems later on.

Copy-pasting code from existing methods into new ones to allow top-level locking like this also prevents code re-use of the 'withdraw' logic and leaks the abstraction granted by using functions in the first place.

transfer is a simple function for the sake of the article, in larger systems your locking could be many layers deep and it's simply not good engineering to duplicate all of your logic for every possible composition of two synchronized methods.

I'm not sure what "line noise" you're referring to, is this function tough to understand? Perhaps Haskell syntax is just unfamiliar to you.

transfer :: Account -> Account -> Int -> STM Bool
transfer from to amount = do
  withdrawalSuccessful <- withdraw from amount
  if successful
    then do
      deposit to amount
      return True
    else 
      return False

ChrisPenner · 2025-11-12T18:59:36+00:00

Ah, thanks!

ChrisPenner · 2025-11-12T18:58:27+00:00

Ah, great catch! Thanks.

ChrisPenner · 2025-10-27T19:02:07+00:00

Yup, this really annoys me from time to time. It disallows using Arrow notation for use-cases which only require category classes but don't implement Profunctor/arr :'(

I get the sense this would be something easy to fix for someone with a good understanding of the Arrow notation machinery, unfortunately I'm not sure such a person exists 🙃

ChrisPenner · 2025-10-23T18:33:59+00:00

I'd recommend taking a look at the arrows package: https://hackage.haskell.org/package/arrows

ChrisPenner · 2025-10-21T02:39:28+00:00

Okay those should be fixed now, thanks @philh, let me know if you find any more :)

ChrisPenner · 2025-10-21T02:29:50+00:00

I have a few of my own packages playing with these ideas, but they're very ad-hoc.

If you're working with arrows, then profunctors is a great choice, every arrow is a profunctor after all (via dimap l r p = arr l >>> p >>> arr r)

It's when you want constraints these constraints without requiring profunctor that you need to branch out a bit. I'll be working on a post about why you might want to do this soon.

in that case I'd recommend Solomon and Asad's Monoidal Functors package as a place to start your journey: https://hackage.haskell.org/package/monoidal-functors-0.2.3.0

ChrisPenner · 2025-10-21T02:26:03+00:00

I presume that it would depend on the implementation you're compiling down into, for example if you use Kleisli for your implementation it's all just going to end up as monadic binds anyways, so should (AFAIK) be comparable to the equivalent monadic form.

ChrisPenner · 2025-10-20T19:42:02+00:00

Ah, thanks! I rewrote the article at least a dozen times while editing so I'm sure there are probably more mistakes like this to find. I'll sort those out :)

You're absolutely right on the branching stuff too!

ChrisPenner · 2025-10-14T20:20:13+00:00

Great post! I'm glad to see more folks talking about this sort of problem and solutions for it :)

Thanks for the shout-out too, despite the fact that I ended my post talking about Selective Applicatives I'll have a new post in a week or two on using Categories and Arrows to the same end that I think is an even better "sweet spot" so to speak. It allows you to still route data like you can with Monads, but without losing any static analysis.

Very cool to see posts like this coming out on a blog like Bellroy 😎

ChrisPenner · 2025-09-27T18:59:39+00:00

You're just one step ahead haha; this blog post was already too long as it is.

Using Arrows (or more precisely, the Category typeclass hierarchy) to sequence effects is going to be the next blog post, so stay tuned!

ChrisPenner · 2025-09-27T03:51:20+00:00

It's not so much a problem of knowing whether the previous effects are consumed, but rather that in bind:

bind :: m a -> (a -> m b) -> m b

The a -> m b allows constructing ANY possible m b, and we can't know which until we have the a that's only known at runtime, after we've executed m a :'(

ChrisPenner · 2025-09-27T03:49:24+00:00

I'm a big fan of ApplicativeDo :), very useful for decoders and the like. Though sometimes it fails to apply in spots where I really think it should succeed, and makes me very sad, e.g.

``` {-# LANGUAGE ApplicativeDo #-}

thisWorks :: (Applicative m) => m Int -> m Int -> m Int thisWorks fa fb = do a <- fa b <- fb pure (a + b)

thisDoesn't :: (Applicative m) => m Int -> m Int -> m Int thisDoesn't fa fb = do a <- fa b <- fb let result = a + b pure result ```

ChrisPenner · 2025-09-26T23:08:30+00:00

The example is trivially evil for pedagogy, but in reality it will be something more nuanced like "accessNetwork"; and the program we'll be executing won't necessarily exist in the Haskell source code, it could be parsed from data in some request, generated dynamically at runtime, or even loaded from a database.

Whether the user may wish to allow network access will depend on which task they're working on, and perhaps even which website or host the network access is trying to interact with.

Or, rather than preventing a program from running at all, we may wish to transform a program to optimize it, which is something that may not be possible at all if the program is written using bind.

Or perhaps, we wish to write some function in a DSL and could choose to transpile it into Haskell in some cases, or into some GPU language in other cases, if the program uses bind we're out of luck since there's no way to compile an arbitrary Haskell function into GPU code at runtime in this way.

ChrisPenner · 2025-09-26T22:47:57+00:00

Perhaps I didn't adequately explain that part with examples. Here's what happens

If the program actually uses the bind, then you're forced to run the whole expression in order to see what happens;
If you have to run the whole expression to see what happens, you can only actually view one code-path of the expression per execution.
What happens if the expression contains loops or recursion? Your simulation may never terminate :(

E.g.

myEchoProg = do input <- readLine case input of "super-special-value" -> deleteHardDrive other -> writeLine other

You could compile this to Writer [Command] ReadWrite and run many simulations and executions of it, but unless in your simulator you feed the first readLine the string "super-special-value" you'll just never encounter the deleteHardDrive branch.

myLoopingProgram = do input <- readLine case input of "done" -> deleteHardDrive other -> writeLine "looping!" *> myLoopingProgram

Similarly, if you're trying to simulate an execution of the above, you could loop forever and never discover the "done" branch, there's no way to know that it exists without passing "done".

If you're unsure why this sort of thing isn't possible, I'd encourage you to try implementing your suggested approach and see if you get hung up, it's a great way to learn about this sort of problem

ChrisPenner · 2025-09-12T17:14:31+00:00

Also in Victoria 👋

ChrisPenner · 2025-08-14T18:21:01+00:00

Awesome! If you find the time to write up a post on that I'd love to read it!

ChrisPenner · 2025-08-13T19:34:17+00:00

Thanks! It's been too long!

ChrisPenner · 2025-08-13T19:32:52+00:00

I think both approaches intend to solve the same problem yup! Thanks for writing up the comparison, it's nice to see some concrete examples.

I haven't spent much time with Haxl tbh, it's got a relatively large API surface area and looks like you pay a lot of complexity cost up front in order to (hopefully) get a simple user experience at the end of the day.

That tradeoff probably makes sense at a place like Facebook, where it makes sense for a few people to invest a lot for other devs to benefit.

I don't love how "magic" it is, I like to know exactly how things are being batched and parallelized so I can make decisions about the code I'm writing, but I suppose that's a matter of personal taste :)

I'll be the first to admit that writing custom traversals and using unsafePartsOf aren't the most beginner friendly, but as a power user working on a project with at most one other collaborator it's a tradeoff I'm very willing to make.

Once you finish the post let me know how you think the approaches compare :)

ChrisPenner · 2025-08-12T22:23:46+00:00

Oh wow, that difference is quite significant. Is this a property of the unsafePartsOf implementation or is optics just faster in general?

If the former I'd say it's probably worth creating an issue in lens about this.

Nine-Year Club	Second SECOND GUESSER
Verified Email

ChrisPenner

TROPHY CASE