[wavemode]

The article requires familiarity with Haskell, as well as the concept of Backpacks: https://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/

The author then uses Backpacks to achieve ad-hoc polymorphism without typeclasses.

There is a well-known article from a long time ago which was conceptually similar: https://www.haskellforall.com/2012/05/scrap-your-type-classe...

Which highlighted the fact that typeclasses can basically be thought of as an additional vtable argument passed to every function that has typeclass constraints. (And, indeed, thinking about them this way often allows one to avoid typeclasses entirely and achieve the same kind of polymorphism in simpler and more flexible ways.)

Backpacks can achieve something similar, except by declaring an abstract "signature" for your dependency, rather than a function argument. (Backpacks can also be used to do a lot more than this, of course, but that's outside the scope of the OP article.)

[throwaway81523]

I think Oleg Kiselyov also has a post somewhere explaining how you can use Ocaml modules to do something similiar to Haskell typeclasses.

[jadbox]

This was a wonderful comment that added a lot of value to the article for me. I have a random curiosity if this was generated by a model or human written. I'm hoping for the later as this seems too well processed to be a LLM, but I'd like to check my assumption.

[wavemode]

All human lol. I was very into Haskell when I was in college, and Scrap Your Typeclasses was always one of my favorite articles.

There has always been a sort of fascination with effect systems and dependency inversion in the Haskell community. You cannot throw a stone in any discussion board without hitting someone currently noodling on the problem of "man, typeclasses are cumbersome and don't compose well. What if we had something better?"

Transformers and mtl were the name of the game for a long time. Then for a while there was a LOT of hype around free monads and algebraic effect systems. When I was deeply into Haskell, at the time it sometimes felt like a new effect system library was being released every week.

Then there was also this counter-movement of people going "all this new-fangled stuff is overly complicated. Why don't we just use plain functions?" (see [0]).

And there were also a lot of people saying "well, if you just write your whole application in ReaderT IO, you can get 90% of the effects juice for only 10% of the complexity squeeze" (see [1]).

Meanwhile, this whole time we have had distant voices in the back pointing out that OCaml has already solved this problem, and Haskell should just introduce a feature for first-class modules. Well, now it's here, and it's called Backpack.

[0]: https://www.simplehaskell.org/

[1]: https://academy.fpblock.com/blog/2017/06/readert-design-patt...

[tome]

> there were also a lot of people saying "well, if you just write your whole application in ReaderT IO, you can get 90% of the effects juice for only 10% of the complexity squeeze"

I think 90% is an overestimate because you don't get any encapsulation. Maybe 50% is a more reasonable number. If you want 99% of the effects juice for 1% of the complexity squeeze, my effect system, Bluefin0[1], as well as the effectful[2] effect system

My recent talk "A History of Effect systems"[3] explains this in more detail, as does the "Why even use an effect system"[4] section of the latest Bluefin documentation.

[1] https://hackage-content.haskell.org/package/bluefin

[2] https://hackage-content.haskell.org/package/effectful

[3] https://www.youtube.com/watch?v=RsTuy1jXQ6Y

[4] https://hackage-content.haskell.org/package/bluefin-0.0.17.0...

[jadbox]

Super helpful. Thank you again for even more context here. I'm curious now to dig into Backpack.