http://ozark.hendrix.edu/~yorgey/forest/contact/ contact /~yorgey/forest/contact/ Contact information Office MC Reynolds 310; make an appointment Phone +1 501 450 1377 Email last name at hendrix.edu Github byorgey IRC byorgey on LiberaChat Mastodon https://mathstodon.xyz/@byorgey References Context Brent A. Yorgey http://ozark.hendrix.edu/~yorgey/forest/index/ index /~yorgey/forest/index/ Brent Yorgey false http://ozark.hendrix.edu/~yorgey/forest/contact/ contact /~yorgey/forest/contact/ Contact information Office MC Reynolds 310; make an appointment Phone +1 501 450 1377 Email last name at hendrix.edu Github byorgey IRC byorgey on LiberaChat Mastodon https://mathstodon.xyz/@byorgey Brent A. Yorgey 2025 10 24 http://ozark.hendrix.edu/~yorgey/forest/0001/ 0001 /~yorgey/forest/0001/ About this site This site is a "forest" created using Forester. Click on headings to collapse or expand sections, or click on the alphanumeric ID next to a section heading to open the section in a new page. Type Ctrl+K to search the graph. 2025 10 24 http://ozark.hendrix.edu/~yorgey/forest/0005/ 0005 /~yorgey/forest/0005/ Links My biography How to pronounce my last name What I'm up to right now My weeknotes The list of productivity tools I use Want to ask me for a letter of reference? Read this guide first. Brent A. Yorgey 2026 3 7 http://ozark.hendrix.edu/~yorgey/forest/009L/ 009L /~yorgey/forest/009L/ Statement on LLMs I do not and will not use LLMs, in any form, for any purpose. Although LLMs are fascinating from a purely technical perspective, I refuse to participate in or contribute to such systems that are built on massive exploitation of human labor and make profligate use of scarce resources. I also don't think they are actually very good for a lot of the applications people seem excited about. Even in cases where LLMs are technically good at a task, that does not necessarily mean their use for that task contributes positively to human flourishing. A good way to describe myself is as a generative AI vegetarian. You can find a fuller explanation—and many, many links—at the above essay by Sean Boots, which I agree with almost 100%. On bad days, I find myself feeling more like Anthony Moser. Here is something I wrote for my students reflecting on the current state of the world and what I hope for them as they go out into it. 2025 10 25 http://ozark.hendrix.edu/~yorgey/forest/0007/ 0007 /~yorgey/forest/0007/ News and announcements 2025 9 25 http://ozark.hendrix.edu/~yorgey/forest/005Y/ 005Y /~yorgey/forest/005Y/ ZuriHac invited keynote on competitive programming I gave an invited keynote talk on competitive programming at ZuriHac 2025. 2025 1 23 http://ozark.hendrix.edu/~yorgey/forest/0008/ 0008 /~yorgey/forest/0008/ New JFP paper published My paper, You Could Have Invented Fenwick Trees (Functional Pearl), is now published in the Journal of Functional Programming! 2024 12 19 http://ozark.hendrix.edu/~yorgey/forest/0009/ 0009 /~yorgey/forest/0009/ Haskell Symposium keynote I gave a keynote presentation at the Haskell Symposium on The Joy of Building (Functional) Languages (invited keynote). 2023 8 24 http://ozark.hendrix.edu/~yorgey/forest/000A/ 000A /~yorgey/forest/000A/ New Disco paper published My paper, Disco: A Functional Programming Language for Discrete Mathematics, has been published in the proceedings of TFPIE '23: Trends in Functional Programming in Education. 2025 10 24 http://ozark.hendrix.edu/~yorgey/forest/0002/ 0002 /~yorgey/forest/0002/ Teaching I teach computer science and mathematics at Hendrix College. Here is a short letter I wrote to my students reflecting on the current state of the world and what I hope for them as they go out into it. 2025 10 24 http://ozark.hendrix.edu/~yorgey/forest/0004/ 0004 /~yorgey/forest/0004/ Previous courses 2025 10 25 http://ozark.hendrix.edu/~yorgey/forest/000I/ 000I /~yorgey/forest/000I/ Previous courses taught at Hendrix College LBST 150J, The Engaged Citizen: The Art and Science of Creativity (co-taught with Melissa Gill, F '20) LBST 101, Explorations (F '18, F '20, F '22, F '24) CSCI 150, Foundations of Computer Science (F '15, S '16, S '17, S '18, F '18, S '19, F '19, S '20, S '21, F '22, S '23, F '23, S '24, S '25, F '25, S '26) CSCI 151, Data Structures (F '16, F '17, S '19) MATH 240, Discrete Mathematics (S '20, S '21, S '22, S '23, S '25, S '26) CSCI 322, Computing Systems Organization (S '22, S '24) CSCI 382, Algorithms (S '16, S '17, F '17, F '18, F '19, F '20, F '22, F '23, F '24, F '25) CSCI 360, Programming Languages (F '16, F '18, S '21, S '23, S '25) CSCI 365, Functional Programming (S '16, S '18, S '20, S '22, S '24, S '26) CSCI 410, Senior Seminar (F '16, F '17, F '19, F '20, F '22, F '24) 2025 10 25 http://ozark.hendrix.edu/~yorgey/forest/000J/ 000J /~yorgey/forest/000J/ Previous courses taught at Williams College CS 134, Digital Communication and Computation, an Introduction to Computer Science (co-taught with Bill Lenhart, F '14) CS 354, Functional Programming and the Art of Recursion (F '14) CS 136, Data Structures and Advanced Programming (S '15) 2025 10 25 http://ozark.hendrix.edu/~yorgey/forest/000K/ 000K /~yorgey/forest/000K/ Previous courses taught at University of Pennsylvania The Art of Recursion (F '12) CIS 194, Introduction to Haskell (F '10, S '12, S '13) CIS 500, Software Foundations (TA; S '10, S '11) CIS 120, Programming Languages and Techniques I (TA; F '09) 2025 10 25 http://ozark.hendrix.edu/~yorgey/forest/000L/ 000L /~yorgey/forest/000L/ Other previously taught courses Woodrow Wilson Senior High School, Washington DC Introduction to Computer Science ('04-'05, '05-'06) AP Computer Science AB ('04-'05, '05-'06) Honors Precalculus ('05-'06) Correspondence course in precalculus with homeschool students ('08-'09) http://ozark.hendrix.edu/~yorgey/forest/000C/ 000C /~yorgey/forest/000C/ Projects http://ozark.hendrix.edu/~yorgey/forest/000N/ 000N /~yorgey/forest/000N/ Disco Disco is a functional teaching language for discrete mathematics, implemented in Haskell. Heinrich Apfelmus recently built a basic web UI for students to be able to use Disco in their browser, and I'm using it to teach MATH 240, Discrete Mathematics this semester. Related talks and papers Brent A. Yorgey 2023 8 14 http://ozark.hendrix.edu/~yorgey/forest/yorgey-disco-2023/ yorgey-disco-2023 /~yorgey/forest/yorgey-disco-2023/ Disco: A Functional Programming Language for Discrete Mathematics Reference TFPIE '23: Trends in Functional Programming in Education 10.4204/EPTCS.382.4 http://ozark.hendrix.edu/~yorgey/pub/disco-tfpie23.pdf https://github.com/disco-lang/disco http://ozark.hendrix.edu/~yorgey/pub/disco-tfpie23-talk.pdf Disco is a pure, strict, statically typed functional programming language designed to be used in the setting of a discrete mathematics course. The goals of the language are to introduce students to functional programming concepts early, and to enhance their learning of mathematics by providing a computational platform for them to play with. It features mathematically-inspired notation, property-based testing, equirecursive algebraic types, subtyping, built-in list, bag, and finite set types, a REPL, and student-focused documentation. Disco is implemented in Haskell, with source code available on GitHub, and interactive web-based REPL available through replit. 2025 10 26 http://ozark.hendrix.edu/~yorgey/forest/000O/ 000O /~yorgey/forest/000O/ Swarm In the fall of 2021 I started developing a game called Swarm and built a small open-source community around its development. So far we have made a few official alpha releases, and development continues to hum along. We finally merged a big import feature to the language. I've recently finished work on an immutable array type, and now working on adding a help system. I've also been writing up some notes about a planned redesign of the type system. 2025 10 26 http://ozark.hendrix.edu/~yorgey/forest/000P/ 000P /~yorgey/forest/000P/ Applicative inference While working on a mini-DSL as part of the Swarm project, I got an intuitive sense that the types of DSLs involving an applicative functor can be fully inferred from (suitably restricted) programs that just use regular applicative notation, whereas for monads this would be ambiguous. I have been working, intermittently, on a research project to formalize and prove this idea. 2025 10 26 Related talks and papers Brent A. Yorgey 2025 1 30 http://ozark.hendrix.edu/~yorgey/forest/idiomatic-inference-PLV/ idiomatic-inference-PLV /~yorgey/forest/idiomatic-inference-PLV/ Idiomatic Inference for DSLs Reference Portland State University PLV seminar http://ozark.hendrix.edu/~yorgey/pub/PLV-idiomatic-inference.pdf https://github.com/byorgey/infer-applicative McBride and Paterson's idioms, or applicative functors, are a well-known abstraction defining function application in some ambient effectful context. It would often be useful, especially in the context of designing domain-specific languages, to infer such "idiomatic'' application, allowing the programmer to use plain function application syntax—but only when doing so is unambiguous. I will present work in progress characterizing the conditions necessary for this to be possible. 2025 10 28 http://ozark.hendrix.edu/~yorgey/forest/000S/ 000S /~yorgey/forest/000S/ Diagrams Diagrams is an embedded domain-specific language in Haskell for creating vector graphics, which I and several other contributors developed starting in 2008. Development has more or less stopped at this point, but I still keep it updated to compile with the latest versions of GHC and its dependencies. 2025 10 28 Diagrams-related talks and papers Ryan Yates Brent A. Yorgey 2015 8 30 http://ozark.hendrix.edu/~yorgey/forest/yates-yorgey-2015/ yates-yorgey-2015 /~yorgey/forest/yates-yorgey-2015/ Diagrams: A Functional EDSL for Vector Graphics Reference FARM '15: International Workshop on Functional Art, Music, Modelling and Design 10.1145/2808083.2808085 http://ozark.hendrix.edu/~yorgey/pub/diagrams-FARM.pdf https://www.youtube.com/watch?v=oAz8AEf7WDA Diagrams is a domain-specific language for creating vector graphics. We will give a short diagrams tutorial/demo, particularly highlighting the power of a functional, embedded domain-specific language. Brent A. Yorgey 2013 11 20 http://ozark.hendrix.edu/~yorgey/forest/yorgey-diagrams-NYHUG-2013/ yorgey-diagrams-NYHUG-2013 /~yorgey/forest/yorgey-diagrams-NYHUG-2013/ Diagrams: Declarative Vector Graphics in Haskell Reference New York Haskell Users' Group https://vimeo.com/84104226 https://vimeo.com/84249042 http://ozark.hendrix.edu/~yorgey/pub/13-11-25-nyhaskell-diagrams.pdf Over the past ten years, I have solved over 1700 competitive programming problems in Haskell, just for fun (as well as a few that were not fun). I will give a brief introduction to competitive programming and show off some examples demonstrating the unique benefits of Haskell in this context. We will then have a miniature programming contest, open to all—only Haskell allowed! Andy Gill Brent A. Yorgey 2013 9 28 http://ozark.hendrix.edu/~yorgey/forest/yorgey-active-2013/ yorgey-active-2013 /~yorgey/forest/yorgey-active-2013/ Functional Active Animation Reference FARM '13: International Workshop on Functional Art, Music, Modelling and Design http://www.youtube.com/watch?v=fb2K3h7t8fo Brent A. Yorgey 2012 9 13 http://ozark.hendrix.edu/~yorgey/forest/yorgey-monoids-2012/ yorgey-monoids-2012 /~yorgey/forest/yorgey-monoids-2012/ Monoids: Theme and Variations (Functional Pearl) Reference Haskell '12: Haskell Symposium 10.1145/2430532.2364520 http://ozark.hendrix.edu/~yorgey/pub/monoid-pearl.pdf http://ozark.hendrix.edu/~yorgey/pub/12-09-13-monoid-pearl-HS.pdf http://www.youtube.com/watch?v=X-8NCkD2vOw The monoid is a humble algebraic structure, at first glance even downright boring. However, there's much more to monoids than meets the eye. Using examples taken from the diagrams vector graphics framework as a case study, I demonstrate the power and beauty of monoids for library design. The paper begins with an extremely simple model of diagrams and proceeds through a series of incremental variations, all related somehow to the central theme of monoids. Along the way, I illustrate the power of compositional semantics; why you should also pay attention to the monoid's even humbler cousin, the semigroup; monoid homomorphisms; and monoid actions. Brent A. Yorgey 2012 4 13 http://ozark.hendrix.edu/~yorgey/forest/yorgey-compositional-drawing-2012/ yorgey-compositional-drawing-2012 /~yorgey/forest/yorgey-compositional-drawing-2012/ Embedded, functional, compositional drawing Reference Williams College 2025 10 28 http://ozark.hendrix.edu/~yorgey/forest/000R/ 000R /~yorgey/forest/000R/ Blog In this forest you'll find short musings and notes; I occasionally post longer-form articles at blog :: Brent -> [String]. 2025 10 25 http://ozark.hendrix.edu/~yorgey/forest/000F/ 000F /~yorgey/forest/000F/ Competitive programming I enjoy recreational competitive programming, especially in Haskell. I have solved about 2700 problems on Open Kattis, over 2000 of them in Haskell. I've written a series of blog posts about competitive programming in Haskell. I am the coach of the Hendrix College competitive programming team. 2025 10 25 Presentations on competitive programming Brent A. Yorgey 2025 6 9 http://ozark.hendrix.edu/~yorgey/forest/yorgey-zurihac-2025/ yorgey-zurihac-2025 /~yorgey/forest/yorgey-zurihac-2025/ Haskell for Competitive Programming (invited keynote) Reference ZuriHac 2025 https://www.youtube.com/watch?v=Bp_mQ62c_74 Over the past ten years, I have solved over 1700 competitive programming problems in Haskell, just for fun (as well as a few that were not fun). I will give a brief introduction to competitive programming and show off some examples demonstrating the unique benefits of Haskell in this context. We will then have a miniature programming contest, open to all—only Haskell allowed! Brent A. Yorgey 2021 9 10 http://ozark.hendrix.edu/~yorgey/forest/comprog-haskell-love/ comprog-haskell-love /~yorgey/forest/comprog-haskell-love/ Competitive Programming in Haskell Reference Haskell Love https://www.youtube.com/watch?v=pyHdHZyyYGg https://github.com/byorgey/HaskellLove21 Competitive programming is an exciting mind sport where competitors race to solve difficult programming tasks as quickly as possible, either individually or as part of a team. It requires sharp problem-solving skills, broad knowledge of algorithms and data structures, and (often) developing a good library of reusable code components ahead of time. Most serious competitive programmers use C++, but this is an arena where Haskell can shine: Haskell's strong type system helps prevent stupid mistakes made in the heat of the moment, and its capability for abstraction allows us to develop versatile libraries and solve problems using a minimum of boilerplate. In this talk, I will livecode a solution to a representative challenge, showing off techniques and libraries along the way. I will also highlight some areas needing work. In some cases, in order to fit within the time limit imposed by the creators of a problem, it is necessary to write code that runs within a small constant multiple of the time taken by a C++ solution. This is possible but difficult; the name of the game is to create libraries of algorithms and data structures that are highly optimized internally but present a flexible and idiomatic interface suitable for use in a contest. I hope that Haskellers of all skill levels will be able to take away something new, and that some will be convinced to take up a new hobby, or contribute some code! Brent A. Yorgey http://ozark.hendrix.edu/~yorgey/forest/000D/ 000D /~yorgey/forest/000D/ Publications Brent A. Yorgey Published papers Brent A. Yorgey 2025 1 17 http://ozark.hendrix.edu/~yorgey/forest/yorgey-fenwick-2025/ yorgey-fenwick-2025 /~yorgey/forest/yorgey-fenwick-2025/ You Could Have Invented Fenwick Trees (Functional Pearl) Reference Journal of Functional Programming ICFP '25: International Conference on Functional Programming 10.1017/S0956796824000169 http://ozark.hendrix.edu/~yorgey/pub/Fenwick-ext.pdf https://github.com/byorgey/fenwick http://ozark.hendrix.edu/~yorgey/pub/fenwick-ICFP.pdf https://youtu.be/jG2u1z_9_fg Fenwick trees, also known as binary indexed trees, are a clever solution to the problem of maintaining a sequence of values while allowing both updates and range queries in sublinear time. Their implementation is concise and efficient—but also somewhat baffling, consisting largely of nonobvious bitwise operations on indices. We begin with segment trees, a much more straightforward, easy-to-verify, purely functional solution to the problem, and use equational reasoning to explain the implementation of Fenwick trees as an optimized variant, making use of a Haskell EDSL for operations on infinite two's complement binary numbers. See also this blog post summary. Published as part of a special issue on program calculation. Brent A. Yorgey 2023 8 14 http://ozark.hendrix.edu/~yorgey/forest/yorgey-disco-2023/ yorgey-disco-2023 /~yorgey/forest/yorgey-disco-2023/ Disco: A Functional Programming Language for Discrete Mathematics Reference TFPIE '23: Trends in Functional Programming in Education 10.4204/EPTCS.382.4 http://ozark.hendrix.edu/~yorgey/pub/disco-tfpie23.pdf https://github.com/disco-lang/disco http://ozark.hendrix.edu/~yorgey/pub/disco-tfpie23-talk.pdf Disco is a pure, strict, statically typed functional programming language designed to be used in the setting of a discrete mathematics course. The goals of the language are to introduce students to functional programming concepts early, and to enhance their learning of mathematics by providing a computational platform for them to play with. It features mathematically-inspired notation, property-based testing, equirecursive algebraic types, subtyping, built-in list, bag, and finite set types, a REPL, and student-focused documentation. Disco is implemented in Haskell, with source code available on GitHub, and interactive web-based REPL available through replit. Brent A. Yorgey Kenny Foner 2018 7 30 http://ozark.hendrix.edu/~yorgey/forest/yorgey-foner-2018/ yorgey-foner-2018 /~yorgey/forest/yorgey-foner-2018/ What's the Difference? A Functional Pearl on Subtracting Bijections Reference ICFP '18: International Conference on Functional Programming 10.1145/3236796 http://ozark.hendrix.edu/~yorgey/pub/GCBP-author-version.pdf https://github.com/kwf/GCBP http://ozark.hendrix.edu/~yorgey/pub/GCBP-ICFP-18-slides.pdf https://www.youtube.com/watch?v=hq9gAe-pmzM It is a straightforward exercise to write a program to "add" two bijections—resulting in a bijection between two sum types, which runs the first bijection on elements from the left summand and the second bijection on the right. It is much less obvious how to "subtract" one bijection from another. This problem has been studied in the context of combinatorics, with several computational principles known for producing the "difference" of two bijections. We consider the problem from a computational and algebraic perspective, showing how to construct such bijections at a high level, avoiding pointwise reasoning or being forced to construct the forward and backward directions separately—without sacrificing performance. Satvik Chauhan Piyush P. Kurur Brent A. Yorgey 2016 9 8 http://ozark.hendrix.edu/~yorgey/forest/chauhan-kurur-yorgey-2016/ chauhan-kurur-yorgey-2016 /~yorgey/forest/chauhan-kurur-yorgey-2016/ How to Twist Pointers without Breaking Them Reference Haskell '16: Haskell Symposium 10.1145/2976002.2976004 http://ozark.hendrix.edu/~yorgey/pub/twisted.pdf Using the theory of monoids and monoid actions, we give a unified framework that handles three common pointer manipulation tasks, namely, data serialisation, deserialisation, and memory allocation. Our main theoretical contribution is the formulation of the notion of a twisted functor, a generalisation of the semi-direct product construction for monoids. We show that semi-direct products and twisted functors are particularly well suited as an abstraction for many pointer manipulation tasks. We describe the implementation of these abstractions in the context of a cryptographic library for Haskell. Twisted functors allow us to abstract all pointer arithmetic and size calculations into a few lines of code, significantly reducing the opportunities for buffer overflows. Dan Piponi Brent A. Yorgey 2015 1 1 http://ozark.hendrix.edu/~yorgey/forest/piponi-yorgey-2015/ piponi-yorgey-2015 /~yorgey/forest/piponi-yorgey-2015/ Polynomial Functors Constrained by Regular Expressions Reference MPC '15: International Conference on Mathematics of Program Construction 10.1007/978-3-319-19797-5_6 http://ozark.hendrix.edu/~yorgey/pub/type-matrices.pdf http://ozark.hendrix.edu/~yorgey/pub/type-matrices-mpc-15.pdf We show that every regular language, via some DFA which accepts it, gives rise to a homomorphism from the semiring of polynomial functors to the semiring of matrices over polynomial functors. Given some polynomial functor and a regular language, this homomorphism can be used to automatically derive a functor whose values have the same shape as those of the original functor, but whose sequences of leaf types correspond to strings in the language. The primary interest of this result lies in the fact that certain regular languages correspond to previously studied derivative-like operations on polynomial functors, which have proven useful in program construction. For example, the regular language yields the derivative of a polynomial functor, and its dissection. Using our framework, we are able to unify and lend new perspective on this previous work. For example, it turns out that dissection of polynomial functors corresponds to taking divided differences of real or complex functions, and, guided by this parallel, we show how to generalize binary dissection to -ary dissection. Brent A. Yorgey 2012 9 13 http://ozark.hendrix.edu/~yorgey/forest/yorgey-monoids-2012/ yorgey-monoids-2012 /~yorgey/forest/yorgey-monoids-2012/ Monoids: Theme and Variations (Functional Pearl) Reference Haskell '12: Haskell Symposium 10.1145/2430532.2364520 http://ozark.hendrix.edu/~yorgey/pub/monoid-pearl.pdf http://ozark.hendrix.edu/~yorgey/pub/12-09-13-monoid-pearl-HS.pdf http://www.youtube.com/watch?v=X-8NCkD2vOw The monoid is a humble algebraic structure, at first glance even downright boring. However, there's much more to monoids than meets the eye. Using examples taken from the diagrams vector graphics framework as a case study, I demonstrate the power and beauty of monoids for library design. The paper begins with an extremely simple model of diagrams and proceeds through a series of incremental variations, all related somehow to the central theme of monoids. Along the way, I illustrate the power of compositional semantics; why you should also pay attention to the monoid's even humbler cousin, the semigroup; monoid homomorphisms; and monoid actions. Brent A. Yorgey Stephanie Weirich Julien Cretin Simon Petyon Jones Dimitrios Vytiniotis José Pedro Magalhães 2012 1 28 http://ozark.hendrix.edu/~yorgey/forest/yorgey-promotion-2012/ yorgey-promotion-2012 /~yorgey/forest/yorgey-promotion-2012/ Giving Haskell a Promotion Reference TLDI '12: Workshop on Types in Language Design and Implementation 10.1145/2103786.2103795 http://ozark.hendrix.edu/~yorgey/pub/promotion.pdf Static type systems strive to be richly expressive while still being simple enough for programmers to use. We describe an experiment that enriches Haskell's kind system with two features promoted from its type system: data types and polymorphism. The new system has a very good power-to-weight ratio: it offers a significant improvement in expressiveness, but, by re-using concepts that programmers are already familiar with, the system is easy to understand and implement. Stephanie Weirich Brent A. Yorgey Tim Sheard 2011 9 19 http://ozark.hendrix.edu/~yorgey/forest/weirich-yorgey-sheard-2011/ weirich-yorgey-sheard-2011 /~yorgey/forest/weirich-yorgey-sheard-2011/ Binders Unbound Reference ICFP '11: International Conference on Functional Programming 10.1145/2034773.2034818 http://ozark.hendrix.edu/~yorgey/pub/unbound.pdf https://dl.acm.org/doi/suppl/10.1145/2034574.2034818/suppl_file/_talk6.mp4 Implementors of compilers, program refactorers, theorem provers, proof checkers, and other systems that manipulate syntax know that dealing with name binding is difficult to do well. Operations such as α-equivalence and capture-avoiding substitution seem simple, yet subtle bugs often go undetected. Furthermore, their implementations are tedious, requiring "boilerplate" code that must be updated whenever the object language definition changes. Many researchers have therefore sought to specify binding syntax declaratively, so that tools can correctly handle the details behind the scenes. This idea has been the inspiration for many new systems (such as Beluga, Delphin, FreshML, FreshOCaml, Cαml, FreshLib, and Ott) but there is still room for improvement in expressivity, simplicity and convenience. In this paper, we present a new domain-specific language, Unbound, for specifying binding structure. Our language is particularly expressive - it supports multiple atom types, pattern binders, type annotations, recursive binders, and nested binding (necessary for telescopes, a feature found in dependently-typed languages). However, our specification language is also simple, consisting of just five basic combinators. We provide a formal semantics for this language derived from a locally nameless representation and prove that it satisfies a number of desirable properties. We also present an implementation of our binding specification language as a GHC Haskell library implementing an embedded domain specific language (EDSL). By using Haskell type constructors to represent binding combinators, we implement the EDSL succinctly using datatype-generic programming. Our implementation supports a number of features necessary for practical programming, including flexibility in the treatment of user-defined types, best-effort name preservation (for error messages), and integration with Haskell's monad transformer library. Brent A. Yorgey 2010 9 30 http://ozark.hendrix.edu/~yorgey/forest/yorgey-species-2010/ yorgey-species-2010 /~yorgey/forest/yorgey-species-2010/ Species and Functors and Types, Oh My! (Functional Pearl) Reference Haskell '10: Haskell Symposium 10.1145/1863523.186354 http://ozark.hendrix.edu/~yorgey/pub/species-pearl.pdf http://vimeo.com/16753644 The theory of combinatorial species, although invented as a purely mathematical formalism to unify much of combinatorics, can also serve as a powerful and expressive language for talking about data types. With potential applications to automatic test generation, generic programming, and language design, the theory deserves to be much better known in the functional programming community. This paper aims to teach the basic theory of combinatorial species using motivation and examples from the world of functional programming. It also introduces the species library, available on Hackage, which is used to illustrate the concepts introduced and can serve as a platform for continued study and research. Brent A. Yorgey Dissertation Brent A. Yorgey 2014 10 14 http://ozark.hendrix.edu/~yorgey/forest/yorgey-species-2015/ yorgey-species-2015 /~yorgey/forest/yorgey-species-2015/ Combinatorial Species and Labelled Structures Reference Doctoral dissertation, University of Pennsylvania http://ozark.hendrix.edu/~yorgey/pub/thesis.pdf http://ozark.hendrix.edu/~yorgey/pub/yorgey-defense-slides.pdf The theory of combinatorial species was developed in the 1980s as part of the mathematical subfield of enumerative combinatorics, unifying and putting on a firmer theoretical basis a collection of techniques centered around generating functions. The theory of algebraic data types was developed, around the same time, in functional programming languages such as Hope and Miranda, and is still used today in languages such as Haskell, the ML family, and Scala. Despite their disparate origins, the two theories have striking similarities. In particular, both constitute algebraic frameworks in which to construct structures of interest. Though the similarity has not gone unnoticed, a link between combinatorial species and algebraic data types has never been systematically explored. This dissertation lays the theoretical groundwork for a precise—and, hopefully, useful—bridge bewteen the two theories. One of the key contributions is to port the theory of species from a classical, untyped set theory to a constructive type theory. This porting process is nontrivial, and involves fundamental issues related to equality and finiteness; the recently developed homotopy type theory is put to good use formalizing these issues in a satisfactory way. In conjunction with this port, species as general functor categories are considered, systematically analyzing the categorical properties necessary to define each standard species operation. Another key contribution is to clarify the role of species as labelled shapes, not containing any data, and to use the theory of analytic functors to model labelled data structures, which have both labelled shapes and data associated to the labels. Finally, some novel species variants are considered, which may prove to be of use in explicitly modelling the memory layout used to store labelled data structures. Brent A. Yorgey Books Benjamin C. Pierce Arthur Azevedo de Amorim Chris Casinghino Marco Gaboardi Michael Greenberg Cătălin Hriţcu Vilhelm Sjöberg Brent A. Yorgey http://ozark.hendrix.edu/~yorgey/forest/sf1/ sf1 /~yorgey/forest/sf1/ Software Foundations, Volume 1: Logical Foundations Reference https://softwarefoundations.cis.upenn.edu/lf-current/index.html Benjamin C. Pierce Arthur Azevedo de Amorim Chris Casinghino Marco Gaboardi Michael Greenberg Cătălin Hriţcu Vilhelm Sjöberg Andrew Tolmach Brent A. Yorgey http://ozark.hendrix.edu/~yorgey/forest/sf2/ sf2 /~yorgey/forest/sf2/ Software Foundations, Volume 2: Programming Language Foundations Reference https://softwarefoundations.cis.upenn.edu/plf-current/index.html Brent A. Yorgey Presentations Brent A. Yorgey 2025 6 9 http://ozark.hendrix.edu/~yorgey/forest/yorgey-zurihac-2025/ yorgey-zurihac-2025 /~yorgey/forest/yorgey-zurihac-2025/ Haskell for Competitive Programming (invited keynote) Reference ZuriHac 2025 https://www.youtube.com/watch?v=Bp_mQ62c_74 Over the past ten years, I have solved over 1700 competitive programming problems in Haskell, just for fun (as well as a few that were not fun). I will give a brief introduction to competitive programming and show off some examples demonstrating the unique benefits of Haskell in this context. We will then have a miniature programming contest, open to all—only Haskell allowed! Brent A. Yorgey 2025 1 30 http://ozark.hendrix.edu/~yorgey/forest/idiomatic-inference-PLV/ idiomatic-inference-PLV /~yorgey/forest/idiomatic-inference-PLV/ Idiomatic Inference for DSLs Reference Portland State University PLV seminar http://ozark.hendrix.edu/~yorgey/pub/PLV-idiomatic-inference.pdf https://github.com/byorgey/infer-applicative McBride and Paterson's idioms, or applicative functors, are a well-known abstraction defining function application in some ambient effectful context. It would often be useful, especially in the context of designing domain-specific languages, to infer such "idiomatic'' application, allowing the programmer to use plain function application syntax—but only when doing so is unambiguous. I will present work in progress characterizing the conditions necessary for this to be possible. Brent A. Yorgey 2024 9 6 http://ozark.hendrix.edu/~yorgey/forest/joy-functional-haskell/ joy-functional-haskell /~yorgey/forest/joy-functional-haskell/ The Joy of Building (Functional) Languages (invited keynote) Reference Haskell '24: Haskell Symposium http://ozark.hendrix.edu/~yorgey/pub/HS24-keynote.pdf https://github.com/byorgey/HS24-keynote https://www.youtube.com/watch?v=C8PcRqIToCM For almost as long as I can remember, all my best projects—the ones that I’m proudest of, the ones that have been the most fruitful and brought me the most joy—have all centered around building some kind of language. Perhaps I am just weird, but I think there is something uniquely joyful about not just expressing oneself, but creating a whole new means of expression for oneself and others. I will take you on a tour of some of my most interesting and joyful language-building projects (some of which you have probably heard of, some of which you definitely haven’t), and then we will build a language together! Brent A. Yorgey 2021 9 10 http://ozark.hendrix.edu/~yorgey/forest/comprog-haskell-love/ comprog-haskell-love /~yorgey/forest/comprog-haskell-love/ Competitive Programming in Haskell Reference Haskell Love https://www.youtube.com/watch?v=pyHdHZyyYGg https://github.com/byorgey/HaskellLove21 Competitive programming is an exciting mind sport where competitors race to solve difficult programming tasks as quickly as possible, either individually or as part of a team. It requires sharp problem-solving skills, broad knowledge of algorithms and data structures, and (often) developing a good library of reusable code components ahead of time. Most serious competitive programmers use C++, but this is an arena where Haskell can shine: Haskell's strong type system helps prevent stupid mistakes made in the heat of the moment, and its capability for abstraction allows us to develop versatile libraries and solve problems using a minimum of boilerplate. In this talk, I will livecode a solution to a representative challenge, showing off techniques and libraries along the way. I will also highlight some areas needing work. In some cases, in order to fit within the time limit imposed by the creators of a problem, it is necessary to write code that runs within a small constant multiple of the time taken by a C++ solution. This is possible but difficult; the name of the game is to create libraries of algorithms and data structures that are highly optimized internally but present a flexible and idiomatic interface suitable for use in a contest. I hope that Haskellers of all skill levels will be able to take away something new, and that some will be convinced to take up a new hobby, or contribute some code! Brent A. Yorgey 2018 4 6 http://ozark.hendrix.edu/~yorgey/forest/yorgey-graph-coloring-SAT-CCSC/ yorgey-graph-coloring-SAT-CCSC /~yorgey/forest/yorgey-graph-coloring-SAT-CCSC/ Graph Coloring with a SAT Solver Reference CCSC Mid-South http://ozark.hendrix.edu/~yorgey/pub/CCSC-nifty-SAT.pdf Brent A. Yorgey Richard Eisenberg Harley Eades 2018 1 13 http://ozark.hendrix.edu/~yorgey/forest/yorgey-eisenberg-eades-errors-OBT/ yorgey-eisenberg-eades-errors-OBT /~yorgey/forest/yorgey-eisenberg-eades-errors-OBT/ Explaining Type Errors Reference OBT '18: Off The Beaten Track http://ozark.hendrix.edu/~yorgey/pub/explaining-errors.pdf http://ozark.hendrix.edu/~yorgey/pub/explaining-errors-slides.pdf Every beginning student of programming—that is, every student with the ill fortune of having a language with a static type system foisted upon them by a well-intentioned yet sadistic instructor—is well-acquainted with the Dreaded Type Error Message. Why do type error messages have to be so terrifying? Can’t we do a better job explaining type errors to programmers? We propose two interrelated theses: We ought to move away from static error “messages” and towards interactive error explanations. We ought to consider the problem of generating error explanations in a more systematic, disciplined, and formal way. Explaining errors to users shouldn’t just be relegated to the status of an “engineering issue”, but ought to have all the tools of programming language theory and practice applied to it. Ryan Yates Brent A. Yorgey 2015 8 30 http://ozark.hendrix.edu/~yorgey/forest/yates-yorgey-2015/ yates-yorgey-2015 /~yorgey/forest/yates-yorgey-2015/ Diagrams: A Functional EDSL for Vector Graphics Reference FARM '15: International Workshop on Functional Art, Music, Modelling and Design 10.1145/2808083.2808085 http://ozark.hendrix.edu/~yorgey/pub/diagrams-FARM.pdf https://www.youtube.com/watch?v=oAz8AEf7WDA Diagrams is a domain-specific language for creating vector graphics. We will give a short diagrams tutorial/demo, particularly highlighting the power of a functional, embedded domain-specific language. Brent A. Yorgey 2013 11 20 http://ozark.hendrix.edu/~yorgey/forest/yorgey-diagrams-NYHUG-2013/ yorgey-diagrams-NYHUG-2013 /~yorgey/forest/yorgey-diagrams-NYHUG-2013/ Diagrams: Declarative Vector Graphics in Haskell Reference New York Haskell Users' Group https://vimeo.com/84104226 https://vimeo.com/84249042 http://ozark.hendrix.edu/~yorgey/pub/13-11-25-nyhaskell-diagrams.pdf Over the past ten years, I have solved over 1700 competitive programming problems in Haskell, just for fun (as well as a few that were not fun). I will give a brief introduction to competitive programming and show off some examples demonstrating the unique benefits of Haskell in this context. We will then have a miniature programming contest, open to all—only Haskell allowed! Brent A. Yorgey 2013 10 29 http://ozark.hendrix.edu/~yorgey/forest/yorgey-trees-semirings/ yorgey-trees-semirings /~yorgey/forest/yorgey-trees-semirings/ Trees and Things (with Semirings!) Reference Houghton College Andy Gill Brent A. Yorgey 2013 9 28 http://ozark.hendrix.edu/~yorgey/forest/yorgey-active-2013/ yorgey-active-2013 /~yorgey/forest/yorgey-active-2013/ Functional Active Animation Reference FARM '13: International Workshop on Functional Art, Music, Modelling and Design http://www.youtube.com/watch?v=fb2K3h7t8fo Brent A. Yorgey 2012 4 13 http://ozark.hendrix.edu/~yorgey/forest/yorgey-compositional-drawing-2012/ yorgey-compositional-drawing-2012 /~yorgey/forest/yorgey-compositional-drawing-2012/ Embedded, functional, compositional drawing Reference Williams College Brent A. Yorgey 2010 10 1 http://ozark.hendrix.edu/~yorgey/forest/yorgey-type-level-HIW-2010/ yorgey-type-level-HIW-2010 /~yorgey/forest/yorgey-type-level-HIW-2010/ Typed type-level programming with GHC Reference HIW '10: Haskell Implementors' Workshop http://www.vimeo.com/15480577 http://ozark.hendrix.edu/~yorgey/pub/typetype-HIW-20101001.pdf Brent A. Yorgey 2009 11 24 http://ozark.hendrix.edu/~yorgey/forest/yorgey-species-2009/ yorgey-species-2009 /~yorgey/forest/yorgey-species-2009/ Random testing—and beyond! with combinatorial species Reference University of Kansas http://ozark.hendrix.edu/~yorgey/pub/combtesting-ku-20091124.pdf Brent A. Yorgey 2008 6 8 http://ozark.hendrix.edu/~yorgey/forest/yorgey-mathematics-haskell/ yorgey-mathematics-haskell /~yorgey/forest/yorgey-mathematics-haskell/ Executable Mathematics: a Whirlwind Introduction to Haskell Reference Williams College Brent A. Yorgey 2008 3 22 http://ozark.hendrix.edu/~yorgey/forest/yorgey-xmonad-FringeDC/ yorgey-xmonad-FringeDC /~yorgey/forest/yorgey-xmonad-FringeDC/ xmonad: a Haskell Success Story Reference FringeDC http://ozark.hendrix.edu/~yorgey/pub/xmonad.pdf 2026 3 28 http://ozark.hendrix.edu/~yorgey/forest/00CH/ 00CH /~yorgey/forest/00CH/ Drafts This is a place to collect drafts, half-finished writing, and the like—really just a way for me to keep links to these things around so I don't lose track of them. You're welcome to look, but don't expect anything in particular! Draft blog post: Dr. How I Learned to Stop Worrying and Love Zero Notes on redesign of the Swarm type system ★ Classical vs constructive logic Backlinks 2025 11 2 http://ozark.hendrix.edu/~yorgey/forest/000U/ 000U /~yorgey/forest/000U/ Notes on redesign of the Swarm type system These notes are currently under construction, but I've made them public on purpose since it forces me to think things through more carefully. Comments welcome! 2025 11 2 http://ozark.hendrix.edu/~yorgey/forest/000T/ 000T /~yorgey/forest/000T/ Motivation Currently, Swarm has a relatively standard Hindley-Milner type system, with an extra requirements analysis bolted on top. The goal of the requirements analysis is to decide what capabilities (and hence what devices) are required to execute some code, and to facilitate automatically installing necessary devices on newly built robots. However, the bolted-on requirements analysis is fundamentally broken, and has led to a number of bugs. For example, see the following issues: Umbrella issue Wrong requirements for `let`-bound variables Wrong requirements context to `build` Using recursive functions doesn't require proper capabilities Making `dictionary` devices more meaningful Automatic equipment requirement checks don't work when using functions from a nested import Fundamentally, the problem is that a proper requirements analysis must be done statically (requirements analysis for programs passed to the build command are currently done dynamically, at runtime, leading to a number of bugs), and can't be separated from type analysis (e.g. to be able to deal properly with requirements of higher-order functions). The goal of this work is to design a unified type-and-requirements system that handles things properly, using the lessons learned over the past few years of struggling with the current implementation. 2025 11 3 http://ozark.hendrix.edu/~yorgey/forest/000X/ 000X /~yorgey/forest/000X/ Capabilities, entities, and devices 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001C/ 001C /~yorgey/forest/001C/ Entities Definition We assume a globally fixed set of entities . Entities represent types of objects in the game, and can be either naturally occurring (such as trees and rocks) or manufactured (such as branch predictors). 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001D/ 001D /~yorgey/forest/001D/ Capabilities Definition We also assume a globally fixed set of capabilities . A capability represents the ability of a robot to do a particular thing: for example, to add, to move, make use of recursive functions, etc. For each built-in command there is a capability which represents the capability to use command , but there are other capabilities as well. 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001E/ 001E /~yorgey/forest/001E/ Devices Definition Some entities provide one or more capabilities when they are equipped; such entities are known as devices. For example, a branch predictor device provides the capability, which allows robots to evaluate conditional expressions. 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001F/ 001F /~yorgey/forest/001F/ Devices capabilities We assume a fixed function which maps each entity to the set (possibly empty) of capabilities it provides. In a standard abuse of notation, if is a set of entities, we write to denote the image of under , that is, 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001G/ 001G /~yorgey/forest/001G/ Capabilities devices oracle Of course we can invert the function to yield a function which maps a capability to the set of entities which provide it. More interesting, however, is that we also assume the existence of a provisioning oracle which calculates a set of devices which together provide (at least) the given set of capabilities. That is, it must be the case that for any capability set , Simply defining would fit the bill, but would be unsatisfying, since its output would typically contain many redundant devices. Ideally we want some sort of "minimal" device set for a given set of capabilities. Solving this exactly is NP-hard, but there are various heuristics that can give approximate solutions. The precise algorithm used by the provisioning oracle does not matter for our purposes here; we simply assume that it exists and has the required property. 2025 11 20 http://ozark.hendrix.edu/~yorgey/forest/001Y/ 001Y /~yorgey/forest/001Y/ Capability set expressions Since types can be capability-polymorphic, it's not enough to just keep track of literal capability sets; we need to keep track of variables that can stand for unknown capability sets, which can in turn combine with other capability sets. A capability set expression can be: the empty capability set , a capability set variable , a singleton literal capability set, such as , or the union of two capability set expressions, , but quotiented by the assumption that is the identity for , and is associative, commutative and idempotent. For example, . We also write set literals like as an abbreviation for . 2025 11 4 http://ozark.hendrix.edu/~yorgey/forest/0014/ 0014 /~yorgey/forest/0014/ Robots Each robot has: an inventory, containing a number of entities, and a set of equipped devices. In order to confer capabilities, a device must be equipped, that is, moved from the robot's general inventory to the special set of equipped devices. Entities can be moved between the inventory and equipped set via the equip and unequip commands. 2025 11 14 http://ozark.hendrix.edu/~yorgey/forest/001N/ 001N /~yorgey/forest/001N/ Swarm polytypes Most generally, a Swarm polytype is of the form where is a sequence of type variables, is a sequence of capability set variables, is a capability set expression, and is a monotype. Such a type is ascribed to expressions which, under any substitutions and , can be evaluated by a robot with capabilities , producing either a value of type or (due to either an exception or nontermination). Note that in the case that there are no capability set variables , we often omit them from the syntax, writing simply as an abbreviation for . Moreover, we also omit writing in the case when is , and omit writing when there are no variables being quantified over. 2025 11 3 http://ozark.hendrix.edu/~yorgey/forest/000V/ 000V /~yorgey/forest/000V/ Swarm typing judgments Swarm has two basic typing judgments: a top-level judgment that assigns capability-annotated polytypes, and a basic judgment that assigns monotypes to terms and collects the capabilities needed to evaluate them. 2025 11 14 http://ozark.hendrix.edu/~yorgey/forest/001M/ 001M /~yorgey/forest/001M/ Top-level typing judgment Definition The top-level typing judgment is of the form which simply says that term has polytype in context . Here is a type context associating variables with their types. The polytype quantifies over type and capability variables, and contains a set of capbilities needed to evaluate the term . 2025 11 14 http://ozark.hendrix.edu/~yorgey/forest/001O/ 001O /~yorgey/forest/001O/ Monomorphic typing judgment Definition The basic typing judgment for the Swarm language has the form where is a type context, is a term, is a monotype (which could contain type variables), and is a capability set expression. This should intuitively be read as saying that has type in context , and can be evaluated given capabilities . In this judgment and are considered inputs, is considered an output, and can be either an input or an output depending on whether we are in checking or inference mode. In practice, the typing rules are implemented in an explicitly bidirectional style, but are presented here as undirected rules for simplicity. 2025 11 14 http://ozark.hendrix.edu/~yorgey/forest/001Q/ 001Q /~yorgey/forest/001Q/ Remark Note that the basic typing judgment only says something about the capabilities required to evaluate . Further use of the resulting value may require additional capabilities: for example, evaluating the application of to an argument, if it is a function; or executing , if it is a command. As a rule, the capabilities needed for such uses beyond evaluation are recorded in the type . 2025 11 14 http://ozark.hendrix.edu/~yorgey/forest/001R/ 001R /~yorgey/forest/001R/ Remark At the level of the basic typing judgment, the capability set is not part of the monotype , but rather part of the judgment. The reason is that we want to maintain the invariant that polytypes only record a single, top-level capability set, and other capability sets are recorded at appropriate points within the type (e.g. as annotations on function arrows) rather than being sprinkled on every single subterm of the type. 2025 11 14 http://ozark.hendrix.edu/~yorgey/forest/001P/ 001P /~yorgey/forest/001P/ Generalization and instantiation XXX add capability set variables and describe. Where can the different kinds of variables occur? (Hence, where do we need to apply substitutions?) 2025 11 18 http://ozark.hendrix.edu/~yorgey/forest/001T/ 001T /~yorgey/forest/001T/ Pure fragment of the Swarm language First, we go through the various types and constructs in the pure fragment of the language. Expressions in the pure fragment can be evaluated and have no side effects, in contrast to the command monad, which embeds effectful, sequenced imperative programs. Note that evaluating an expression can result in an exception being thrown or nontermination, which one might consider effects; but both of these result, semantically, in a value of . Evaluating an expression cannot have side effects in the sense of computing a value successfully while also causing extra effects. For each type or family of types, we explain typing rules for introduced and elimination forms, as well as related built-in constants. 2026 6 9 http://ozark.hendrix.edu/~yorgey/forest/00GR/ 00GR /~yorgey/forest/00GR/ Undefined There is a built-in constant , with type . Semantically, it corresponds to ; operationally, trying to evaluate causes an exception to be thrown. 2025 11 18 http://ozark.hendrix.edu/~yorgey/forest/001V/ 001V /~yorgey/forest/001V/ and Swarm has a built-in type with zero inhabitants, and a type with one inhabitant (written ). Their associated typing rules are standard, and no special capabilities are needed to use them. Note that there is no built-in eliminator for ; it is easy to implement one using undefined, as in 2026 6 10 http://ozark.hendrix.edu/~yorgey/forest/00GS/ 00GS /~yorgey/forest/00GS/ If is a type, then is a type representing delayed expressions of type . The annotation represents the capabilities needed to force evaluation of the contained expression. The delay type comes with two built-in constants, and , representing introduction and elimination forms, with typing rules as follows: The idea is that if we wrap a term in a delay, then any capabilities needed to evaluate it are put off until such time as its evaluation is forced. XXX Can and be constants, with polytypes? Or do they really need to be special syntactic forms with typing rules? 2026 6 10 http://ozark.hendrix.edu/~yorgey/forest/00GT/ 00GT /~yorgey/forest/00GT/ Remark Note that in surface syntax for Swarm, the delay type and introduction form are both written with curly braces; we choose not to use that syntax in this formal development since it could be easily confused with syntax for capability sets. 2026 6 10 http://ozark.hendrix.edu/~yorgey/forest/00GU/ 00GU /~yorgey/forest/00GU/ Functions Function type 2025 11 18 http://ozark.hendrix.edu/~yorgey/forest/001W/ 001W /~yorgey/forest/001W/ The type is standard, with values and ; no special capabilities are needed to use Boolean values themselves. The eliminator for values is a built-in function with type This says that takes a boolean value and two delayed expressions of the same type , and produces a value of type . It also tells us that evaluating the constant itself requires capability , and that evaluating its full application to a boolean and two delayed expressions requires capabilities —whatever capabilities are required to evaluate the two branches. Of course, only one of or will actually be needed, but since we can't know which until runtime, we must conservatively require their union. XXX should it just be everywhere, or etc.? Are we thinking of the capability annotation on the final arrow as being synthesized from the annotations on the two delay expressions, or are we thinking of it as an external constraint being imposed? 2025 11 18 http://ozark.hendrix.edu/~yorgey/forest/001X/ 001X /~yorgey/forest/001X/ 2025 11 3 http://ozark.hendrix.edu/~yorgey/forest/000W/ 000W /~yorgey/forest/000W/ Inventories and requirement contexts In order to be able to properly express typing rules for the command monad, we first need to develop some additional machinery. 2025 11 4 http://ozark.hendrix.edu/~yorgey/forest/0013/ 0013 /~yorgey/forest/0013/ Extended natural numbers Definition We write to denote the natural numbers extended with a special positive infinity value. Addition on satisfies for all , and is standard on . if and only if there exists such that . In other words, is standard on , and for all . Multiplication is standard on , with and for 0]]>. Under these definitions, forms a (naturally ordered) commutative semiring. 2025 11 4 http://ozark.hendrix.edu/~yorgey/forest/0012/ 0012 /~yorgey/forest/0012/ Inventories Definition An inventory is a multiset of entities, that is, a function assigning a nonnegative (possibly infinite) multiplicity to each entity. 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001H/ 001H /~yorgey/forest/001H/ Inventory union Definition We define the union of inventories, , as the inventory , the componentwise sum of inventories and . Inventories form a monoid under union, with the empty inventory as the identity element. 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001I/ 001I /~yorgey/forest/001I/ Inventory ordering Definition If and are inventories, we write to mean that for every , that is, contains at least as many copies of each entity as does. Equivalently, iff there exists an inventory such that . 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001J/ 001J /~yorgey/forest/001J/ Inventory replication Definition If and is an inventory, we define as the inventory ; that is, intuitively, consists of the union of copies of . The inventory monoid together with this action by forms a left semimodule. 2025 11 3 http://ozark.hendrix.edu/~yorgey/forest/000Z/ 000Z /~yorgey/forest/000Z/ Requirement contexts Definition A requirement context is a triple where is a set of capabilities, representing capabilities a robot should have, is a set of entities, representing devices that should be equipped, is an inventory, representing entities that a robot should possess. 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001K/ 001K /~yorgey/forest/001K/ Requirement context notation Definition We write for the empty requirement context . Also, for convenience, we sometimes write a bare set of capabilities to denote the requirement context , or a bare capability to denote ; and likewise for bare entity sets or inventories. 2025 11 3 http://ozark.hendrix.edu/~yorgey/forest/0010/ 0010 /~yorgey/forest/0010/ Requirement context satisfaction Definition A robot with equipped device set and inventory satisfies the requirement context if , , and . In other words, a robot satisfies a requirement context if its equipped devices provide at least the required capabilities, it has all the required devices equipped, and its inventory contains at least the required entity counts. 2025 11 3 http://ozark.hendrix.edu/~yorgey/forest/0011/ 0011 /~yorgey/forest/0011/ Requirement context motivation Remark It's worth discussing the motivation for each of the components of a requirement context. The capability set is used to record capabilities needed to execute certain commands, use certain language constructs, and so on. The device set is used to record specific devices required by a require directive. For example, the boat device confers the capability to traverse water, and does not correspond to a specific command or language construct, so the programmer needs a way to require it specifically. Also, since multiple devices may provide a given capability, the programmer may have reasons for requiring a specific device rather than letting the system choose. One might still wonder why we need both and ; wouldn't it be simpler to just have a set of required devices ? However, since the relationship between devices and capabilities can be many-to-many, we cannot reliably pick a concrete device for a required capability in a nicely compositional way. We prefer to wait until the last possible minute to pick a concrete set of devices to provide a given set of capabilities (using the provisioning oracle). The inventory has several purposes. One is simply to record inventory required by a stock directive. For example, stock 10 "rock" requires a robot to have 10 rocks in its inventory. More importantly, however, the build command (which constructs a robot to execute a given program) turns device requirements into inventory requirements. That is, if executing program P requires having device equipped, then executing build {P} will require possessing in the inventory (in order to equip the device on the newly constructed robot). 2025 11 5 http://ozark.hendrix.edu/~yorgey/forest/0016/ 0016 /~yorgey/forest/0016/ Requirement context union We define the union of requirement contexts componentwise, that is, where the first two unions are set union, and the last is inventory (multiset) union. 2025 11 13 http://ozark.hendrix.edu/~yorgey/forest/001L/ 001L /~yorgey/forest/001L/ Requirement context replication Definition For we can also define , where is inventory replication, and for any set we define and for 0]]>. Again, the idea is that represents the union of copies of . 2025 11 18 http://ozark.hendrix.edu/~yorgey/forest/001U/ 001U /~yorgey/forest/001U/ Swarm command monad 2025 11 2 Stuff that needs to be moved/reorganized 2025 11 3 http://ozark.hendrix.edu/~yorgey/forest/000Y/ 000Y /~yorgey/forest/000Y/ Swarm monotypes Swarm monotypes consist of: Base types such as , , , , . See the Swarm source code for a complete list, but the precise list does not matter much for this discussion. Sum types , product types , and record types , all of which are standard. Command types. The type represents commands which can be executed in requirement context and result in a value of type . Delay types. The type represents delayed expressions which, when forced, can be evaluated using the set of capabilities , resulting in a value of type . Function types. The type represents functions which, when applied to an argument of type , produce a result of type using capabilities . We use as an abbreviation for , a function which requires no capabilities to apply. Equirecursive types. The type represents the type which is the least solution to . 2025 11 9 http://ozark.hendrix.edu/~yorgey/forest/0017/ 0017 /~yorgey/forest/0017/ Swarm typing rules I will not attempt to write down a full set of typing rules here; rather, I will lay out some of the key rules, with examples. XXX typing rules for evaluating base types that require capabilities 2025 11 9 http://ozark.hendrix.edu/~yorgey/forest/0018/ 0018 /~yorgey/forest/0018/ Typing rules for built-in commands Many built-in commands have simple typing rules like the following: This says simply that is a command, and that executing it requires the corresponding capability. (Recall that writing a bare capability like where a requirement context is expected stands for the context with a singleton capability set and empty device set and inventory.) The indicates that no capabilities are required to evaluate ; it is already a value so no evaluation is required. Some built-in commands take arguments, but they typically have a similar typing rule, with no capabilities on the arrows. For example, no special capabilities are required to evaluate the application . 2025 11 9 http://ozark.hendrix.edu/~yorgey/forest/0019/ 0019 /~yorgey/forest/0019/ Typing rule for bind The basic rule for bind (aka sequencing) in the monad is as follows: This says that if is a command requring capabilities to evaluate and to execute, and which produces a value of type , and is a command requiring capabilities to evaluate and to execute, producing a value of type , then is a command requring capabilities to evaluate, to execute, and producing a . Note that this rule corresponds to a particular evaluation strategy, namely, evaluating and eagerly at the time is evaluated. If we instead wanted to wait to evaluate and at execution time, then we would need a rule like To see the difference, consider this example code: Cmd Unit = ... end def g : Dir -> Cmd Unit = ... end def example = f 3; g north end]]> When are f 3 and g north evaluated? Under the first rule above, they must be evaluated eagerly, when the definition of example is evaluated. Under the second rule above, they would be re-evaluated every time example is executed.However, we can also bind the result of in , in which case we can no longer evaluate eagerly (unless we wanted to implement partial evaluation of open terms). The rule for is therefore: 2025 11 9 http://ozark.hendrix.edu/~yorgey/forest/001A/ 001A /~yorgey/forest/001A/ Typing rules for functions The typing rule for lambdas is straightforward: Notice how the requirements for evaluating the body show up over the arrow in the result type, but are not needed to evaluate the lambda itself. We do not evaluate under lambdas, but defer evaluation of the body until evaluating an application to an argument. However, evaluating a lambda does require the special capability. Here is the typing rule for function application: The capabilities needed to evaluate the application are the union of all the capabilities needed to evaluate , to evaluate , and to evaluate the body of the function represented by , along with the special capability. 2025 11 4 http://ozark.hendrix.edu/~yorgey/forest/0015/ 0015 /~yorgey/forest/0015/ Requirements polymorphism This tree is a placeholder for discussing requirements polymorphism in depth, with examples and technical details. Related Contributions