Any chance we could hear you talk about Lisp for a bit? I learned a lot from your thread-local comment: https://news.ycombinator.com/item?id=11240681

I was hoping you've stumbled on more ideas in the subsequent years. It's surprisingly hard to come up with simple + general.

Ever since you mentioned thread-locals, I've been seeing the pattern everywhere. Our current C++ codebase passes around a "Chip" object (basically, a global configuration holding the current settings for the compiler), and it's remarkable how many lines of code it ends up touching.

And it's not so easy to port your idea to C++ using thread_local. It turns out that Racket thread cells != thread_local storage. The key difference is that when you spawn a new thread, the new thread needs to inherit the current value -- thread_local doesn't automatically give that!

And storing the current "Chip" as a global doesn't quite work either. If we spin up two different compilation threads for two different chips, each thread needs to see its own Chip independently of the other. We sidestep that for now by explicitly passing a Chip to any new threads, but it's not a general solution like your idea was. The moment I realized that, I thought wistfully about your comment from 6 years ago, and I've wanted to bug you ever since for "more like that, please."