Defining an IO Context in Kotlin

Duncan McGregor explores using Kotlin context receivers to mark impure IO actions and enforce functional programming boundaries at compile time.

In the last episode (youtu.be/UOY0aSpwksE) we learned to distinguish actions from calculations, or, as functional programmers would have it, impure from pure functions. We saw that calculations are easier to test, refactor and reason with, but actions tend to proliferate, because code that calls an action becomes an action itself. We would like to minimize the proportion of actions, so we used annotations to mark them to warn us when they appear. The problem with annotations is that the compiler doesn't really understand them, so it can't tell if we have missed an annotation. We tried here (youtu.be/eXKKrYc6Myg) but couldn't find any way to make it work. The compiler does (mostly) understand the new context receivers though, so in this episode we try using contexts to mark actions, starting with the most common reason for code being impure - IO. Thanks to Jordan Stewart (twitter.com/damaged) for collaborating on this, part 66 of an exploration of where a Test Driven Development implementation of the Gilded Rose stock control system might take us in Kotlin. You can see the whole series as a playlist youtube.com/playlist?list=PL1ssMPpyqociJNwykAOB9_KEZVW7BW7m2 and the code on GitHub github.com/dmcg/gilded-rose-tdd If you like this, you’ll probably like my book Java to Kotlin, A Refactoring Guidebook (java-to-kotlin.dev). It's about far more than just the syntax differences between the languages - it shows how to upgrade your thinking to a more functional style. I have some free time between producing videos and working for team Gilded Rose. If you like these videos I'd like to work with you - please get in touch - duncan@oneeyedmen.com