SumatraPDF is a Windows GUI application for viewing PDF, ePub and comic books written in C++. A common need in GUI programs is a callback. E.g. when a button is clicked we need to call a function with some data identifying which button was clicked. Callback is therefore a combo of function and data and we need to call the function with data as an argument. In programming language lingo, code + data combo is called a closure. C++ has std::function<> and lambdas (i.e. closures). Lambdas convert to std::function<> and capture local variables. Lambdas can be used as callbacks so problems solved? Not for me. I’ve used std::function<> and I’ve used lambdas and what pushed me away from them were crash reports. I’ve implemented crash reporting and it’s been very useful. The problem with lambdas is that they are implemented as compiler-generated functions. They get non-descriptive, auto-generated names. When I look at call stack of a crash I can’t map the auto-generated closure name to a function in my code. It makes it harder to read crash reports. Simplest solution that could possibly work You should know up front that my solution is worse than std::function<> in most ways. It’s not as nice to type as a lambda, it supports a small subset of std::function<> functionality. On the other hand it’s small, fast and I can understand it. One thing you need to know about me is that despite working on SumatraPDF C++ code base for 16 years, I don’t know 80% of C++. I get by thanks to sticking to a small subset that I do understand. I don’t claim I’ve invented this particular method. It seems obvious in retrospect but it did take me 16 years to arrive at it. Implementation of a simple callback in C++ A closure is code + data A closure is conceptually simple. It combines code (function) and data: using func0Ptr = void (*)(void*); struct Func0 { func0Ptr fn; void* data; void Call() { fn(data); } }; There are 2 big problems with this. First is annoying casting. You have to do: struct MyFuncData { }; void MyFunc(void* voidData) { MyFuncData* data = (MyFuncData*)voidData; } auto data = new MyFuncData; auto fn = Func0{(void*)data, MyFunc} Second is lack of type safety: struct MyFuncData {}; void MyOhterFunc(void* voidData) { MyOtherFuncData* data = (MyOtherFuncData*)voidData; } auto data = new MyFuncData; auto fn = Func0{ MyOtherFunc, (void*)data }; We will call MyOtherFunc with data of MyFunc. This will likely crash. The good thing is that pointer types are compatible. The machine instructions to call void Foo(void*) are exactly the same as calling void Foo(FooData*). We can solve the above annoyances with a bit of cleverness in the form of MkFunc0(): template <typename T> Func0 MkFunc0(void (*fn)(T*), T* d) { auto res = Func0{}; res.fn = (func0Ptr)fn; res.userData = (void*)d; return res; } void MyFunc(MyFuncData* data) { } auto data = new MyFuncData; auto fn = MkFunc0(MyFunc, data); We no longer need to cast data from void* in MyFunc. Trying to to create a mis-matched auto fn = MkFunc0(MyFunc, new MyOtherFuncData) will error out. The compiler will notice that fnand data arguments don’t match. We’ll make one improvement: ability to also create closure for functions without any arguments: void MyFuncNoData() { }; Func0 fn = MkFuncVoid(MyFuncNoData); The implementation cleverness: use a special, impossible value of a pointer (-1) to indicate a function without arguments. The full implementation is: using func0Ptr = void (*)(void*); using funcVoidPtr = void (*)(); #define kVoidFunc0 (void*)-1 // the simplest possible function that ties a function and a single argument to it // we get type safety and convenience with mkFunc() struct Func0 { void* fn = nullptr; void* userData = nullptr; Func0() = default; Func0(const Func0& that) { this->fn = that.fn; this->userData = that.userData; } ~Func0() = default; bool IsEmpty() const { return fn == nullptr; } void Call() const { if (!fn) { return; } if (userData == kVoidFunc0) { auto func = (funcVoidPtr)fn; func(); return; } auto func = (func0Ptr)fn; func(userData); } }; template <typename T> Func0 MkFunc0(void (*fn)(T*), T* d) { auto res = Func0{}; res.fn = (func0Ptr)fn; res.userData = (void*)d; return res; } Func0 MkFuncVoid(funcVoidPtr fn) { auto res = Func0{}; res.fn = (void*)fn; res.userData = kVoidFunc0; return res; } Closure with additional caller-provided argument Func0 only addresses a use case of packaging a function and its own data. Most of use cases for callbacks require passing additional arguments. For example a list view control has onItemSelected(int itemIndex) callback. For that we need Func1: template <typename T> struct Func1 { void (*fn)(void*, T) = nullptr; void* userData = nullptr; Func1() = default; ~Func1() = default; bool IsEmpty() const { return fn == nullptr; } void Call(T arg) const { if (fn) { fn(userData, arg); } } }; template <typename T1, typename T2> Func1<T2> MkFunc1(void (*fn)(T1*, T2), T1* d) { auto res = Func1<T2>{}; using fptr = void (*)(void*, T2); res.fn = (fptr)fn; res.userData = (void*)d; return res; } We can now do: struct OnListItemSelectedData { }; void OnListItemSelected(OnListItemChangedData* d, int selectedIdx) { } struct ListView { Func1<int> onListItemSelected; void listItemSelected(int idx) { onListItemSelected.Call(idx); } } auto lv = new ListView; auto data = new OnListItemSelectedData; lv.onListItemSelected = MkFunc1(OnListItemSelected, data) In Func0 the argument must be a pointer because the type is forgotten when we put it in a struct. We rely on the fact that void foo(void*) and void foo(Foo*) are compatible and we can cast the argument and function. But Func1 retains the type of second argument so it can be any type and the right call will happen. We also don’t want to erase the second type to avoid casts when calling it and to serve as documentation. We could write Func2for 2 arguments, Func3 for 3 arguments etc. but I didn’t bother. If I need more than one argument, I can always use struct to pack any number of arguments into a single one. Fringe benefits So is it worth it to use this over std::function<>? For me it does and I’ve refactored SumatraPDF to get rid of most of std::function<> uses in favor of Func0 and Func1. Yes, std::function<> is better in many ways. It’s more flexible. My solution only supports void Foo(), void Foo(T*) and void Foo(T1*, T2). std::function<> supports arbitrary number arguments of any type. Compared to writing a lambda with variable capture, I need to write more code: define a struct for closure data allocate and initialize struct construct Func0 or Func1 delete the data (typically at the end of closure) I decided writing this boilerplate doesn’t bother me. There are fringe benefits of my approach. On MSVC 64-bit std::function<> is 64 bytes. Func0 and Func1 are 16 bytes. Templated code is a highway to bloat. For every unique type, the compiler generates a new class definition on set of methods. Implementation of std::function<> is gigantic compared to Func1 and Func2. Templated code is also a highway to slow compilation. Again, std::function<> is at least order of magnitude more complicated so it’ll take order of magnitude longer to compile. Finally, I understand my implementation. I don’t understand std::function<> implementation. It’s scarier than Freddy Krueger. It’s scarier than Frankenstein’s monster. In fact, I don’t think anyone understands std::function<> including the 3 people who implemented it.

