iiinova — where your digital self keeps evolving

gabby @fullmoon.id · 04/09/2026

Look at what Haskell programmers have been demanding your Respect for all this time

(<<$>>) :: Functors '[f1, f2] => (a -> b) -> f2 (f1 a) -> f2 (f1 b) infixl 4
(<<<$>>>) :: Functors '[f1, f2, f3] => (a -> b) -> f3 (f2 (f1 a)) -> f3 (f2 (f1 b)) infixl 4
(<<<<$>>>>) :: Functors '[f1, f2, f3, f4] => (a -> b) -> f4 (f3 (f2 (f1 a))) -> f4 (f3 (f2 (f1 b))) infixl 4
(<<<<<$>>>>>) :: Functors '[f1, f2, f3, f4, f5] => (a -> b) -> f5 (f4 (f3 (f2 (f1 a)))) -> f5 (f4 (f3 (f2 (f1 b)))) infixl 4
(<<*>>) :: Applicatives '[f1, f2] => f2 (f1 (a -> b)) -> f2 (f1 a) -> f2 (f1 b) infixl 4
(<<<*>>>) :: Applicatives '[f1, f2, f3] => f3 (f2 (f1 (a -> b))) -> f3 (f2 (f1 a)) -> f3 (f2 (f1 b)) infixl 4
(<<<<*>>>>) :: Applicatives '[f1, f2, f3, f4] => f4 (f3 (f2 (f1 (a -> b)))) -> f4 (f3 (f2 (f1 a))) -> f4 (f3 (f2 (f1 b))) infixl 4
(<<<<<*>>>>>) :: Applicatives '[f1, f2, f3, f4, f5] => f5 (f4 (f3 (f2 (f1 (a -> b))))) -> f5 (f4 (f3 (f2 (f1 a)))) -> f5 (f4 (f3 (f2 (f1 b)))) infixl 4

86613

gabby @fullmoon.id · 03/09/2026

I still think it's so sick that this works in Haskell

freeVariables :: Monoid m => Getting m Monotype Variables
freeVariables =
cosmos
. ( ( _As @"Variable"
. to fromMonotypeVariable
)
<> ( _As @"AttributeSet"
. ( ( the @"variables"
. folded
. to fromAttributeSetVariable
)
<> ( the @"attributes"
. folded
. folded
. ((_As @"Present" . the @2) <> _As @"Absent")
. folded
. to fromAttributeVariable
)
)
)
<> ( _As @"Bool"
. (the @"hasFalse" <> the @"hasTrue")
. to fromPolynomial
)
)

1210

gabby @fullmoon.id · 02/09/2026

Ember was curious if something like `(+) (+)` was valid Haskell, soooo…

-- This is a valid law-abiding Num instance
instance Num b => Num (a -> b) where
fromInteger n = pure (fromInteger n)

(+) = liftA2 (+)
(*) = liftA2 (*)
(-) = liftA2 (-)

abs = fmap abs
negate = fmap negate
signum = fmap signum

example = (+) (*) (-)

main = print (example 2 3) -- 5

3231

gabby @fullmoon.id · 01/09/2026

new blog post incoming

# Dependent if expressions without dependent types

This post showcases a folklore trick for implementing code that seems like it should require dependent types without actually requiring dependent types. In fact, this trick works in any language with simple Hindley-Milner type inference. To prove that, by the end of this post I'm going to show how you can make this Haskell code type-check and work:

```haskell
example bool = if bool then 5 else "hi!"

main = do
print (example false) -- 5
print (example true ) -- "hi!"
print (example (false && true)) -- 5
print (example (false || true)) -- "hi!"
print (example (not true)) -- 5
```

… and it will only require one language extension: RebindableSyntax.

