Direct-style effects, also known as algebraic effects and effect handlers, are the next big thing in programming languages. They are already available in Unison and OCaml, are coming to Scala, and I'm seeing discussion about them in other closely-related-to-industry contexts.
The goal is very simple: to allow us to write code in a natural style without monads, but still get the benefits of reasoning and composition that monads bring. At the same time I see some confusion about direct-style effects. In this post I want to address this confusion by explaining the what, the why, and the how of direct-style effects using a Scala 3 implementation as an example.
There is quite a bit going on here. First we'll talk about the problem we're trying to solve and the constraints we're operating under. Then we'll look at a simple implementation in Scala 3 and describe the language feature, contextual functions, that enables it. Next up we'll see some shortcomings of this implementation and see how they can solved by two language features, one well known (delimited continuations) and one in development (type system innovations). Finally I'll give some pointers to more about information on this topic.
For the next edition of Scala with Cats I'm writing a section on implementing interpreters. In my research I ended up going fairly deep down the rabbit hole of optimizations, in which virtual machine dispatch is a major area. There are many different approaches to dispatch, and I struggled to relate them until I realized they were all variations on a basic structure that resulted from applying the principle of duality. Duality is one of the major themes of the book, so I was happy to make this discovery. However I think going deep into optimization is not appropriate for the book so I'm writing this up here instead.
ScalaBridge London is a community for learning Scala, for people who are underrepresented in technology. We last met in 2020, stopping when COVID made it impossible to continue. I want to restart ScalaBridge London. Here's the plan. If you'd like to take part, please signup.
I'm rewriting my books to include new material and target Scala 3. I'm opening sponsors so you can encourage me to finish faster.
Function programming is based1; that is, based on principles that allow a systematic and repeatable process for creating software. In this post I'm going illustrate this process with an example of summing the elements of a list, inspired by this conversation. We'll mostly be looking at algebraic data types and structural recursion (which often uses pattern matching, but is not synonymous with it).
For me, a working functional programmer, this process is one of the main advantages of FP. It means I can spend my mental cycles on understanding the problem, knowing that once I have done so the implementation follows in a straightforward way. The inverse also holds: if someone uses these principles to write code I can easily work out what problem it solves.