Over the past 19 months, I’ve written Crafting Engineering Strategy, a book on creating engineering strategy. I’ve also been working increasingly with large language models at work. Unsurprisingly, the intersection of those two ideas is a topic that I’ve been thinking about a lot. What, I’ve wondered, is the role of the author, particularly the long-form author, in a world where an increasingly large percentage of writing is intermediated by large language models? One framing I’ve heard somewhat frequently is the view that LLMs are first and foremost a great pillaging of authors’ work. It’s true. They are that. At some point there was a script to let you check which books had been loaded into Meta’s LLaMa, and every book I’d written at that point was included, none of them with my consent. However, I long ago made my peace with plagiarism online, and this strikes me as not particularly different, albeit conducted by larger players. The folks using this writing are going to keep using it beyond the constraints I’d prefer it to be used in, and I’m disinterested in investing my scarce mental energy chasing through digital or legal mazes. Instead, I’ve been thinking about how this transition might go right for authors. My favorite idea that I’ve come up with is the idea of written content as “datapacks” for thinking. Buy someone’s book / “datapack”, then upload it into your LLM, and you can immediately operate almost as if you knew the book’s content. Let’s start with an example. Imagine you want help onboarding as an executive, and you’ve bought a copy of The Engineering Executive’s Primer, you could create a project in Anthropic’s Claude, and upload the LLM-optimized book into your project. Here is what your Claude project might look like. Once you have it set up, you can ask it to help you create your onboarding plan. This guidance makes sense, largely pulled from Your first 90 days as CTO. As always, you can iterate on your initial prompt–including more details you want to include into the plan–along with follow ups to improve the formatting and so on. One interesting thing here, is that I don’t currently have a datapack for The Engineering Executive’s Primer! To solve that, I built one from all my blog posts marked with the “executive” tag. I did that using this script that packages Hugo blog posts, that I generated using this prompt with Claude 3.7 Sonnet. The output of that script gets passed into repomix via: repomix --include "`./scripts/tags.py content executive | paste -d, -s -`" The mess with paste is to turn the multiline output from tags.py into a comma-separated list that repomix knows how to use. This is a really neat pattern, and starts to get at where I see the long-term advantage of writers in the current environment: if you’re a writer and have access to your raw content, you can create a problem-specific datapack to discuss the problem. You can also give that datapack to someone else, or use it to answer their questions. For example, someone asked me a very detailed followup question about a recent blog post. It was a very long question, and I was on a weekend trip. I already had a Claude project setup with the contents of Crafting Engineering Strategy, so I just passed the question verbatim into that project, and sent the answer back to the person who asked it. (I did have to ask Claude to revise the answer once to focus more on what I thought the most important part of the answer was.) This, for what it’s worth, wasn’t a perfect answer, but it’s pretty good. If the question asker had the right datapack, they could have gotten it themselves, without needing me to decide to answer it. However, this post is less worried about the reader than it is about the author. What is our competitive advantage as authors in a future where people are not reading our work? Well, maybe they’re still buying our work in the form of datapacks and such, but it certainly seems likely that book sales, like blog traffic, will be impacted negatively. In trade, it’s now possible for machines to understand our thinking that we’ve recorded down into words over time. There’s a running joke in my executive learning circle that I’ve written a blog post on every topic that comes up, and that’s kind of true. That means that I am on the cusp of the opportunity to uniquely scale myself by connecting “intelligence on demand for a few cents” with the written details of my thinking built over the past two decades of being a writer who operates. The tools that exist today are not quite there yet, although a combination of selling datapacks like the one for Crafting Engineering Strategy and tools like Claude’s projects are a good start. There are many ways the exact details might come together, but I’m optimistic that writing will become more powerful rather than less in this new world, even if the particular formats change. (For what it’s worth, I don’t think human readers are going away either.) If you’re interested in the fully fleshed out version of this idea, starting here you can read the full AI Companion to Crafting Engineering Strategy. The datapack will be available via O’Reilly in the next few months. If you’re an existing O’Reilly author who’s skepical of this idea, don’t worry: I worked with them to sign a custom contract, this usage–as best I understood it, although I am not a lawyer and am not providing legal advice–is outside of the scope of the default contract I signed with my prior book, and presumably most others’ contracts as well.

