Hands on Capture Checking
Introduction
I gave a live coding session on capture checking at Scala Days 2025. Let’s be honest: it was essentially a failure, mostly because I have very little live coding experience and woefully underestimated how long it’d take to go through the material. I was stopped maybe 10% in, much to my annoyance and that of Martin Odersky, who’d kindly agreed to be there and help with the questions I was likely to get. This article is a form of apology for my failure: at least the material is available somewhere!
The rest of this introduction is how the whole talk came about, because I find it entertaining, but it’s also mostly irrelevant to the actual content of the article. If you’re interested in capture checking more than my life - why would you be?! - you should probably skip to the technical bits.
I never really intended to give a talk on capture checking - or even study it, to be honest. Not for a long while, at least. Capture checking is still actively being worked on, and I hate aiming at a moving target, struggling to understand a concept just to find out it’s outdated by the time I’m done.
But then I noticed something which captured (wink, nudge) my interest: whenever Martin would go on stage to talk about capabilities and how they will allow us to use a direct style of programming without losing any of the nice properties afforded us by continuation passing style or monadic style, he would invariably say something along the lines of and of course for all this to work reliably we’ll need capture checking, but that’s really a detail. That’s really a detail. I’ve used that exact phrasing many times, and it was always either a grand act of self delusion, or me attempting to convince some manager to approve a project they really shouldn’t approve. It was interesting to hear Martin use these words.
So I decided to try and see if I could understand what the fuss was all about. To give some context to that decision, I’d been travelling, having just left Tokyo and now finding myself in Hawaii because that’s apparenly my life now, very jetlagged, my brain in one timezone, my body in another and they weren’t talking with each other. It didn’t feel unreasonable to start studying something where all the material was either in academic papers (I don’t know about you, but my brain is not wired to read those) or in documentation that was either outdated or a copy/paste of said academic papers or both, whose error messages were explicitly designed for the feature’s implementers rather than its users and often read like an exercise in obfuscation… I can’t say it was an easy task. But, about a week in, I came to the conclusion that I’d understood everything I needed to use capture checked libraries. Not write them, probably - some features are still a little terrifying, such as reach capabilities or capture set polymorphism - but good enough for the moment at least.
That’s when I coincidentally received an email from one of the Krakow Scala User group organizers telling me they were having an event, and since I was going to be in town, why don’t I give a talk, it’s going to be very informal, there’s only going to be a few of us, I should come, it’ll be fun.
And I thought - I don’t have slides. It usually takes me between 7 weeks and 7 months to write slides, I only had 7 days, that was clearly not going to happen, but maybe I could try live coding? I’m notoriously terrible at that (as evidenced by my Scala Days performance), but there was only going to be a few people, surely it’d be fine. I also thought that I didn’t have a story for my explanation yet, and 7 days was clearly not going to be long enough for me to come up with one. I’d be travelling, working, hopefully sleeping at some point that’d be a nice change, there was no way I’d find the time. So - and this should tell you how jetlagged I was - I decided, why not improvise? If you’ve seen any of my talks, you know I don’t improvise. I over-prepare if anything. But, I reasoned, there’s only going to be a few of us, surely that’ll be fine, what’s the worse that could happen?
I’m glad you asked. I know precisely what the worse that could happen was, because it did happen. First, they were using a definition of a few I was previously unaware of. Quite a few was probably a better description - it was the largest meetup I’d ever attended. We even had people who didn’t know Scala and had no intention of learning it show up, a little randomly. Also, Zainab and Martin. Two people whose opinion matters to me, whom I respect and am vaguely terrified of. Also also, Martin. Came up with the whole concept of capture checking, has his name on all the papers on the subject, spear-heading its development, knows everything there is to know on the topic… all statements, you’ll notice, that emphatically do not apply to me. And yet I was going to be on stage, explaining it all to him. You understand how I maybe felt trapped, a little. Luckily, Martin, noticing my discomfort and ever the gentleman, said it’d be fine, we’d both go on stage, I’d write the code, and he’d criticise it, correct my mistakes, explain things and give context for some of the more… exotic… design decisions. Great! I was going to have to do two things I’m notoriously bad at, live coding and sharing the spotlight.
... continue reading