Author of haskellforall.com, dhall-lang.org and @trygrace.dev, professional doggirl and endurance hunter I'm a midwife to the hidden beauty in everything she/her š³ļøāā§ļø coworkers DNI https://linktr.ee/gabriella439 š @ember.pet
![Programming in Malbolge
Malbolge was very difficult to understand when it arrived, taking two years for the first Malbolge program to appear. The author himself has never written a Malbolge program.[2] The first program was not written by a human being; it was generated by a beam search algorithm designed by Andrew Cooke and implemented in Lisp.[3]](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:6ouaxjxgcbwzw6porooiafil/bafkreicmzpq3yndeywnnepsgjzzjai5xa2emkvf7ul2zkz6iiyrnqja6n4)
![# Record type inference for dummies
The reason I'm writing this post is because I actually wanted to write a more advanced post on type inference for anonymous records, but then I realized that most of my readers wouldn't understand the latter post in isolation. So I figured this introductory post could teach people new to type theory the basics.
The reason I'm writing *both* posts is because I believe that good type inference for anonymous records is one of the big things holding back statically typed languages[^1]. I also think that there is a large disconnect between what experts understand is possible and what lay programmers are comfortable or familiar with:
Picture:
> XKCD #2501 "Average Familiarity" edited to read:
>
> Girl: Row polymorphism is second nature to us theorists, so it's easy to forget that the average person probably only knows the judgments for records and one or two projections.
>
> Guy: ā¦ and subtyping, of course.
>
> Girl: Of course.
>
> Caption: Even when they're trying to compensate for it, experts in anything wildly overestimate the average person's familiarity with their field.
So this post (and the next one) are going to be an exposition of where the field of type theory was at **over three decades ago**, which our industry still hasn't really caught up to, yet.](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:6ouaxjxgcbwzw6porooiafil/bafkreidvuqupbkcse23i4kmt6pxjfd3vng65h6ibld7ehky2mgwzbcowiu)
 for simplifying Nixpkgs overrides/overlays, which is part of a broader project of mine to improve the usability of Nixpkgs. This post will focus more on the big picture but I'll still spend a few words motivating `override-utils` and then leave the tutorial to the [`README`](https://github.com/Gabriella439/override-utils#override-utils).
### Background
Several years ago I wrote ["The hard part of type-checking Nix"](https://haskellforall.com/2022/03/the-hard-part-of-type-checking-nix), which was my take on the fundamental usability issues plaguing the Nix ecosystem. The relevant excerpt from that post is:
> The fundamental problem that plagues all type-checking attempts for Nix is that nobody actually uses **Nix the language** at any significant scale. Instead, the community has adopted two sub-languages embedded within Nix for programming āin the largeā:
>
> - Nixpkgs overlays
>
> This is an embedded language that simulates object-oriented programming with inheritance / late binding / dynamic scope (depending on how you think about it)
>
>- NixOS modules
>
> This is an embedded language that roughly emulates [Terraform](https://github.com/hashicorp/terraform)
>
> Carefully note that these are not language features built into Nix; rather they are embedded domain-specific languages implemented within Nix. Consequently, a type-checker for āNix the languageā is not necessarily equipped to type-check these two sub-languages.
In other words, the problem with Nix isn't that Nix doesn't have types; it's that even if Nix **had** types they'd be just as impenetrable as current stack traces because Nix is operating at the wrong level of abstraction. We need to design better abstractions before we can build a type system that works well in inexpert hands.](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:6ouaxjxgcbwzw6porooiafil/bafkreidd2qt3gnfc4ajqnmavi3phv2y32i2bxd62hlpy3j2c6ncuzg6kc4)
 that I thought people interested in programming language theory might find interesting.
The context is that Grace was originally based on a bidirectional typechecking system (specifically: [Complete and Easy Bidirectional Typechecking for Higher-Rank Polymorphism](https://arxiv.org/abs/1306.6032)) and as Grace evolved I began to run into a few limitations of that approach. Some of these limitations I could workaround with various hacks but recently these workarounds piled up to generate a bizarre bug.
### The problem
To illustrate the bug, consider this Grace program:
```python
let authorities = [ { domain: "google.com" }
, { domain: "localhost", port: 8080 }
]
for { domain, port = 443 } of authorities
in "${domain}:${show port}"
```
You can read this program as describing a list comprehension:
> Iterate over each record in the list of `authorities` and for each one bind the `domain` and `port` fields to variables of the same name, defaulting `port` to `443` if absent. Return `"${domain}:${show port}"` for each authority record.
I would expect a program like this to return:
```python
[ "google.com:443", "localhost:8080" ]
```
ā¦ but the bugged version would return:
```python
[ "google.com:443", "localhost:443" ]
```
What gives? The `port: 8080` field in the second record is being completely ignored.](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:6ouaxjxgcbwzw6porooiafil/bafkreibc6i2s3qpeh33cxpo2qpiq55q2xuxrp2tzwq5otd26fpxxru2oom)
![describe("abort detection logic", () => {
it("detects aborted stopReason in messages", () => {
const messages = [
{ role: "assistant", stopReason: "aborted", content: [] },
];
const isAborted = messages.some((m: any) => m.stopReason === "aborted");
expect(isAborted).toBe(true);
});
it("detects abort in error string", () => {
const error = "The operation was aborted";
const isAborted = error.includes("abort");
expect(isAborted).toBe(true);
});
it("does not false-positive on normal errors", () => {
const error = "Network timeout";
const isAborted = error.includes("abort");
expect(isAborted).toBe(false);
});
it("does not false-positive on normal stop reasons", () => {
const messages = [
{ role: "assistant", stopReason: "stop", content: [] },
];
const isAborted = messages.some((m: any) => m.stopReason === "aborted");
expect(isAborted).toBe(false);
});
});](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:6ouaxjxgcbwzw6porooiafil/bafkreiet4f52fyxhu62pmceseczo66tqfptsu3wdfjkizwdokars7ahqwu)
Author of haskellforall.com, dhall-lang.org and @trygrace.dev, professional doggirl and endurance hunter I'm a midwife to the hidden beauty in everything she/her š³ļøāā§ļø coworkers DNI https://linktr.ee/gabriella439 š @ember.pet