Brent A. Yorgey 2026 8 22 http://ozark.hendrix.edu/~yorgey/forest/2026-W33/ 2026-W33 /~yorgey/forest/2026-W33/ Weeknotes for 21 August 2026 (week 33) Brent A. Yorgey 2026 8 22 Swarm This week was the 5-year anniversary of my first commit to the Swarm repo—back in August of 2021, at the start of my sabbatical. It's been a wonderful, wild ride. The project has gone much farther than I could have imagined, and been more professionally fruitful than I would have thought possible! And a big part of the reason it's remained fun for so long is the cool community of other contributors the project has attracted. There's been a flurry of activity this week from several other contributors, so I've spent a decent bit of time reviewing PRs. Among other cool things, there have been some fantastic improvements to memory usage and performance. I've also continued working on an integrated help system this week. It's coming along nicely. One of the few things still missing is the ability to specify a table of contents for a given page, from which we can automatically display next/previous/up links. I basically plan to steal the way Sphinx does this with the toctree directive. Brent A. Yorgey 2026 8 22 First-year student advising I spent a substantial amount of time this week meeting with my cohort of 14 first-year student advisees—first as a group, and then individually. In past years, they have come to campus with blank slates and we would spend the first week frantically building their schedules, resolving conflicts, finding alternate classes when the class they wanted is too full, and so on. It didn't leave much time for anything besides putting out fires. Starting last year, we have a new system in place where they meet with someone virtually over the summer to put together an initial course schedule. By the time they arrive on campus they already have a mostly-solid schedule, and I just have to help fill it out with an extra class or two. It is much more civilized and leaves plenty of time for chatting and getting to know them and what they are interested in. Talking to people all day is a lot, but aside from that it was quite enjoyable; they all seem like lovely human beings with a wide variety of interests. Brent A. Yorgey 2026 8 22 Semester prep The fall semester is almost upon us. When I haven't been doing advising stuff I have been working hard on preparing for my fall courses. I'll be co-teaching our introductory programming course with my colleague, and we don't plan to change much about the course, which by this point is a well-oiled machine. On the other hand, I am making a few more changes to Algorithms this semester. In order to reduce incentives for LLM use, I'm adding an extra midterm exam and having some required office hour visits. But the extra exam makes it more awkward to fit in weekly problem sets at reasonable times, which suddenly made me wonder today whether I could do something more flexible, like assigning individual problems every day and having them choose a portfolio of problems to solve. I still need to work out a lot of details. Brent A. Yorgey 2026 8 22 Hanabi I have continued to enjoy Hanabi a lot—playing sometimes with my 14yo and sometimes with strangers on Hanab Live. I think I enjoy it for many of the same reasons that I enjoy bridge—it is collaborative rather than competitive (I'm super competitive and it's easy for me to get stressed out about winning and losing), and involves teamwork, communication, and logical deduction. I'm always happy to teach others, so if you're intrigued and would like to learn how to play, let me know! References Context Brent A. Yorgey 2026 2 13 http://ozark.hendrix.edu/~yorgey/forest/005U/ 005U /~yorgey/forest/005U/ Brent Yorgey › Weeknotes This page has an atom feed. Brent A. Yorgey 2026 2 13 http://ozark.hendrix.edu/~yorgey/forest/2026-W06/ 2026-W06 /~yorgey/forest/2026-W06/ Weeknotes for 13 February 2026 (week 6) Inspired by Jon Sterling and Liam O'Connor, this is my first attempt at writing weeknotes. It seems like it could be a useful practice, but one that I won't be able to evaluate without trying it. Brent A. Yorgey 2026 2 14 http://ozark.hendrix.edu/~yorgey/forest/005V/ 005V /~yorgey/forest/005V/ Thoughts on pedagogy and community-building This semester I am participating in a "teaching square" with several colleagues, where we visit and observe each other's classes—not for the purpose of evaluation, or even constructive criticism, but merely to observe and reflect on our own teaching. On Monday I visited a class taught by one of my colleagues (who shall remain anonymous for now since I don't know whether she would want to be identified publicly in this context). I very much enjoyed watching the way my colleague got the students to engage actively with her and with each other. It seemed like the students in the class all knew each others' names, which in my experience is rare, even in a small class. I don't think this was a coincidence—it was something my colleague intentionally cultivated. This week I also read Shriram Krishnamurthi's pedagogy recommendations, and among other good advice, he also says several things about creating community within the classroom (such as getting students to introduce themselves to each other repeatedly). I'm still thinking about what, if anything, I might concretely do differently in my classes, but it's been good to think about. Brent A. Yorgey 2026 2 14 http://ozark.hendrix.edu/~yorgey/forest/005W/ 005W /~yorgey/forest/005W/ Forester setup for Discrete Math lecture notes I spent a bunch of time this week writing Discrete Math lecture notes in Forester, and tweaking my Forester setup to make the process more efficient and the results prettier. I used Pandoc to write a janky script that takes my existing LaTeX lecture notes and makes a first pass at converting them into Forester syntax. There's still lots more features I could add, and it's nowhere near being a complete, general-purpose pandoc writer (I'm not sure it will ever be), but it already saves me time. After asking for advice on the forester-discuss mailing list and getting a helpful response, I created some simple Forester macros for typesetting calculational proofs, like so: 7]]> { add to both sides } 8]]> { divide both sides by } 4]]> When teaching my Discrete Math students to write proofs, I emphasize the way the proofs should be structured, i.e. nested. I have not yet gone so far as teaching them via a proof assistant like Lean or Agda—I'm not sure I ever will—but I get as close as possible while still writing proofs on paper. I spent a bit of time tweaking some CSS to be able to easily typeset things like this: Brent A. Yorgey2026214Proof Let be an arbitrary integer; then we must show . Brent A. Yorgey2026214Subproof Suppose , that is, there exists an integer such that . Then we must show that is also odd. Brent A. Yorgey2026214Subproof , so is odd since it is one more than twice an integer. Since we showed is odd under the supposition that is odd, we have proved the implication . Since was an arbitrary integer, we have proved . This works by creating a new taxon called "Subproof" and using CSS to hide the header and draw a bar on the side. I'm not sure if there's a better way to accomplish this, but it works pretty well for now. Brent A. Yorgey 2026 2 14 http://ozark.hendrix.edu/~yorgey/forest/005X/ 005X /~yorgey/forest/005X/ Classical vs constructive logic in Discrete Math Aside from such technical fiddling, I've also spent a good deal of time over the past few weeks rethinking my approach to teaching logic and proofs in my Discrete Math course, inspired by Emily Riehl's approach and by a rant by Mark Jason Dominus about teaching constructive logic. Of course I love constructive logic; but I have come to the conclusion that, in my context at least, I think there are still good reasons for teaching classical logic (and teaching it first). So I didn't end up making the radical changes I thought I might; but it was still a very useful exercise, as I did end up reorganizing things in some significant ways. At some point I will write up a more detailed explanation of how I have decided to teach the course, and why. Brent A. Yorgey 2026 2 13 Curling On a completely different note, I watched a lot of curling this week. It looks like a lot of fun; I wish I could try it! Brent A. Yorgey 2026 2 21 http://ozark.hendrix.edu/~yorgey/forest/2026-W07/ 2026-W07 /~yorgey/forest/2026-W07/ Weeknotes for 20 February 2026 (week 7) Spent a bunch of time this week grading, dealing with administrative stuff, and writing more lecture notes. Besides those I did a couple other things of interest: Brent A. Yorgey 2026 2 21 http://ozark.hendrix.edu/~yorgey/forest/0075/ 0075 /~yorgey/forest/0075/ Swarm hacking I spent a while finishing up this pull request for Swarm. Right now, Swarm feels like it's kind of in this big slog/plateau where we've added all the "easy" features, and now in order to reach the ultimate vision there are a bunch of really hard, big projects/refactorings/redesigns that need to happen. Stuff that's not sexy and that players will never notice. Fortunately, although I certainly enjoy adding exciting features, I also really enjoy the craft of writing and refactoring code, of thinking hard about problems and coming up with elegant schemes for solving them. I don't get to do a whole lot of that otherwise, so I'm really glad to have this somewhat-frivolous-but-surprisingly-professionally-fruitful project to work on. Brent A. Yorgey 2026 2 21 http://ozark.hendrix.edu/~yorgey/forest/0074/ 0074 /~yorgey/forest/0074/ The Farmer Was Replaced I started playing The Farmer Was Replaced—someone recommended it because of its similarities to Swarm. There definitely are some similarities: in both games, you program robots to move around in a grid world collecting resources to unlock new programming language features. (There are also some big differences, of course, such as the fact that Swarm has a much cooler programming language.) The game feels like it is trying to be a fun way for people to learn programming. But having taught literally hundreds of beginners how to program, I can tell you unequivocally that no one is going to be learning how to program from this game if they don't already have some other prior programming experience. Still, it's a pretty fun game, and very polished; the implementation of the in-game Python-esque language is very impressive. I haven't finished the game yet, still need to solve some mazes and implement a better snake-playing robot... Brent A. Yorgey 2026 2 27 http://ozark.hendrix.edu/~yorgey/forest/2026-W08/ 2026-W08 /~yorgey/forest/2026-W08/ Weeknotes for 27 February 2026 (week 8) Brent A. Yorgey 2026 2 28 http://ozark.hendrix.edu/~yorgey/forest/0087/ 0087 /~yorgey/forest/0087/ Material set theory, universal sets, and pedagogy In my Discrete Mathematics course I am currently teaching (traditional, material) set theory. I've recently noticed several instances where we really "want" to have a universe of discourse, i.e. a global set of which which other sets under consideration are subsets. Of course the notion of set complement doesn't make sense without a universe of discourse; complement with respect to what? I typically introduce set equality by defining to mean . But sometimes we would really like to treat set equality extensionally, i.e. But what is the quantifying over? For this to make sense, we must posit that we are quantifying over some kind of universe. As for the subset relation itself, I typically define as , but perhaps it is nicer to define it as If we define it that way, the extensional and subset-both-ways definitions of set equality are simply related by the fact that distributes over : { Definition of } { distributes over } { Definition of } But saying "there always has to be a universal set " is kind of equivalent to saying that we want our sets to be typed: you can't just have "a set", you have to say what universe the elements are going to be chosen from, i.e. the type of the elements. What I would really like to do is start with some basic type theory, then later introduce sets as , and build up from there. But that would be a big change. It's too late for this semester, but maybe next year... 2026 2 28 http://ozark.hendrix.edu/~yorgey/forest/0088/ 0088 /~yorgey/forest/0088/ Re-reading The Goblin Emperor This week I've re-read Katherine Addison's The Goblin Emperor for the third time. It's not the kind of thing I usually read; I usually can't stand a lot of politics (for example, I found Kim Stanley Robinson's Mars trilogy tiresome at times). But there is something so wholesome and inspiring about a character who has a lot of power but works very hard to Do The Right Thing in the midst of a system rife with corruption and greed. The week before, I read the third book in the spin-off Chronicles of Osreth trilogy, The Tomb of Dragons. I enjoy them for similar reasons to The Goblin Emperor, and I also enjoy the more mystery/detective slant. I thought I had already read the first two books in the series, but it turns out that I only read the first—oops! There were multiple references in the third book to things I didn't remember, which I initially chalked up to having read the second book too long ago, but it turns out it was because I actually haven't read it at all. So I decided I will go back and re-read the first book (Witness for the Dead) before reading the second, but then I figured I might as well go all the way back and re-read The Goblin Emperor first. Brent A. Yorgey 2026 3 6 http://ozark.hendrix.edu/~yorgey/forest/2026-W09/ 2026-W09 /~yorgey/forest/2026-W09/ Weeknotes for 6 March 2026 (week 9) Brent A. Yorgey 2026 3 14 http://ozark.hendrix.edu/~yorgey/forest/00BN/ 00BN /~yorgey/forest/00BN/ Swarm module export Earlier this week I was hacking on Swarm, adding an export construct that allows you to re-export either individual names or entire modules from a given module. I thought this was going to be easy, but I couldn't figure out how to make it work. I finally realized that I had been Doing It Wrong™: after typechecking, I was doing a second pass over the type-annotated syntax tree for a module to collect up the names and types of things that should be exported. But with export in the mix, there was no longer enough information to figure this out just by looking at the syntax (even when fully type-annotated). The correct (and obvious in retrospect) thing to do is to instead collect up exported names and their types during typechecking. Brent A. Yorgey 2026 3 14 http://ozark.hendrix.edu/~yorgey/forest/00BM/ 00BM /~yorgey/forest/00BM/ Theorems with both constructive and non-constructive proofs I've been working on writing up some advanced, optional notes for my Discrete Mathematics students (mostly second-year undergraduates) on classical vs constructive logic, and I wanted a good example of a theorem with both non-constructive and constructive proofs. A typical example of a non-constructive proof is of the infinitude of primes: for any natural number , we consider the number : either it is prime, or it is divisible by one which must be larger than , since is clearly not divisible by anything . This is supposedly nonconstructive since it uses LEM to conclude that is either prime or not, but this is totally unsatisfactory to me. Since primality is decidable, this instance of LEM is actually constructively provable, and the whole proof immediately becomes an algorithm for computing a prime larger than any . (Another typical "example" is the so-called proof by contradiction that is irrational; but of course, it is not a proof by contradiction at all.) I asked for examples on Mastodon, which led to a very interesting discussion. Henrý Ólson suggested the theorem "there exist irrational and such that is rational". The nonconstructive proof uses LEM: is either rational or not; if so, it satisfies the theorem, and if not, does. Constructively, we can show that is irrational and that . This is covered by Andrej Bauer in Five Stages of Accepting Constructive Mathematics, but I had forgotten it. It's a pretty good example to show to undergraduates, since the proof with LEM is very clearly nonconstructive, and the whole thing (including proofs of irrationality for and ) requires only some basic number theory. I came up with the theorem "For every natural , there exists n]]> which is not square". Both the nonconstructive and constructive proofs depend on the (constructively proved) lemma that if is square then is not. The nonconstructive proof proceeds by contradiction: suppose every n]]> is square. Then in particular and are square, but the lemma immediately yields a contradiction. The constructive proof considers , which is immediately seen to be non-square by the lemma. Jim Kingdon protested, not unreasonably, that the nonconstructive proof has a similar problem as the proof of infinitude of primes. Since the property of being square is decidable, one can turn the nonconstructive proof into a constructive one fairly easily: just decide whether is a square; if not, we have our non-square, and if so, the lemma tells us must be non-square. This is true, but I still like this example a bit better than the infinitude of primes: that one directly uses an instance of LEM which is constructively provable, whereas this one uses a proof by contradiction. Jim Kingdon also gave another example, Bézout's identity. This seems like a nice example, and one that is accessible to undergraduates, but I'm still confused about it! The constructive proof is via the Extended Euclidean Algorithm. The typical non-constructive proof considers the set 0\}]]> and notes that it must have a smallest element by the well-ordering property, then proceeds to prove that this smallest positive element is in fact the GCD of and . Intuitively, this seems clearly non-constructive, since it does not actually help you compute the smallest element of the set. But I am still a bit confused about where exactly a classical axiom ends up getting used. The version of the well-ordering principle which says that every set has a well-order implies the Axiom of Choice; but we surely don't need such a big hammer here. We are simply using the version that applies to subsets of natural numbers, which is constructively provable (in fact, it is logically equivalent to induction). The answer seems to be that the constructive well-ordering principle for the natural numbers requires membership of the set to be decidable, and deciding whether there exist integers and such that for a particular is nontrivial. If you just throw LEM at it, you get the nonconstructive proof. Or if you work harder, you can actually decide this via the Extended Euclidean Algorithm. Brent A. Yorgey 2026 3 13 http://ozark.hendrix.edu/~yorgey/forest/2026-W10/ 2026-W10 /~yorgey/forest/2026-W10/ Weeknotes for 13 March 2026 (week 10) Brent A. Yorgey 2026 3 13 AI vegetarian I've been thinking for a while about publishing an official statement regarding my stance on LLMs (and other generative AI systems), but it always felt too daunting to express what I wanted to express. But I recently found several things other people had written that captured my position pretty well, so I finally published a statement. I still want to write something for my students in particular, but I'm still thinking about that. Brent A. Yorgey 2026 3 13 Blog post series on constructive logic Following last week's discussion on Theorems with both constructive and non-constructive proofs, I realized that there is something of a gap in the pedagogical materials available on constructive logic, and the difference between classical and constructive logic. There are many hand-wavy, intuitive explanations of constructive vs non-constructive proofs in, say, slide decks used for teaching undergraduate Discrete Math courses. There is also lots of advanced material, such as Andrej Bauer's paper Five Stages of Accepting Constructive Mathematics, the HoTT book, and others. However, there does not seem to be much intermediate-level material. So I plan to write a series of blog posts aimed at people who are familiar with typed functional programming, and perhaps have even heard of the Curry-Howard correspondence, and perhaps have even played with a theorem prover such as Agda or Lean, but who don't know the actual formal details of classical vs constructive logic. Earlier this week I started drafting some ideas on paper; I hope this week or next to find some time to start writing it up more formally. Brent A. Yorgey 2026 3 28 http://ozark.hendrix.edu/~yorgey/forest/00CG/ 00CG /~yorgey/forest/00CG/ Disco: exhaustiveness checking for arithmetic patterns A couple summers ago, my student Colin Phillips implemented exhaustiveness checking for Disco, following Lower your guards: a compositional pattern-match coverage checker by Graf, Peyton Jones, and Scott. So it can now do things like f : Unit + (Bool * Nat) -> Int Disco> f(right(False, n)) = 3 Warning: the function f is undefined for some inputs. For example: f(left(■)) = ... f(right(true, 0)) = ... f(right(true, 1)) = ...]]> However, Disco also has arithmetic patterns, like N f(2n) = n + 1 f(2n+1) = 3]]> but doing coverage checking for these is tricky in general. Quick, for what values (if any) is the below (partial) function undefined? N f(3n) = 0 f(1+5n) = 1 f(2n+2) = 2 f(n+12) = 3]]> My student Katherine Reid was working on a library for solving this problem, via the theory of semilinear sets, but we never quite finished incorporating it into the Disco coverage checker. Since I'm using Disco to teach again this semester, I've started working on this again. This week, I mostly just spent some time understanding the existing code and writing down a list of the reamining tasks. I'm optimistic I can get it polished up and merged before the end of the semester. (Answer: the function is undefined for and .) Brent A. Yorgey 2026 3 13 Swarm export and arrays Finally, over in Swarm land, I've continued polishing up Swarm module export. I've also started working on adding an immutable array type to the language—not difficult, but enjoyable. Brent A. Yorgey 2026 3 20 http://ozark.hendrix.edu/~yorgey/forest/2026-W11/ 2026-W11 /~yorgey/forest/2026-W11/ Weeknotes for 20 March 2026 (week 11) Really didn't have time to do much of anything this week besides grading, course prep, meeting with students in office hours, and administrative tasks as the chair of my department. The only interesting things I did were to work a bit more on immutable arrays in Swarm, and record an interview for the Haskell Interlude with Sam Frohlich and Farhad Mehta, which was fun. Brent A. Yorgey 2026 3 27 http://ozark.hendrix.edu/~yorgey/forest/2026-W12/ 2026-W12 /~yorgey/forest/2026-W12/ Weeknotes for 27 March 2026 (week 12) Weeknotes, Spring Break edition! (For non-US readers: Spring Break is (typically) one week off from classes, approximately in the middle of the spring semester.) This has been a relaxing and productive week with no classes to teach. Brent A. Yorgey 2026 3 27 Immutable arrays in Swarm Brent A. Yorgey 2026 3 27 Challenge scenarios requring arrays Continuing my work on immutable arrays in Swarm, this week I was playing around with creating some challenge scenarios that require the use of arrays. This is actually somewhat tricky, since you can always simulate arrays with functions—it's just less efficient. So the general idea is to construct scenarios with a time limit, where you need the efficiency of an array to be able to get a solution that is fast enough. But even this is tricky! My first attempt just involved a row of randomly generated capital letters that you are supposed to sort alphabetically. I thought you could read them all into an array and pick them up at the same time, sort the array, then lay them out in sorted order. However, I realized that you can just pick them all up, then iterate through the capital letters one at a time in order, and place any that you happen to have of each. I constructed another scenario that I thought would work: there is a "key" row of randomly permuted capital letters, and another row of randomly generated capital letters. You must sort the second row, but in the order specified by the permutation in the first row. However, I realized there's a clever way to accomplish this in time without using an array: (1) pick up all the items to be sorted; (2) scan through the key permutation, going one recursive call deeper with each item, so the recursion stack ends up storing the entire sequence; (3) unwind the recursion stack while walking along the destination row in reverse; for each item of the permutation, place all the copies of it you have in your inventory. Having written this, I think I should go back to my original idea, but use randomly generated strings instead of individual capital letters. That way, the range of possible values is huge, so there's no way to simply iterate through them in order and place any that you happen to have. (Currently, there's no way to iterate through items in your inventory...) Brent A. Yorgey 2026 3 27 Minimal API for immutable arrays It's also been interesting to think about a good minimal API for immutable arrays. Elimination forms are easy: we just need index : Array a -> Int -> a and size : Array a -> Int. But what about introduction forms? At this point I've implemented unfold : b -> (b -> Unit + (a * b)) -> Array a (as well as an effectful variant), but I'm starting to think that's not good enough: it assumes that you can generate the array elements in order, all at once. Instead, I think we really want something like: (a -> a -> a) -> b -> (b -> Unit + (Int * a * b)) -> Array a]]> which unfolds (index, value) pairs starting from a seed value, starting with the default value and using the combining function for multiple values at the same index. In Haskell you would write this as Monoid a => [(Int, a)] -> Array a but Swarm has no type classes and we don't want arrays to depend on lists, so we encode the monoid constraint via the first two arguments, and encode the list via an unfold. Is there a simpler way to do this? Brent A. Yorgey 2026 3 27 Applicative inference I had a nice meeting with Andrey Mokhov to see if we might collaborate on my Applicative inference research project. Not sure yet where it will go, but neither of us is under any particular pressure to publish, so I'm content to just let it play out at whatever pace makes sense. Brent A. Yorgey 2026 3 27 Exhaustiveness checking for arithmetic patterns in Disco I continued working on this project from a couple weeks ago. I made some progress with typechecking and desugaring of arithmetic patterns. All that's left is to actually plug them into the exhaustiveness checker itself, and make it call out to the semilinear set solver appropriately... but after staring at it for a while, I realized I have no idea how the exhaustiveness checker works! I suspect some refactoring will be needed, since there doesn't seem to be an obvious place to just stick in some extra code for arithmetic patterns. Thankfully, the student who wrote it is still around; I hope we can meet about it soon and figure it out together. Brent A. Yorgey 2026 3 27 Kattis I had fun this week solving a few Kattis problems in Haskell. One particularly interesting problem was Metro Lines: there is a line of stops numbered to , and we are given a bunch (up to ) of subway lines, each of which has a cost and visits all the stops between and inclusive. You can get on and off of any line anywhere you want; it costs to ride from to , where is the cost of the line. We're supposed to print out the cheapest fare to get from station to each station from through . Try solving it yourself, or click to expand my solution sketch below! Brent A. Yorgey Brent A. Yorgey 2026 3 27 2026 3 28 Solution sketch for Metro Lines (spoiler) The solution is to sort all the line endpoints, then scan through from left to right, keeping track of a set of active lines, sorted by cost (I just used a Set of pairs). For each segment , we then know the cost of the cheapest line which operates on that segment. The key insight is that since we can get on and off whenever we want, we can independently choose the cheapest line for each one-unit segment; since the cost is linear in the length of the ride, we can just independently add up the cost of each one-unit segment to get the total cost. Brent A. Yorgey 2026 4 4 http://ozark.hendrix.edu/~yorgey/forest/2026-W13/ 2026-W13 /~yorgey/forest/2026-W13/ Weeknotes for 3 April 2026 (week 13) Brent A. Yorgey 2026 5 3 http://ozark.hendrix.edu/~yorgey/forest/00GM/ 00GM /~yorgey/forest/00GM/ Introduction forms for immutable arrays After mentioning it in last week's weeknotes, I got some great feedback from Verity on an introduction form for immutable arrays. (Again, the biggest constraint here is that we don't want to use lists: Swarm does have lists, but not built-in in a primitive way. Using lists requires you to first unlock algebraic data types as well as recursive types, and you should be able to unlock and use arrays independently.) After a bit of back and forth, the current best idea is a) -> b -> (b -> Unit + Int * (a -> (a * b))) -> Array a]]> The first argument specifies the starting value at any index. The second argument is a seed value for the unfold. I like to think of the third argument as a protocol for communication between the array constructor and the user, specifying the process for a sort of imperative unfold. The array constructor begins by announcing the current seed value of type b. The user gets to choose whether to stop, or to continue by specifying an index. The array constructor provides the value of type a currently at that index. The user then gets to provide a new value of type a, and a new seed. This is trickier to implement than what I had before (e.g. it requires several new types of CESK machine continuation frames instead of just one, and in practice, we want to wait until we see which indices are requested before deciding on the final size of the array and filling in any missing values), but ultimately should be fine. I need to finish up the implementation and play around with it: implement some other simpler introduction forms in terms of it, and try using it for things that were inefficient before. Brent A. Yorgey 2026 4 4 Draft blog post on zero/empty set/void type/monoids etc. Inspired by a conversation on Mastodon, I've started drafting a blog post on the connections between things like with an empty domain, functions out of empty types, sum/product/and/or of an empty list, etc.. None of this will be at all surprising to experienced Haskell programmers or type theorists, but I hope it may be interesting for some who are just learning. As these things always happen, when I started expanding my outline into prose, I found that the very first bullet point in the outline expanded into enough material for an entire blog post. So it may just be very long, or I may split it up into multiple posts... we'll see! Brent A. Yorgey 2026 4 4 Teaching induction I had a lot of fun this week teaching my Discrete Math students about induction principles for natural numbers. On Wednesday I went over a strong induction principle. When I teach them, I usually state it like I find a formulation without an explicit base case more elegant, but I don't think I am brave enough to teach it this way: I think they would be completely confused by the apparent lack of a base case. Of course, the base case is still there, in the sense that you have to at the very least prove with no assumptions, since is trivial. But you would essentially have to almost always start by doing a case split on whether is 0 anyway, so I feel like I might as well present it in a form with already split out separately. But I would be interested to hear about how others teach this. Of course, in some sense it doesn't matter since the two principles are logically equivalent, but I think it matters in a pedagogical sense. As the crowning example, I proved that every natural number can be written as a sum of distinct powers of two... and then showed them that our induction proof is actually a recursive program for calculating the binary expansion of any natural number, by coding it in Disco: Set(N) binary(0) = {} binary(2k) = {e+1 | e in binary(k)} binary(2k+1) = {0} union {e+1 | e in binary(k)}]]> I definitely enjoyed seeing several of them get head-exploding expressions on their faces when they realized the correspondence between invoking the induction hypothesis and making a recursive function call. Brent A. Yorgey 2026 4 4 A polynomial testing principle I've had Conor McBride's paper A polynomial testing principle on my reading list for a while, and this week I finally got around to reading through it carefully, typing up all the Agda code myself and trying to fill in as much of it as I could before peeking. I now have some much better ideas about how to encode things nicely in Agda. The topic of the paper was also really fun: I was definitely familiar with the idea that two degree- polynomials must be equal if they agree at points, but I would not have guessed that this can be proved in a few hundred lines of Agda. I also enjoyed how it hinged on the forward difference and summation operators, old friends of mine from reading Concrete Mathematics when I was in undergrad. Brent A. Yorgey 2026 4 4 Piano corner For the past few weeks I have been working on Chopin's 1st piano concerto. This is not the first time I've worked on it, but I haven't in a while. I have long dreamed of performing it someday. I always figured this was essentially a pipe dream, but after recently seeing a video of Olga Scheps playing it with a small chamber orchestra, I have a bit more hope that it might be possible! I didn't even realize there was an arrangement for chamber orchestra. Of course there are arrangements for two pianos as well, though that idea doesn't excite me as much. Brent A. Yorgey 2026 4 12 http://ozark.hendrix.edu/~yorgey/forest/2026-W14/ 2026-W14 /~yorgey/forest/2026-W14/ Weeknotes for 10 April 2026 (week 14) Not much to report this week... came down with a nasty cold Monday night and have spent the rest of the week doing not much beyond the bare minimum. Brent A. Yorgey 2026 4 12 Equivalence relations which are the kernel of a (nice) function I did continue to teach my classes (while masked up) and had a nice epiphany while teaching about modular equivalence: I used to present separate detailed proofs showing that the modular equivalence relation is reflexive, symmetric, and transitive... but I realized that we can first prove the alternative characterization , and then it automatically inherits all the properties of an equivalence relation from equality! Any time we have a relation such that for some function , the relation is automatically an equivalence, and if the equality is decidable we also get a nice way to decide our relation. This situation comes up all the time in computing (convert strings to lowercase in order to decide case-insensitive equality; sort lists in order to compare up to permutation; and so on). I posted about this on Mastodon, which led to a nice discussion. It turns out that given a function , the equivalence relation on induced by (putting each fiber in its own equivalence class) is called the kernel of . Previously, I only knew that term in the sense of the set of elements sent to zero by a group or ring homomorphism, but I guess it's related: in the case of a group or ring homomorphism, there's enough structure to allow us to recover the entire kernel relation on the domain from just the set of elements related to zero, so we might as well use the same term "kernel" for both. Brent A. Yorgey 2026 4 18 http://ozark.hendrix.edu/~yorgey/forest/2026-W15/ 2026-W15 /~yorgey/forest/2026-W15/ Weeknotes for 17 April 2026 (week 15) http://ozark.hendrix.edu/~yorgey/forest/00FY/ 00FY /~yorgey/forest/00FY/ Agda proof of the Fundamental Theorem of Arithmetic On Monday, I was idly brainstorming potential final projects for my Functional Programming students. Having just taught my Discrete Math students the Fundamental Theorem of Arithmetic, I wondered whether formalizing it in Agda could make a nice project. (I mean formalizing it from scratch: of course, the FTA must already in the Agda standard library.) Then I... kind of fell down the rabbit hole. Several hours and 560 lines of Agda later, I'm very close: all I have left is to prove that the result of the division algorithm is unique (which is actually kinda tricky). Well... actually, I've only formalized half of the FTA so far, namely, the part that says any number can be factored into a product of primes. I haven't yet attempted to formalize the claim that the resulting factorization is unique up to permutation. We'll see if I decide to add that. In any case, this has been a fun and pleasant exercise, requiring a bunch of facts about addition, multiplication, and inequality; well-founded induction; encoding loops from a start value up to an end value; and various other things. I've been doing everything completely from scratch/memory, without peeking at any Agda stdlib code. Once I finish it I might clean it up and turn it into a blog post. Formalizing the proof has led me to rethink a few of the wys I present things in Discrete Math. For example, I had been defining a number to be prime if "all divisors of are trivial", that is, formally, But now I actually think it is better to define it as " has no nontrivial divisors", that is, Since primality is decidable, these are constructively equivalent, but... I like the second definition better now, for reasons I can't quite put my finger on. Brent A. Yorgey 2026 4 25 http://ozark.hendrix.edu/~yorgey/forest/2026-W16/ 2026-W16 /~yorgey/forest/2026-W16/ Weeknotes for 24 April 2026 (week 16) Not much of interest to report this week—a lot of my time has been spent on various administrative responsibilities, as both the chair of my department and the chair of the Committee on Academic Integrity. Next week is the last week of classes, so over the next few weeks I should start to have more time to work on interesting projects. I did complete my Agda proof of the Fundamental Theorem of Arithmetic, and I'd like to turn it into a blog post. I fancy there might be an audience of people who know the basics of Agda but would benefit from seeing a slightly larger development with lots of careful explanation. Brent A. Yorgey 2026 5 3 http://ozark.hendrix.edu/~yorgey/forest/2026-W17/ 2026-W17 /~yorgey/forest/2026-W17/ Weeknotes for 1 May 2026 (week 17) Brent A. Yorgey 2026 5 3 Wrapping up the semester Friday, May 1 was the last day of classes for the semester. There is still plenty of work to do over the next two weeks (final exams / final project presentations, grading, dealing with cases of academic misconduct, etc.) but the pace will be much more relaxed. I'm looking forward to slowly ramping up some summer projects. Brent A. Yorgey 2026 5 3 Thoughts on Forester for lecture notes Using Forester to write up lecture notes for my Discrete Mathematics course has been a resounding success. Writing them in this medium forced me to think much more carefully about how things are organized and presented, which in many cases led me to make substantive changes for the better, despite having taught this course many times before. I think the students also found it helpful to have the notes available in an easily searchable and hyperlinked format. One of the things I want to do over the next few weeks is to go through the notes to clean some things up, add more hyperlinks, and add some extended/optional material in cases where I didn't have time during the semester, possibly put together a simple preprocessor that will allow me to embed Diagrams code—but overall I think the notes are in really great shape. I definitely plan to do something similar for other courses in the future. Next up will be my Algorithms course in the fall, I think. Brent A. Yorgey 2026 5 3 "To my students" On Monday, I published a piece I had been working on for a while, unimaginatively titled To my students. This year in particular, it felt increasingly disingenuous to say nothing about the current political and technological climate—but I am not good at speaking extemporaneously about such weighty topics, so I decided to write something instead. When it was finished, I emailed a link to my students, and posted a link on Mastodon. I was not expecting the magnitude of the response. I heard from many current students who were appreciative, and had interesting conversations with several of them. My piece apparently got posted to a much wider student community via social media. My Mastodon post got much more traction than my posts usually do (though 120 boosts hardly counts as "going viral"). It was also posted to Hacker News, and I made the mistake of reading some of the comments. I heard from a few random strangers for whom the piece resonated particularly strongly. I also heard from someone who was my student when I taught high school math 20 years ago. With the exception of the Hacker News comments, overall the experience was very positive and encouraging. Brent A. Yorgey 2026 5 3 Mutable and immutable arrays and CESK machines I have continued working on immutable arrays in Swarm, but have been stymied by the complexity of implementing a fully general introduction form via a CESK machine. Trying to implement it from scratch was breaking my brain, so I tried implementing it in pure Haskell, then doing a manual CPS transformation followed by manual defunctionalization, to try to more mechanically derive the required CESK implementation, but even that was breaking my brain. I finally realized this morning that perhaps I have been thinking about this all wrong. I started out implementing only immutable arrays because I thought it would be simpler—and I figured I would introduce mutable arrays later. But the need for such complicated introduction forms could be circumvented entirely with mutable arrays. That is, I think I will stick with a simple yet impoverished introduction form for immutable arrays for now (unfoldArray : b -> (b -> (Unit + a*b)) -> Array a), and then later introduce mutable arrays along with a copying freezeArray : MArray a -> Array a. Although thinking about general introduction forms for immutable arrays has been interesting, I think this will be a lot simpler and more robust. Brent A. Yorgey 2026 5 3 Piano corner I've continued working on the Chopin 1st concerto. I'm close to being able to play the entire first movement—only the coda still needs significant work. Over the summer I want to continue working on the concerto while also being more systematic about practicing other things in my repertoire and possibly learning some other, shorter, new pieces as well. Through an unlikely series of events, it looks like I may have an opportunity to acquire a free (!!) 2002 Yamaha C7 grand piano for my church. This is one of the absolute best pianos on the market, and typically costs something like $20k-30k used; a brand-new Yamaha C7X, the successor model, costs about $90k. Getting one for free still seems too good to be true, but I am warily optimistic. I will certainly write about it (with pictures) if it does indeed come together! In that case I will almost certainly be spending more time at my church just to play it... I love my Yamaha T118 upright, but it can't compare with a 7'6" Yamaha grand. Brent A. Yorgey 2026 5 10 http://ozark.hendrix.edu/~yorgey/forest/2026-W18/ 2026-W18 /~yorgey/forest/2026-W18/ Weeknotes for 8 May 2026 (week 18) Brent A. Yorgey 2026 5 10 Still wrapping up the semester... Last week I wrote "There is still plenty of work to do... but the pace will be much more relaxed." I always forget that this is completely false. Last week was not more relaxed, it was a zoo. I can only assume this coming week will be the same (in particular, my department is trying to hire a 1-year visitor at the last minute, and I am the chair of the department and hence the chair of the hiring committee); but there is light at the end of the tunnel. Brent A. Yorgey 2026 5 10 Pride goeth before the fall In last week's piano corner, I said "Through an unlikely series of events, it looks like I may have an opportunity to acquire a free... piano". I am extremely ashamed to have to write this, but it turns out to have been a scam. (The "piano" was free, but of course the shipping was not...) Fortunately, I did not end up giving the scammers any money—but only very narrowly. I actually got as far as attempting to send them money via Venmo, but Venmo stopped the payment because it suspected a scam. This, coupled with a friend's skepticism, finally got me to dig more deeply and uncover incontrovertible proof that the whole thing was a scam all along. This has been a very humbling and sobering experience. I like to think of myself as sophisticated, educated, intelligent—just as, I assume, many of us do—and therefore immune to scams or misinformation. But that seems to have actually made it worse. I wanted so badly for it to be true that I used my sophisticated, educated intelligence to spin all sorts of justifications for why it was not actually a scam despite the (many!) red flags. In the end, I am really thankful that I only lost some pride, not money, and I hope that this experience will help me be more careful and less trusting of my own judgment in the future. 2026 5 10 http://ozark.hendrix.edu/~yorgey/forest/00GN/ 00GN /~yorgey/forest/00GN/ Deriving an efficient partition conjugation function On Saturday I was solving a Kattis problem for which I realized that I needed some Haskell code to efficiently compute the conjugate of an integer partition. That is, if we think of a partition as a Ferrers diagram, the conjugate is the partition we get by flipping the diagram along the main diagonal. I managed to write an efficient implementation, and solve the Kattis problem, simply by thinking hard; but it made me wonder whether one could derive an efficient implementation starting from an obviously-correct yet inefficient specification (via the Bird-Meertens formalism, aka Squiggol). I spent a very pleasant Sunday afternoon trying to work this out and discussing it on Mastodon. I think I'm quite close to having a completely formal derivation; I hope to turn it all into a proper blog post next week. Brent A. Yorgey 2026 5 16 http://ozark.hendrix.edu/~yorgey/forest/2026-W19/ 2026-W19 /~yorgey/forest/2026-W19/ Weeknotes for 15 May 2026 (week 19) Brent A. Yorgey 2026 5 16 Still still wrapping up the semester... This week was even worse than last week: students turning in last-minute assignments at the start of the week, submitting final course grades, dealing with lots of academic integrity (aka cheating) cases (I am the chair of my college's academic integrity committee), conducting a last-minute search for a one-year visiting position (I'm the chair of my department and hence the de facto chair of the search committee), participating in a half-day workshop for a new first-year course I will be teaching in the fall... and on top of all that, my church has hired a new pastor who will be arriving soon, and there has been a lot of work getting ready for his arrival and organizing his ordination service. Basically, I find myself in several leadership positions, all of which required more work than usual over the past few weeks in particular! I definitely didn't have time to write the blog post I promised last week. Fortunately, in all cases there is light at the end of the tunnel: academic integrity stuff is finished; the search is proceeding well after the initial flurry of reading lots of applications; and almost everything is arranged for our new pastor's arrival. I always hesitate to say "next week will be better", because I am frequently wrong. But I really do think next week I will be able to start easing into some summer projects. Brent A. Yorgey 2026 5 23 http://ozark.hendrix.edu/~yorgey/forest/2026-W20/ 2026-W20 /~yorgey/forest/2026-W20/ Weeknotes for 22 May 2026 (week 20) This week was indeed much better than last week! There was still a good deal of administrative work, but I actually had time to work on some projects. Brent A. Yorgey 2026 5 23 Deriving an efficient conjugate function for integer partitions I finally had more time to work on deriving an efficient integer partition conjugation function. My optimism of two weeks ago was unfounded—I worked on it a good deal this week but haven't cracked it yet. But I feel like I have made some good progress, and it's been fun refreshing my memory on stuff from The Algebra of Programming and Algorithm Design with Haskell. If anyone would be interested in collaborating on this, I'd be happy to jump in a video call. Brent A. Yorgey 2026 5 23 Open-source maintenance The diagrams-solve and diagrams-lib packages are full of uses of partial functions such as head and tail, having been written before Data.List.NonEmpty really existed. But they generate tons of warnings, and I finally decided to bite the bullet and eliminate the use of partial functions as much as possible. This has involved some tricky analyses of which lists can be statically known to be nonempty, especially in e.g. list-heavy code used to compute operations on Bernstein polynomials, but I made some very good progress this week and the conversion is almost complete. Brent A. Yorgey 2026 5 23 Swarm Brent A. Yorgey 2026 5 23 Immutable arrays I have finally finished my pull request adding immutable arrays to the language! In the end I was able to come up with a scenario that requires the use of arrays to solve in a reasonable amount of time, but only needs immutable arrays constructed with an unfold operation: you first "read" a random permutation from a row of letters laid out on the ground, then iterate the permutation a certain number of times and lay the letters back down in the resulting order. If anyone can think of an efficient way to solve this without the use of an array, I'd love to hear about it! Brent A. Yorgey 2026 5 23 New contributors, and import bugs Swarm has had several new contributors pop up this week, which is fun. Tom Scheper found a bug which is rather obvious in retrospect—when encountering a module import, we only check the file itself for changes, but not any of its transitive imports. But this means that if A imports B, and you modify B then re-import A, you will not actually pick up the changes to B unless you touch A as well. Fixing this is a bit finicky. We can't just transitively check all imports every time, since we would end up re-checking the same modules repeatedly. Instead, I think the right idea is to do two passes when processing some top-level source code: first, transitively check its imports looking for any in the module cache that are outdated, and flag them for a reload. Then, do a second pass where we actually recursively load and check all the modules that need to be loaded, either because they have not been loaded yet or because they are flagged. I started working on the fix for this a couple days ago and hope to finish soon. Brent A. Yorgey 2026 5 23 Math search As I briefly mentioned in some previous weeknotes, my department is hiring a Visiting Assistant Professor of Mathematics for next year (kind of at the last minute), and we did a bunch of work on our search this week. We held virtual interviews with several candidates on Wednesday and Thursday afternoons; the committee then met Friday and decided on one to invite for an on-campus interview; the rest of my afternoon consisted of writing a formal request to the provost and setting up phone conversations with some references. I'm hopeful we can wrap up the search in the next few weeks. Brent A. Yorgey 2026 5 23 Piano corner This week I pulled out my book of Chopin waltzes and have enjoyed playing through and refreshing them. It turns out there are actually only a few left that I don't know, and they all seem lovely. I think I might make a side quest for the summer to learn them all; this week I learned No. 13 in D flat major. Next week I'm going to make an intentional plan for what I want to work on over the summer. Brent A. Yorgey 2026 5 29 http://ozark.hendrix.edu/~yorgey/forest/2026-W21/ 2026-W21 /~yorgey/forest/2026-W21/ Weeknotes for 29 May 2026 (week 21) This week I spent a lot of time helping friends move, fixing Swarm bugs, and working on our search for a 1-year visiting professor. There's never as much time during the summer to work on big projects as I think there will be, or would like there to be! But I'm excited to be participating in a "Community of Practice" with other faculty around the book Stolen Focus by Johann Hari. I'm also excited to take a quiet creative retreat this coming Tuesday-Thursday—I've booked an AirBnB at a place in the country about 20 minutes away for a couple nights! Expect a full report in next week's weeknotes. Brent A. Yorgey 2026 5 29 Swarm Brent A. Yorgey 2026 5 29 Fixing transitive import bug I fixed the import bug from last week. Doing two passes was the right general idea, but I didn't have the details right. My son actually helped me figure out the right way to do it: first do a DFS through the module cache, evicting everything that is outdated or depends on something outdated. After that, the actual loading code does not need to change! Any module which depends on something that has changed will have been evicted from the cache, so we are forced to reload and recheck it. Simple and robust. Brent A. Yorgey 2026 5 29 Exponential import blowup Ondřej Weis tried testing the import system and, to my simultaneous shame and joy, easily made it completely fall over. Shame because I worked really hard on that code and thought it was really clean, elegant, and well-thought out. Joy, because it's wonderful to have someone point out flaws so they can get fixed. In particular, if you created a linear chain of modules where each imports the next, the amount of time it took to load them from disk was exponential in the number of modules! This completely flummoxed me—I was looking for places where a recursive function accidentally called itself twice on the same AST, or something like that. But once again Ondřej came to the rescue and figured out that it was because of the way we dynamically built up a stack of unresolved effects as we recursed (every level gets its own new, local, Accum effect to record the imports for each module). Apparently fused-effects, the effects library we use, does not deal with this situation well at all (though I still don't understand how it leads to exponential time complexity)! In any case, Ondřej fixed it by handling the accumulation effect explicitly. Brent A. Yorgey 2026 5 29 Math search This week was a lot of "hurry up and wait" as I waited through the holiday weekend for people to be able to work on scheduling a candidate visit, then waiting to hear back from various people we needed to schedule a meeting with, waiting to hear back from some students we would like them to meet with... We finally have the in-person interview all scheduled for this Monday! Brent A. Yorgey 2026 6 6 http://ozark.hendrix.edu/~yorgey/forest/2026-W22/ 2026-W22 /~yorgey/forest/2026-W22/ Weeknotes for 5 June 2026 (week 22) This week has finally felt like the start of summer! Brent A. Yorgey 2026 6 6 Concluding the Visiting Assistant Professor search! On Monday of this week, we brought a candidate for an on-campus interview for our 1-year visiting position in mathematics. We made them an offer on Wednesday, and by Friday they had officially accepted! I'm looking forward to have a new colleague joining us for next year, and also very glad that the search is over—being the chair of a search committee was a lot of work! Even though it's official and thus presumably public information, out of an abundance of caution I won't yet mention who it is; I'll probably mention them at some point in the future. Brent A. Yorgey 2026 6 6 Personal creative retreat From Tuesday evening to Thursday morning of this week, I took a personal creative retreat. I stayed at an AirBnB out in the country about 20 minutes away from my house, in a one-room bungalow located on the grounds of a ranch/event/wedding venue. It was spacious and quiet, with plenty of natural light but a lot of big old shade trees, so it stayed cool without having to run the A/C unit. Pretty much perfect for working and thinking deeply, and the timing could not have been more perfect—right after finally wrapping up our search. Over the course of my 36-hour stay I got plenty of sleep, ate some good food, read part of Martha Wells' Queen Demon, and also did about 11 hours worth of focused, deep work, on three main projects.2026627http://ozark.hendrix.edu/~yorgey/forest/00H5/00H5/~yorgey/forest/00H5/Embedding diagrams in ForesterI would really like to be able to use Diagrams from within Forester, so I spent a bit of time working on a diagrams-forester preprocessor tool. The idea is that it will look for special sentinel blocks that look like Then it would run the diagrams code in the ..., and replace the entire diagram block with an image link. diagram would also be defined to produce some kind of dummy placeholder, so the code would be valid Forester code both before and after the preprocessor runs. I don't want to spend a lot of time on this, but it's definitely worth spending a few hours on this summer, so I wanted to get it off the ground. So far it can identify and parse the diagram blocks; I still need to hook it up to the diagrams-builder package and deal with things like input and output directories and so on.Brent A. Yorgey202666Fixing Swarm code metrics to work with importsWhen you complete a Swarm scenario, in addition to recording your time (both wall-clock and in-game time), it can also record the size of your code, both in terms of the number of characters and the size of the AST, and it records your best (smallest) scores. This makes it easy to play code golf (competing with yourself, or with others).However, when I added import to the language, I completely forgot about this mechanism, and a user recently reported that the game was not counting imports toward the code size, making it possible to game the system by shoving all your code into an import. Whoops!Fixing this was conceptually straightforward, but nontrivial from an engineering point of view. First, I decided that I didn't want to do a DFS through the import graph every time we want to measure code size—we already do a DFS through the import graph when loading modules in the first place, so why not just cache some relevant information at that point? So, I added a field to each module record to store a cached set of *all* its transitive dependencies. Making sure that field was filled in properly involved a number of interesting bugs that I won't go into—including an infuiriating one where a test got the correct result, and then later got an incorrect result when rerunning the exact same test! (it had to do with, you guessed it, caching)—but I finally got everything working with an elegant framework for easily adding more code metrics in the future.2026613http://ozark.hendrix.edu/~yorgey/forest/00H4/00H4/~yorgey/forest/00H4/Blog post on proof of Fundamental Theorem of Arithmetic in AgdaA couple months ago I reported that I had, just for fun, completed a completely-from-scratch proof of the Fundamental Theorem of Arithmetic in Agda, and I've decided to turn it into a blog post/tutorial. It's not an Agda tutorial—I'm assuming the reader already knows the basics of Agda and the Curry-Howard correspondence—but I'm not assuming much beyond that. There's lots of introductory material out there, but I feel like it might be helpful to have a fully explained medium-size proof, for people who have learned the basics and played around with proof assistants, but would find it helpful to see a more fully worked example. Along with the blog post I plan to publish a version with holes, so someone wanting to learn could try to fill in the holes while reading along with the explanations.I spent a bunch of time (about 5 hours) working on the writeup. A lot of fun stuff in there, including well-founded induction. I would say it's about... 2/3 finished. At 11K words so far, it is not going to be short! Brent A. Yorgey 2026 6 6 Piano corner For some reason this week I dug out my old copies of Hanon and Czerny's "School of Velocity". Kinda boring but a good way to spend 10 minutes warming up. I've continued working through all of Chopin's waltzes—I've played many of them before, but they're somewhat rusty, so I'm systematically going through and polishing them up. So far I'm up to number 4. Brent A. Yorgey 2026 6 12 http://ozark.hendrix.edu/~yorgey/forest/2026-W23/ 2026-W23 /~yorgey/forest/2026-W23/ Weeknotes for 12 June 2026 (week 23) Brent A. Yorgey 2026 6 12 Family We enjoyed time with visiting family this week. On Thursday, I hiked up Pinnacle Mountain with my sister-in law and 6 of our kids (2 of mine and 4 of hers). It's a strenuous hike (about 220 meters elevation gain over a 1.8km trail) with a lot of fun scrambling over rocks that pays off with a lovely view at the top. Brent A. Yorgey 2026 6 12 Blog post on FTA proof in Agda I worked a bunch more on this blog post/tutorial I mentioned last week. I'm very close to completing a first pass through the entire proof: cleaning up, reorganizing, and writing prose to explain everything. Next week I'll make a second pass through editing and polishing; then I'll go through and create a version with holes for people to download and play along. The plan is to have it published in the next week or two. Brent A. Yorgey 2026 6 12 Swarm type + requirements system One of the most interesting things about Swarm is the core mechanic where you must obtain and craft devices that allow you to unlock programming language features. So we have to be sure robots are able to run their code. We can (and do) use dynamic runtime checks, but it would be very annoying and tedious if this were the only safeguard. When you build a robot to run a program, you don't want to manually install all the required devices (there could be dozens, if you are using many language features); you also don't want robots to get halfway through running their programs only to crash because they are missing some required device. So there is a requirements analysis which figures out what capabilities a program requires, and which devices could provide them; when building a robot, those devices are automatically installed (or, if you do not possess the necessary devices, the build fails). However, this requirements analysis is an ad-hoc step bolted on after typechecking. At the time I wrote it, I didn't really understand what I was doing. Over the years, however, this ad-hoc bolted-on requirements analysis has led to all sorts of bugs. I've come to realize that the requirements for a program should really be part of its type, with requirements analysis integrated into the type system, similar to other existing work on type-and-effect style systems. The twist is the distinction between required capabilities and required inventory; the command turns the former into the latter, since in order to execute you must have the correct devices in your inventory in order to equip them on the newly constructed robot. I've spent some time this week working on a formal writeup of a system that I think will fit the bill. The interesting part is that we really need requirements polymorphism, which means that instead of just keeping track of sets of requirements, we need to keep track of expressions involving requirement variables, and then solve equations over these expressions after generating them during type inference. I am hopeful that this will work out nicely, but there are always unforeseen wrinkles. Brent A. Yorgey 2026 6 12 Piano corner I have Chopin's waltzes polished up through number 7. Number 4 in F major is one I've never played before, but it's a lot of fun; most of my time this week has been spent learning it. Number 8 is another one I've never played, so next week I will be learning that one. Brent A. Yorgey 2026 6 22 http://ozark.hendrix.edu/~yorgey/forest/2026-W24/ 2026-W24 /~yorgey/forest/2026-W24/ Weeknotes for 19 June 2026 (week 24) Brent A. Yorgey 2026 6 22 Markdown processing and layout in Swarm As part of my work on adding a help system to Swarm, I realized that I needed to better understand our code for processing Markdown (used for in-game item descriptions, scenario descriptions, and the like). Of course, what started out as innocently reading through the code and adding some extra comments ended with me rewriting a bunch of code from scratch, which I ended up working on obsessively all week. However, I'm quite pleased with the result, which not only fixes several issues we had with spacing and code layout, but also paves the way for easily adding features like hyphenation and syntax highlighting, in addition to expanding the range of Markdown we support to include links and lists. Brent A. Yorgey 2026 6 22 Hanabi Hanabi is a fascinating cooperative game of logical deduction (if you don't know it I recommend checking it out). My family has had it for a while, and played it occasionally, but within the past week we have been getting into it a bit more, occasioned by my 8-year-old requesting to be taught how to play. I played a game with him, and he and my older son have both played games with my wife. I re-read the introductory conventions from the H-group, and my older son and I tried playing an online game using some of those conventions. Hopefully soon we can play some larger games with more of us all together (2-player games are a bit odd). Brent A. Yorgey 2026 6 22 Piano corner I continued working on Chopin's waltzes, spending the majority of my time learning Number 8 in A♭ major this week. It still needs a bit more polishing, but it's largely done. I also continued polishing a few others, notably No. 12 in F minor/A♭ major. In putting together these weeknotes, I've also realized that what exactly counts as a Chopin waltz is somewhat up for debate! There are some pieces that have been attributed to him but probably aren't authentic; some pieces that are definitely by Chopin but may or may not count as a waltz; some authentic waltzes that we know existed but whose manuscripts have been lost; and some authentic waltzes that were published after his death that he may or may not have wanted to be published. The Dover edition I have contains 17 waltzes (of which I currently know 14). After consulting the Wikipedia page, it seems like there are two more that I want to include in my project: both posthumous waltzes in A minor, the first published in 1955 and the second discovered two years ago at the Morgan Library (which I already learned shortly after it was discovered). I really ought to start creating pages in this forest for pieces in my repertoire... Only a week and a half left until we leave for our yearly month-long pilgrimage to Maine, where I do not have access to a piano. I was really hoping to finish learning all the waltzes before we leave, but it's looking unlikely that I will have time (I still have approximately four more of them to learn). Oh well, I can finish the project when we get back. Brent A. Yorgey 2026 6 27 http://ozark.hendrix.edu/~yorgey/forest/2026-W25/ 2026-W25 /~yorgey/forest/2026-W25/ Weeknotes for 26 June 2026 (week 25) Brent A. Yorgey 2026 6 27 Blog post on FTA proof in Agda I finally made a last big push and finished up my blog post/tutorial on an Agda proof of the Fundamental Theorem of Arithmetic (see here for a previous discussion), which ended up being about 13K words (including both prose and code). Somehow this always happens to me—I set out to write a "short note" about something and then end up with a book, or a 19-part blog post series, or whatever. I don't think it's a bad thing. I just ought to know by now what's going to happen at the outset. Brent A. Yorgey 2026 6 27 Forester hacking I've gotten a bit stuck on my tool for Embedding diagrams in Forester. The surrounding infrastructure is not hard, but the core mechanic of extracting code to a temporary Haskell file and then calling out to another GHC process to interpret the code, via the hint package, is very fiddly; I haven't yet been able to get versions/package databases/planets/mystic sigils etc. to line up properly. I've also been idly wondering about embedding music notation within forests via lilypond. I will have to look into how Liam O'Connor includes chant notation in his forest (e.g. here). Brent A. Yorgey 2026 6 27 Hanabi I have continued playing some Hanabi, especially with my 14-year old. We've played a couple games with strictly no verbal communication. The first time we did terribly, scoring 18/25; the second was much better, 24/25. In both cases we learned a lot from our mistakes. I'm looking forward to playing more on vacation and introducing some family members to the game and/or strategies. Brent A. Yorgey 2026 6 27 Piano corner Worked more on Chopin waltzes; I also practiced several of the movements of John Rutter's Suite Antique for flute and piano. My wife and I played the whole suite together over 20 years ago, when we were dating, but we haven't had many chances to play together since then (first, we didn't have a piano; then, when we did have a piano, we had small kids, which made it hard to find the time to play together). It was my wife's idea to pull it out, and I'm looking forward to playing with her again! More generally, I hope we can find more opportunity to play together now that our kids are not quite so little (our youngest is 5, and we're not likely to have any more). We can start by reviving the Rutter as well as Poulenc's flute sonata, which we also played together a long time ago. Eventually I'd also love to play the Prokofiev flute sonata. Brent A. Yorgey 2026 7 5 http://ozark.hendrix.edu/~yorgey/forest/2026-W26/ 2026-W26 /~yorgey/forest/2026-W26/ Weeknotes for 3 July 2026 (week 26) Brent A. Yorgey 2026 7 5 Maine road trip 2026, part 1 My family makes an annual summer pilgrimage from Conway, Arkansas to Peru, Maine, where my family owns a cabin. Getting there involves a week-long road trip in either direction, with plenty of stops along the way to see sights, friends, and family, with a different route every year—the road trip is not just a means to an end but an integral part of the vacation! This year, we first drove to Mammoth Cave National Park in Kentucky. Mammoth Cave is the longest known cave system in the world, with over 685 km of known passageways. We took a guided tour of (one tiny part of!) the cave, which was quite impressive. Next we drove to Pittsburgh, Pennsylvania to stay with friends for a few nights. Activities included a visit to the Kamin Science Center (including, of course, a photo op on the space toilet), dinner with other friends, 4th of July fireworks on the campus of Carnegie Mellon, and attending a Sunday morning service at City Reformed Presbyterian Church. I also went for a mountain bike ride in Frick Park, which was fun but exhausting. Tomorrow we head to Williamstown, Massachusetts for the last stop on our journey. Brent A. Yorgey 2026 7 5 Including diagrams and lilypond snippets in Forester I've been thinking more about how to embed diagrams and lilypond output in Forester trees. Last week I reported feeling stuck on the diagrams preprocessor I was building, but I recently realized I've been overthinking it: rather than call a diagrams interpreter programmatically (which runs into issues with package databases, mismatched GHC versions, etc.), I should just use it as an external executable. The other benefit of this approach is that it should work similarly for lilypond, which also works as an external tool that compiles source code to an image, so I hope I can reuse a lot of the same infrastructure in my preprocessing tool. Brent A. Yorgey 2026 7 5 Piano corner Since we've been on our trip, I haven't been able to play the piano, but I did create a page for my piano repertoire. There are only a couple pieces listed so far, but I plan to add new pieces incrementally. Brent A. Yorgey 2026 7 10 http://ozark.hendrix.edu/~yorgey/forest/2026-W27/ 2026-W27 /~yorgey/forest/2026-W27/ Weeknotes for 10 July 2026 (week 27) Brent A. Yorgey 2026 7 10 Maine We made it to Maine! It's delightful here. I've already read two whole books, done a lot of swimming, and baked some traditional Abie cake. Here's a picture I took of a common loon swimming right by our dock: 2026 7 10 http://ozark.hendrix.edu/~yorgey/forest/00IO/ 00IO /~yorgey/forest/00IO/ Lilypond snippets in Forester I built a simple preprocessor that can extract arbitrary blocks from Forester source and run them through an external tool, replacing the block with an image. I then put the whole thing together into a Shake build system for my forest. Now I can include musical snippets using lilypond syntax, like this: I've been slowly adding musical snippets to identify the first few bars of pieces in my piano repertoire. For example, check out [CW02] Waltz in A♭ major, Op. 34 No. 1.Next I'll extend the preprocessor to work with diagrams as well. Brent A. Yorgey 2026 7 18 http://ozark.hendrix.edu/~yorgey/forest/2026-W28/ 2026-W28 /~yorgey/forest/2026-W28/ Weeknotes for 17 July 2026 (week 28) Brent A. Yorgey 2026 7 18 Diagrams in Forester! Shortly after adding the ability to embed lilypond snippets in my forest, I finished adding support for embedded diagrams code as well: I'm super excited that I finally got this to work. I've already used it to add some diagrams to my Discrete math lecture notes, for example, here. If you're curious to see how this works, check out the Shake file here. Brent A. Yorgey 2026 7 18 Maine Continuing to hang out in Maine. I've eaten a lot of ice cream, played a lot of Hanabi, spent part of a day riding again at Mt. Abram Bike Park (I only almost died twice), etc. Brent A. Yorgey 2026 8 8 http://ozark.hendrix.edu/~yorgey/forest/2026-W31/ 2026-W31 /~yorgey/forest/2026-W31/ Weeknotes for 7 August 2026 (week 31) Brent A. Yorgey 2026 8 8 Maine We finally returned earlier this week from our annual trek to Maine. We saw a lot of loons, including seven at once, which I had never seen before—they tend to be rather solitary—but apparently this is a thing. While there, in addition to a bunch of reading and swimming, I made an elaborate DnD-style campaign for my 8-year-old, and played a lot more Hanabi. On our way home, we saw The Odyssey (not in IMAX, just a regular big theater screen) and enjoyed it. Geeked out with my percussionist band nerd son about Ludwig Göransson's use of a rhythmic Shepard tone. Brent A. Yorgey 2026 8 8 Swarm My work on Swarm has inched along slowly—still working on Markdown processing in preparation for building an integrated help system. In other news, however, Patrick Estrada did a bunch of work switching out fused-effects for effectful—leading to some significant speedups! Brent A. Yorgey 2026 8 8 Semester prep This past week I've just started working on preparations for the fall semester. (The first few years I taught at Hendrix, I would tell myself that I would work on fall preparations a little bit each week over the summer, in order to spread out the work; then I would spend the whole summer not working on fall course prep and feeling guilty about it; then at the end of the summer I would do everything at the last minute in an anxiety-fueled and still guilt-ridden panic. After a few years of this I finally realized that I should just give myself permission to not work on fall prep over the summer.) I've started with Algorithms. I've taught this course many times before, so for the most part I won't be making any big changes; but I do plan to write up my lecture notes in Forester this year, just like I did for Discrete Math last spring. I've also been making a few changes to the course design in light of what I strongly suspect was too much use of generative AI by students in the course last year. In particular I plan to add one more in-class exam, and require students to come into office hours some number of times for some kind of formally assessed conversation/quiz/oral exam thing. I'm still not quite sure of the details. Brent A. Yorgey 2026 8 15 http://ozark.hendrix.edu/~yorgey/forest/2026-W32/ 2026-W32 /~yorgey/forest/2026-W32/ Weeknotes for 14 August 2026 (week 32) Brent A. Yorgey 2026 8 15 Swarm integrated help system I've started actually putting together the Swarm integrated help system in earnest—the idea is to have a collection of interlinked documents, stored as a bunch of Markdown files, which can be displayed and explored interactively from within the game (and which can also be compiled into a static HTML form). There's nothing technically challenging about this at all, just a bunch of engineering. But as the semester ramps up that's exactly what I need—something on which I can make consistent progress in bits of time here and there, without needing big blocks of time to think deeply. Brent A. Yorgey 2026 8 15 Semester prep This week was full of meetings and workshops (department chairs workshop on Monday; meeting with my colleage about our co-taught course on Wednesday; an all-day workshop on new student advising on Thursday; a workshop on the new first-year course on Friday). After getting back from vacation a couple weeks ago, my todo list is already extremely long. I'm looking forward to the semester for the most part, but as usual I wish I could spend my time working deeply on a few things rather than having a million tiny administrative tasks. I am most definitely looking forward to my next sabbatical in a year or two. Brent A. Yorgey 2026 8 22 http://ozark.hendrix.edu/~yorgey/forest/2026-W33/ 2026-W33 /~yorgey/forest/2026-W33/ Weeknotes for 21 August 2026 (week 33) Brent A. Yorgey 2026 8 22 Swarm This week was the 5-year anniversary of my first commit to the Swarm repo—back in August of 2021, at the start of my sabbatical. It's been a wonderful, wild ride. The project has gone much farther than I could have imagined, and been more professionally fruitful than I would have thought possible! And a big part of the reason it's remained fun for so long is the cool community of other contributors the project has attracted. There's been a flurry of activity this week from several other contributors, so I've spent a decent bit of time reviewing PRs. Among other cool things, there have been some fantastic improvements to memory usage and performance. I've also continued working on an integrated help system this week. It's coming along nicely. One of the few things still missing is the ability to specify a table of contents for a given page, from which we can automatically display next/previous/up links. I basically plan to steal the way Sphinx does this with the toctree directive. Brent A. Yorgey 2026 8 22 First-year student advising I spent a substantial amount of time this week meeting with my cohort of 14 first-year student advisees—first as a group, and then individually. In past years, they have come to campus with blank slates and we would spend the first week frantically building their schedules, resolving conflicts, finding alternate classes when the class they wanted is too full, and so on. It didn't leave much time for anything besides putting out fires. Starting last year, we have a new system in place where they meet with someone virtually over the summer to put together an initial course schedule. By the time they arrive on campus they already have a mostly-solid schedule, and I just have to help fill it out with an extra class or two. It is much more civilized and leaves plenty of time for chatting and getting to know them and what they are interested in. Talking to people all day is a lot, but aside from that it was quite enjoyable; they all seem like lovely human beings with a wide variety of interests. Brent A. Yorgey 2026 8 22 Semester prep The fall semester is almost upon us. When I haven't been doing advising stuff I have been working hard on preparing for my fall courses. I'll be co-teaching our introductory programming course with my colleague, and we don't plan to change much about the course, which by this point is a well-oiled machine. On the other hand, I am making a few more changes to Algorithms this semester. In order to reduce incentives for LLM use, I'm adding an extra midterm exam and having some required office hour visits. But the extra exam makes it more awkward to fit in weekly problem sets at reasonable times, which suddenly made me wonder today whether I could do something more flexible, like assigning individual problems every day and having them choose a portfolio of problems to solve. I still need to work out a lot of details. Brent A. Yorgey 2026 8 22 Hanabi I have continued to enjoy Hanabi a lot—playing sometimes with my 14yo and sometimes with strangers on Hanab Live. I think I enjoy it for many of the same reasons that I enjoy bridge—it is collaborative rather than competitive (I'm super competitive and it's easy for me to get stressed out about winning and losing), and involves teamwork, communication, and logical deduction. I'm always happy to teach others, so if you're intrigued and would like to learn how to play, let me know! 2026 9 4 http://ozark.hendrix.edu/~yorgey/forest/2026-W35/ 2026-W35 /~yorgey/forest/2026-W35/ Weeknotes for 4 September 2026 (week 35) Missed last week's weeknotes since there is a whole lot going on at the start of the semester! 2026 9 4 Haskell Interlude I was on the Haskell Interlude podcast! I recorded the actual interview last spring, with Farhad Mehta and Sam Frohlich; the whole process was a lot of fun. I listened to the episode before it was released and I am not too embarrassed about anything I said, so give it a listen! 2026 9 4 Semester start Because of all administrative responsibilities, I had very little time to prepare for my actual classes, and the first few days of classes hit like a ton of bricks—I did not get very much sleep as I prepared syllabi and assignments at the very last minute. I do feel I'm in a better place now, though. Much of it was one-time overhead that need not be repeated. Getting to know my students has been fun. I am teaching one upper-level course (CSCI 382, Algorithms) in which I already knew most of the students; one introductory computing course (CSCI 150, Foundations of Computer Science); and one general education first-year seminar. For the most part, the students seem thoughtful and engaged. I am trying something a bit different with CSCI 382, Algorithms this semester (besides typing up my lecture notes in Forester). I used to assign weekly problem sets, consisting of a bunch of problems in a PDF that they would have one week to solve and submit. But scheduling the problem sets around exams and breaks, and making sure they contained appropriate material, was always tricky. They also didn't adapt well to students who were either very advanced or struggling. This semester, I am simply publishing a collection of problems, and the students are responsible for selecting which problems they want to solve. To help ensure they are making consistent progress, they still have weekly "problem sets" due, but the problem sets do not specify which problems they must solve, but only a required number of problems instead. This allows me to publish a wider variety of problems, as well as helping students who fall a bit behind continue to make consistent progress without penalizing them for being behind. We'll see how it goes! I am cautiously optimistic, though of course I'm sure there are things I will learn and change about the system next time. 2026 9 4 Missing ICFP ICFP was relatively close to me this year (Indianapolis would be about a 9 hour drive, or a short plane flight or two, away), but unfortunately, it happened during the first week of classes. Since I am the department chair and an advisor for first-year students, that sadly made ICFP a no-go. Spent the week watching the occasional livestream, reading friends post about ICFP on Mastodon, and just generally feeling like I was missing out. I am already plotting how I can make it to Nijmegen next year... 2026 9 4 Admin corner A bunch of my extra time is taken up right now with two major administrative tasks: completing a self-evaluation, and putting together a hiring request for next year. Both are due early next week. I will be very glad when they are both done! 2026 9 4 Swarm Only a tiny bit of incremental progress on the integrated help system this week; looking forward to having the above admin stuff done so I can get back to working on this more regularly! 2026 9 4 Piano corner I've continued to work on my Chopin waltz project. I'm also slowly adding repertoire to my forest. Backlinks Related Contributions