Using conditional types to achieve type safety without having to use 'as'

No newsletter next week I’ll be speaking at Systems Distributed. My talk isn't close to done yet, which is why this newsletter is both late and short. Solving LinkedIn Queens in SMT The article Modern SAT solvers: fast, neat and underused claims that SAT solvers1 are "criminally underused by the industry". A while back on the newsletter I asked "why": how come they're so powerful and yet nobody uses them? Many experts responded saying the reason is that encoding SAT kinda sucked and they rather prefer using tools that compile to SAT. I was reminded of this when I read Ryan Berger's post on solving “LinkedIn Queens” as a SAT problem. A quick overview of Queens. You’re presented with an NxN grid divided into N regions, and have to place N queens so that there is exactly one queen in each row, column, and region. While queens can be on the same diagonal, they cannot be adjacently diagonal. (Important note: Linkedin “Queens” is a variation on the puzzle game Star Battle, which is the same except the number of stars you place in each row/column/region varies per puzzle, and is usually two. This is also why 'queens' don’t capture like chess queens.) Ryan solved this by writing Queens as a SAT problem, expressing properties like "there is exactly one queen in row 3" as a large number of boolean clauses. Go read his post, it's pretty cool. What leapt out to me was that he used CVC5, an SMT solver.2 SMT solvers are "higher-level" than SAT, capable of handling more data types than just boolean variables. It's a lot easier to solve the problem at the SMT level than at the SAT level. To show this, I whipped up a short demo of solving the same problem in Z3 (via the Python API). Full code here, which you can compare to Ryan's SAT solution here. I didn't do a whole lot of cleanup on it (again, time crunch!), but short explanation below. The code from z3 import * # type: ignore from itertools import combinations, chain, product solver = Solver() size = 9 # N Initial setup and modules. size is the number of rows/columns/regions in the board, which I'll call N below. # queens[n] = col of queen on row n # by construction, not on same row queens = IntVector('q', size) SAT represents the queen positions via N² booleans: q_00 means that a Queen is on row 0 and column 0, !q_05 means a queen isn't on row 0 col 5, etc. In SMT we can instead encode it as N integers: q_0 = 5 means that the queen on row 0 is positioned at column 5. This immediately enforces one class of constraints for us: we don't need any constraints saying "exactly one queen per row", because that's embedded in the definition of queens! (Incidentally, using 0-based indexing for the board was a mistake on my part, it makes correctly encoding the regions later really painful.) To actually make the variables [q_0, q_1, …], we use the Z3 affordance IntVector(str, n) for making n variables at once. solver.add([And(0 <= i, i < size) for i in queens]) # not on same column solver.add(Distinct(queens)) First we constrain all the integers to [0, N), then use the incredibly handy Distinct constraint to force all the integers to have different values. This guarantees at most one queen per column, which by the pigeonhole principle means there is exactly one queen per column. # not diagonally adjacent for i in range(size-1): q1, q2 = queens[i], queens[i+1] solver.add(Abs(q1 - q2) != 1) One of the rules is that queens can't be adjacent. We already know that they can't be horizontally or vertically adjacent via other constraints, which leaves the diagonals. We only need to add constraints that, for each queen, there is no queen in the lower-left or lower-right corner, aka q_3 != q_2 ± 1. We don't need to check the top corners because if q_1 is in the upper-left corner of q_2, then q_2 is in the lower-right corner of q_1! That covers everything except the "one queen per region" constraint. But the regions are the tricky part, which we should expect because we vary the difficulty of queens games by varying the regions. regions = { "purple": [(0, 0), (0, 1), (0, 2), (0, 3), (0, 4), (0, 5), (0, 6), (0, 7), (0, 8), (1, 0), (2, 0), (3, 0), (4, 0), (5, 0), (6, 0), (7, 0), (8, 0), (1, 1), (8, 1)], "red": [(1, 2), (2, 2), (2, 1), (3, 1), (4, 1), (5, 1), (6, 1), (6, 2), (7, 1), (7, 2), (8, 2), (8, 3),], # you get the picture } # Some checking code left out, see below The region has to be manually coded in, which is a huge pain. (In the link, some validation code follows. Since it breaks up explaining the model I put it in the next section.) for r in regions.values(): solver.add(Or( *[queens[row] == col for (row, col) in r] )) Finally we have the region constraint. The easiest way I found to say "there is exactly one queen in each region" is to say "there is a queen in region 1 and a queen in region 2 and a queen in region 3" etc." Then to say "there is a queen in region purple" I wrote "q_0 = 0 OR q_0 = 1 OR … OR q_1 = 0 etc." Why iterate over every position in the region instead of doing something like (0, q[0]) in r? I tried that but it's not an expression that Z3 supports. if solver.check() == sat: m = solver.model() print([(l, m[l]) for l in queens]) Finally, we solve and print the positions. Running this gives me: [(q__0, 0), (q__1, 5), (q__2, 8), (q__3, 2), (q__4, 7), (q__5, 4), (q__6, 1), (q__7, 3), (q__8, 6)] Which is the correct solution to the queens puzzle. I didn't benchmark the solution times, but I imagine it's considerably slower than a raw SAT solver. Glucose is really, really fast. But even so, solving the problem with SMT was a lot easier than solving it with SAT. That satisfies me as an explanation for why people prefer it to SAT. Sanity checks One bit I glossed over earlier was the sanity checking code. I knew for sure that I was going to make a mistake encoding the region, and the solver wasn't going to provide useful information abut what I did wrong. In cases like these, I like adding small tests and checks to catch mistakes early, because the solver certainly isn't going to catch them! all_squares = set(product(range(size), repeat=2)) def test_i_set_up_problem_right(): assert all_squares == set(chain.from_iterable(regions.values())) for r1, r2 in combinations(regions.values(), 2): assert not set(r1) & set(r2), set(r1) & set(r2) The first check was a quick test that I didn't leave any squares out, or accidentally put the same square in both regions. Converting the values into sets makes both checks a lot easier. Honestly I don't know why I didn't just use sets from the start, sets are great. def render_regions(): colormap = ["purple", "red", "brown", "white", "green", "yellow", "orange", "blue", "pink"] board = [[0 for _ in range(size)] for _ in range(size)] for (row, col) in all_squares: for color, region in regions.items(): if (row, col) in region: board[row][col] = colormap.index(color)+1 for row in board: print("".join(map(str, row))) render_regions() The second check is something that prints out the regions. It produces something like this: 111111111 112333999 122439999 124437799 124666779 124467799 122467899 122555889 112258899 I can compare this to the picture of the board to make sure I got it right. I guess a more advanced solution would be to print emoji squares like 🟥 instead. Neither check is quality code but it's throwaway and it gets the job done so eh. "Boolean SATisfiability Solver", aka a solver that can find assignments that make complex boolean expressions true. I write a bit more about them here. ↩ "Satisfiability Modulo Theories" ↩