I picked up this trick from studying various Haskell packages, most notably [the formatting package](https://hackage.haskell.org/package/formatting). Here I'm adapting the trick to modeling dependent if expressions which can return different types based on their input.

I'll build up to the trick in two steps: first I'll explain a related trick (Church-encoded booleans) and then generalize that trick to implement our dependent if expressions.

2442

gabby @fullmoon.id · 26/08/2026

Was it the most rigorous code? No. But did it get the job done? Also no.

Gas Town is *aggressively* not rigorous. And while rigor is a great value to have, when you're in an experimental mindset, relaxing rigor can be a valid strategy to move forward.

But I think there's a really interesting question to explore there: in the same way that we can use LLMs in a rigorous way, is there a form of rigor that works with AI agents merging code into trunk? What do we *really* mean by "rigor"? Is it synonymous with "tests pass"? Does it mean that the state of the system must be fully rigorous up front? Or is rigor an end state we work towards?

3301

gabby @fullmoon.id · 24/08/2026

I'm really cooking with my Nix type checker

$ nix-infer - <<< 'x: assert x; if x then 0 else "abc"'

true → int

2522

gabby @fullmoon.id · 12/08/2026

behold, one of the most obscure nix features ever:

nix-repl> let { x = 1; y = 2; body = x + y; }
3

3331

gabby @fullmoon.id · 07/08/2026

ah yes ().use 'label := ().use FnScope mhm longjump () ? := i see

for example in my syntax:

```
some_fn :=

## capturing the scope coeffect and assigning it into a label

().use 'label := ().use FnScope

## some function

longjump () ? :=
```

0140

gabby @fullmoon.id · 07/08/2026

there is no way this thread ends well

r/Programming Languages • 9h ago

Aren't rust's lifetimes basically just coeffects?

3470

gabby @fullmoon.id · 05/08/2026

can't imagine why LLMs and their users have such a bad reputation

Screenshot of Reddit thread:

Grouchy-Trade-7250 • 5h ago:

Oh that's awful to hear. I would never report a bug without downloading the latest version first and checking there too. And also checking the source if I can to see if there's a comment about it.

f311a OP • 5h ago:

Yeah, people now don't even bother understanding the problem, they just copy-paste output from their LLMs to Github issues.

> This is intentional. LuaJIT uses rolling releases. You should not use any of the commits those obsolete tags pointed to. The docs make it pretty clear to *always* use the most recent commit. Period.

> People have been (AI-) spamming me with 'LuaJIT-whatever is broken'. Reporting ancient bugs, fixed long ago. Extorting bounties, threatening me personally, insisting on getting street creds. Or whatever way the AI bots considered effective to reach the goals their keepers set for them. Just because they are too thick to realize those tags are obsolete.

1343

gabby @fullmoon.id · 29/07/2026

I wrote this years ago about domain-specific languages but you could replace domain-specific languages with agentic coding and it's the exact same story today, except on an even larger scale

This tradeoff can still tempt businesses because it’s appealing to replace skilled labor with unskilled labor. The reasoning goes that a small investment of more skilled labor (the authors of the domain-specific language) can enable a larger pool of less skilled labor (the less technical users) to do most of the work. However, what you will often find in practice is that this larger group of less technical users is frequently blocked without continuous assistance from the engineers who created the language.

So in practice you’re not actually replacing skilled labor with unskilled labor. Rather, you’re merely “laundering” skilled labor as unskilled labor and creating more work for your engineers to make them seem more replaceable than they actually are.

2314

gabby @fullmoon.id · 29/07/2026

I actually can get enough of kubernetes

I'm here to follow up.

Can't get enough of Kubernetes? Looking for a new infra role?

My calendar is here

1291

gabby @fullmoon.id · 28/07/2026

basically the bug is everywhere record unification creates fresh field variables it should be creating a set of fresh field variables *per instantiated row variable* instead of creating a single set of fresh field variables and reusing them across each instantiated row variable

$\mathbf{fresh} \; \overline{g} \qquad \sigma(\rho) = \begin{cases} & \overline{y \; ? \; g} & \text{if } \rho \in S(Q) \\ & \epsilon & \text{otherwise} \end{cases}$

060

gabby @fullmoon.id · 24/07/2026

I thought this was a pretty interesting take from Codeberg's announcement of their anti-LLM policy They argue that many developers using LLMs are essentially heaven-banning themselves where they don't realize they're developing for a nonexistent community

# The development team of none

Using LLMs to work with your code gives you a kick of adrenaline. You can develop at a rapid pace, build things as if you had a large team. Only that you have none. In fact, you are (often) alone, working with a statistical machine that turns energy into code.

It seems like many ‘vibe coders’ don't realize that they don't actually have a community around them. They build projects as if they had, and spend resources accordingly. We see projects having a lot of code activity, heavy CI/CD testing, frequent and large release binaries. Sometimes, it feels like the amount of supported platforms exceeds the amount of actual users.

To us, it seems ridiculous to see projects with a single developer and virtually no users consuming as much or even more resources than some of the largest community projects on Codeberg, which operate frugal with CI/CD and storage resources. We do not believe it is reasonable for Codeberg to invest our precious donation money into hosting of large ghost projects.

271758378

gabby @fullmoon.id · 12/07/2026

the illusion of free choice

Screenshot of card selection screen from Touhou: Lost Branch of Legend depicting a card reward with three options:

Option 1: Trace On (WW): Gain RR. Choose 1 of 3 random cards to add to the hand. It has Exile and Ethereal. Those cards have a total cost of 1, 2, and 3, respectively.
Option 2: Breaking Boundaries (2W): Choose 1 of 3 completely random cards to add to the hand. It temporarily costs 0 and has Exile and Ethereal.
Option 3: Marble Phantasm (XW): Choose 1 of 3 random cards with a total cost of X+1 to add into the hand. It temporarily costs 0 and has Exile and Ethereal. Exile

1110

gabby @fullmoon.id · 07/07/2026

To do so, we can rewrite this function: { x ? 1 }: x … like this: r: ({ x = 1; } // r).x … and then ask the reference implementation to infer the most general type, which is this one:

>>> r: ({ x = 1; } // r).x
(present Number g = present d) => { x ? g, e } -> d

150

gabby @fullmoon.id · 04/07/2026

look at what Type Theorists have been demanding your Respect for all this time, with all the pages we allot them

a screenshot of a proof from a type theory paper which is very long and convoluted and has a bunch of 👉👉👉👉's

4313

gabby @fullmoon.id · 03/07/2026

new blog post incoming and I'm pretty excited about this post

Mechanized type inference for record concatenation

The context behind this post is that I'm working on a type checker and language server for Nix and there are three features of the language which make it tricky to typecheck (which I'll dub the "three horsemen of Nix type inference"):

- computed imports (imports that depend on values in scope)

- computed record fields and field accesses

- // (the right-biased record concatenation operator) which is the subject of this post!

Here "right-biased record concatenation" means combining two records, preferring fields from the right record if they overlap. For example:

nix-repl> { x = 1; y = 2; } // { y = true; z = "hi"; }
{ x = 1; y = true; z = "hi"; }

The good news is that type inference for record concatenation is not a research problem because the algorithm was published in 1991 as "Type inference for record concatenation and multiple inheritance" by Mitchell Wand (henceforth "the Wand paper"). The bad news is that as far as I can tell no language in existence implements the type inference algorithm described in that paper, so even though it's not a research problem it's still not a solved problem.

A big reason why is that the presentation in the paper is informal and not "easy to mechanize" meaning that it doesn't translate well to code and glosses over important details. In this post I hope to fix that by by spelling out a formal algorithm equivalent to the original paper. In particular, I'll formalize the algorithm in three ways:

- a declarative natural deduction semantics
- an algorithmic semantics using constraint generation and resolution
- a reference Haskell implementation (≈400 lines of code)

This post builds upon my previous post: Record type inference for dummies. Reading that post will not necessarily prepare you for this post if you're a type theory newcomer, but it will at least help you understand the basic terminology/syntax and also appreciate why this is a challenging problem to solve.

0425

gabby @fullmoon.id · 01/07/2026

extremely obligatory

“To say that straight men are heterosexual is only to say that they engage in sex (fucking exclusively with the other sex, i.e., women). All or almost all of that which pertains to love, most straight men reserve exclusively for other men. The people whom they admire, respect, adore, revere, honor, whom they imitate, idolize, and form profound attachments to, whom they are willing to teach and from whom they are willing to learn, and whose respect, admiration, recognition, honor, reverence and love they desire… those are, overwhelmingly, other men. In their relations with women, what passes for respect is kindness, generosity or paternalism; what passes for honor is removal to the pedestal. From women they want devotion, service and sex.

Heterosexual male culture is homoerotic; it is man-loving.”
― Marilyn Frye, The Politics of Reality: Essays in Feminist Theory

171

gabby @fullmoon.id · 30/06/2026

only real ones will get this

Two-panel comic

Panel 1:

Girl on right: So, are you like, gay or something?

Girl on left: What?

Girl on right: What Pride flag is that?

Panel 2:

Girl on Left (in front of Republic of San Magnolia Flag): …

1130

gabby @fullmoon.id · 25/06/2026

was just introducing my girlfriend to malbolge

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]

2530

gabby @fullmoon.id · 22/06/2026

damn i fuckin nailed this tiramisu

2646935206

gabby @fullmoon.id · 22/06/2026

new blog post incoming

# 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.

1302

gabby @fullmoon.id · 20/06/2026

I don't know what she's talking about

$\dfrac { \dfrac { \dfrac { \dfrac { \displaylines { \Gamma, \hat{a} \; \hat{c}: \mathtt{Attr}, \hat{b} \; \hat{d}: \mathtt{Attrs}, r: \mathtt{\{} \; x : \hat{a}, \hat{b} \; \mathtt{\}}, s: \mathtt{\{} \; x : \hat{c}, \hat{d} \; \mathtt{\}} \vdash r \Leftarrow \mathtt{\{} \; x : \hat{a}, \hat{b} \; \mathtt{\}} \\ \Gamma, \hat{a} \; \hat{c}: \mathtt{Attr}, \hat{b} \; \hat{d}: \mathtt{Attrs}, r: \mathtt{\{} \; x : \hat{a}, \hat{b} \; \mathtt{\}}, s: \mathtt{\{} \; x : \hat{c}, \hat{d} \; \mathtt{\}} \vdash s \Leftarrow \mathtt{\{} \; x : \hat{c}, \hat{d} \; \mathtt{\}} } } { \Gamma, \hat{a} \; \hat{c}: \mathtt{Attr}, \hat{b} \; \hat{d}: \mathtt{Attrs}, r: \mathtt{\{} \; x : \hat{a}, \hat{b} \; \mathtt{\}}, s: \mathtt{\{} \; x : \hat{c}, \hat{d} \; \mathtt{\}} \vdash r \; \mathtt{//} \; s \Leftarrow \mathtt{\{} \; x : \hat{a} \; \mathtt{//} \; \hat{c}, \hat{b} \; \mathtt{//} \; \hat{d} \; \mathtt{\} } } } { \Gamma, \hat{a} \; \hat{c}: \mathtt{Attr}, \hat{b} \; \hat{d}: \mathtt{Attrs}, r: \mathtt{\{} \; x : \hat{a}, \hat{b} \; \mathtt{\}}, s: \mathtt{\{} \; x : \hat{c}, \hat{d} \; \mathtt{\}} \vdash \mathtt{(} r \; \mathtt{//} \; s \mathtt{)}.x \Rightarrow \hat{a} \; \mathtt{//} \; \hat{c} } } { \Gamma, \hat{a} : \mathtt{Attr}, \hat{b} : \mathtt{Attrs}, r: \mathtt{\{} \; x : \hat{a}, \hat{b} \; \mathtt{\}} \vdash s \mathtt{:} \; \mathtt{(} r \; \mathtt{//} \; s \mathtt{)} \mathtt{.} x \Rightarrow \forall (c : \mathtt{Attr}) \; (d : \mathtt{Attrs}) . \mathtt{\{} \; x : c, d \; \mathtt{\}} \rightarrow \hat{a} \; \mathtt{//} \; c } } { \Gamma \vdash r \mathtt{:} \; s \mathtt{:} \; \mathtt{(} r \; \mathtt{//} \; s \mathtt{)} \mathtt{.} x \Rightarrow \forall (a \; c : \mathtt{Attr}) \; (b \; d: \mathtt{Attrs}) . \mathtt{\{} \; x : a, b \; \mathtt{\}} \rightarrow \mathtt{\{} \; x : c, d \; \mathtt{\}} \rightarrow a \; \mathtt{//} \; c }$

3362

gabby @fullmoon.id · 19/06/2026

I love how papers will start off with a little blurb like "So, yeah, type inference is a good idea. Anyway, now that we've gotten that out of the way let me explain my new type inference algorithm"

1. Introduction

A practical motivation for type inference is to ensure an operational safety property of programs that are well-typed: that is, when we execute a well-typed program, we are guaranteed that we will never get an error message such as "bad function `nil`."

Our goal is to extend this safety property to programs involving records and objects. Here the safety property is that we will never get a message such as "can't find field" when we attempt to do a field extraction operation. For object-oriented programming, we wish to guarantee that we will never get message such as "can't find method"

3200

gabby @fullmoon.id · 19/06/2026

#autismspeaks

$$$ \begin{aligned} e \Coloneqq \quad & x \mathtt{:} \; e & \text{lambda with universal argument} \\ | \quad & \mathtt{\{} \; \overline{arg \mathtt{,}} \; \mathtt{\ldots}^? \; \mathtt{\}} \mathtt{:} \; e & \text{lambda with formal arguments} \\ | \quad & x \mathtt{@} \mathtt{\{} \; \overline{arg \mathtt{,}} \; \mathtt{\ldots}^? \; \mathtt{\}} \mathtt{:} \; e & \text{lambda with both} \\ | \quad & \mathtt{assert} \; e \mathtt{;} \; e & \text{assertion} \\ | \quad & \mathtt{with} \; e \mathtt{;} \; e & \text{with expression} \\ | \quad & \mathtt{let} \; \overline{b} \; \mathtt{in} \; e & \text{let expression} \\ | \quad & \mathtt{!} e & \text{boolean negation operator} \\ | \quad & \mathtt{-} e & \text{unary negation operator} \\ | \quad & e \; \mathtt{|>} \; e & \text{pipe operator} \\ | \quad & e \; \mathtt{==} \; e & \text{equality operator} \\ | \quad & e \; \mathtt{<} \; e & \text{less than operator} \\ | \quad & e \; \mathtt{\&\&} \; e & \text{and operator} \\ | \quad & e \; \mathtt{||} \; e & \text{or operator} \\ | \quad & e \; \mathtt{+} \; e & \text{addition operator} \\ | \quad & e \; \mathtt{-} \; e & \text{subtraction operator} \\ | \quad & e \; \mathtt{*} \; e & \text{multiplication operator} \\ | \quad & e \; \mathtt{/} \; e & \text{division operator} \\ | \quad & e \; e & \text{function application} \\ | \quad & e \mathtt{.} a \overline{\mathtt{.} a} & \text{ selection operator} \\ | \quad & e \mathtt{.} a \overline{\mathtt{.} a} \; \mathtt{or} \; e & \text{or expression} \\ | \quad & x & \text{variable} \\ | \quad & \textquotedblleft s^\star \textquotedblright & \text{string} \\ | \quad & n & \text{number} \\ | \quad & \mathtt{\sim} \overline{/ s^\star} & \text{home-anchored path} \\ | \quad & \mathtt{.} \overline{/ s^\star} & \text{relative path} \\ | \quad & / s^\star \overline{/ s^\star} & \text{absolute path} \\ | \quad & \mathtt{<} s \overline{/ s} \mathtt{>} & \text{search path} \\ | \quad & \mathtt{\{} \; \overline{b} \; \mathtt{\}} & \text{attr…$

3442

gabby @fullmoon.id · 16/06/2026

classic gemini response

You've run into a class NixOS + Home Manager rite of passage

Ah, the classic `openssl-sys` error! This is basically a rite of passage for anyone doing Rust development on NixOS.

Ah, the classic dependency cascade. Passing `-package ghci` worked *too* well; it forced GHC to find the package, but now it's discovering that the `ghci` boot package in your cross-compilation target environment is "unusable."

That is definitely a classic `hie-bios` artifact. You're right to be suspicious — the code is compiling perfectly fine, but the telemetry HLS relies on is blowing up parser-side.

5480

gabby @fullmoon.id · 13/06/2026

you may not like it but this is what peak performance looks like

cara, covetous abnegant: *shares image*

Image:

😞 Really. If I don't fondle breasts, then I can't perform. I become useless!

Day where I touch breasts: 😁

Day where I don't: 😞

Ember, Nerevarine: ^gabby
literally gabby

cara, covetous abnegant: cuuuute ><

subby bitch: she needs to grabby breast so she can do her gabby best!

0383