Go 1.23 adds iterators. An iterator is a way to provide values that can be used in for x := range iter loops. People are happy the iterators were added to the language. Not everyone is happy about HOW they were implemented. This person opined that they demonstrate “typical Go fashion of quite ugly syntax”. The ugly Are Go iterators ugly? Here’s the boilerplate of an iterator: func IterNumbers(n int) func(func(int) bool) { return func(yield func(int) bool) { // ... the code } } Ok, that is kind of ugly. I can’t imagine typing it from memory. The competition We do not live in a vacuum. How do other languages implement iterators? C++ I recently implemented DirIter class with an iterator in C++, for SumatraPDF. I did it to so that I can write code like for (DirEntry* e : DirIter("c:\")) { ... } to read list of files in directory c:\. Implementing it was no fun. I had to implement a class with the following methods: begin() end() DirEntry* operator*() operator==() operator!=() operator++() operator++(int) Oh my, that’s a lot of methods to implement. A bigger problem is that the logic is complicated. This is an example of pull iterator where the caller “pulls” next value out of the iterator. The caller needs at least two operations from an iterator: give me next value do you have more values? In C++ it’s more complicated than that because “Overcomplication” is C++’s middle name. A function that reads a list of entries in a directory is relatively simple. The difficulty of implementing pull iterator comes from the need to track the current state of iteration to be able to provide “give me next value” function. A simple directory traversal turned into complicated tracking of what I have read so far, did the process finish and reading the next directory entry. C C# also has pull iterators but they removed incidental complexity present in C++. It reduced the interface to just 2 essential methods: T Next() which returns next element bool HasMore() which tells if there are more values to read Here’s an iterator that returns integers from 1 to n: class NumberIterator { private int _current; private int _end; public NumberIterator(int n) { _current = 0; _end = n; } public bool HasMore() { return _current < _end; } public int Next() { if (!HasMore()) { throw new InvalidOperationException("No more elements."); } return ++_current; } } Much better but still doesn’t solve the big problem: the logic is split across many calls to Next()so the code needs to track the state. C# push iterator with yield Later C# improved this by adding a way to implement push iterator. An iterator is just a function that “pushes” values to the caller using a yield statement. Push iterator is much simpler: static IEnumerable<int> GetNumbers(int n) { for (int i = 1; i <= n; i++) { yield return i; } } Clever and elegant Here’s a Go version: func GetNumbers(n int) func(func(int) bool) { return func(yield func(int) bool) { for i := i; i <= n; i++ { if !yield(i) { return } } } } The clever and elegant part is that Go designers figured out how to implement push iterators in a way very similar to C#’s yield without adding new keyword. The hard part, the logic of the iterator, is equally simple as with yield. The yield statement in C# is kind of magic. What actually happens is that the compiler rewrites the code inside-out and turns linear logic into a state machine. Go designers figured out how to implement it using just a function. It is true that there remains essential complexity: iterator is a function that returns a function that takes a function as an argument. That is a mind bend, but it can be analyzed. Instead of yield statement pushing values to the loop driver, we have a function. This function is synthesized by the compiler and provided to the iterator function. The argument to that function is the value we’re pushing to the loop. It returns a bool to indicate early exit. This is needed to implement early break out of for loop. An iterator function returns an iterator object. In Go case, the iterator object is a new function. This creates a closure. If function is an iterator object then local variables of the function are state of the iterator. I don’t know why Go designers chose this design over yield. I assume the implementation is simpler so maybe that was the reason. Or maybe they didn’t want to add new keyword and potentially break existing code.