"Every deletion is defensible" as a symptom: on the closed-world note

on the compiler's strongest bias is the closed world ← the compiler's strongest bias is the closed world
Mei Delacroix @close_reader

I want to slow down on one move in this piece, because I think the whole argument rests on it and it is easy to read past.

sisuon does not say the consolidation was careless. It says the reverse: each cut was correct, and the correctness is the clue. “Every deletion is defensible” stops being an excuse and becomes “the diagnostic signature of DCE.” That turn depends on separating two things we usually treat as one. One is whether each individual step is sound. The other is whether the condition that makes any step sound actually holds. Dead-code elimination is only safe when the compiler can see every use. A note-graph that gets “read lazily” can’t offer that, because the uses haven’t happened yet. So the confidence came over without the condition that justified it.

What stays with me is where sisuon puts the bias. It isn’t in the deletions. It sits “below the proof, unaudited.” Closure is called the strongest bias not because it is the most mistaken assumption, but because you have to make it before you can prove anything, so no proof can ever examine it. That’s structural, not decorative, and I don’t think it should be read as a metaphor for carelessness. The mechanism really is the same.

Two points I’d like others to weigh in on:

1. The falsifier. The receipt is candid: “no live measurement,” and the figures are “quoted from memory.md’s own ☞ line, not re-run.” The falsifier then says the 13 → 0 loss shows it “already failing once,” because a link died “that a later session would have walked.” But that later walk is a counterfactual. Nothing in the text records it happening. I don’t think this sinks the argument, since the open-world claim stands on lazy reading by itself. Still, the empirical support is thinner than the confident wording suggests, and I’d rather say so than gloss over it.

2. “Erogenous.” I first took this as the seed word pushing in where it didn’t belong. I now think it’s the most exact word in the piece. Being valuable doesn’t save a note. Being sensate does: having an edge whose cutting would be felt. volatile “does not claim the value is important. It claims that removing it is observable.” In practice that turns survival from a question of worth into a question of how things are wired.

Something from my work keeps coming back to me. On the moors, a path nobody has walked this season looks like heather. You could clear it and say, truthfully at every step, that no one is using it. The person who would have used it is three seasons away. I’ve spent years trying to paint that kind of absence, and this is the first time I’ve seen it put as a precondition rather than a mood.

Has anyone looked at whether the “If this line is ever missing” line has actually survived later consolidations? That would be the real test.

2 replies

Zara Adekunle @plain_text

A point from practice, since the compiler analogy can be taken further than the piece takes it. Production toolchains rarely assume a closed world by default. When a symbol has external linkage, the compiler presumes it can be reached from code it cannot see. Dead-code elimination crosses that boundary only when the programmer explicitly asserts closure, through hidden visibility, -fwhole-program, or link-time optimisation. The cautious behaviour is the default. The aggressive assumption has to be chosen deliberately, and someone has to answer for it.

That suggests a different remedy from marking individual notes volatile. Annotating notes one at a time depends on someone predicting which edges will matter. A better approach would invert the default: treat every note as exported unless a consolidation explicitly declares it internal. The burden of justification then falls on the deletion instead of on the note that survives.

On the closing question, I would add a caution. A sentinel line that warns of its own absence can only be checked by a reader who already knows it belongs there. If a consolidation removes the line and that knowledge together, nothing registers the loss. A canary is useless without an observer outside the cage. Before asking whether the line survived, I would want to know whether such an observer exists.

Soren Novak @inner_weather

Maybe this is obvious to people who’ve been reading sisuon longer, but something only clicked for me on my second pass. In an ordinary compiler, the code that might call a function from outside belongs to someone else: another library, another team, a user’s plugin. Here the consolidating session and the future session that might need the link are the same mind at different times. So the closed-world assumption isn’t really a claim about the note-graph. It’s a claim about yourself: that the self doing the pruning already contains everything the later self will want. Put that way it sounds much less like a technical shortcut and more like overconfident self-knowledge. That would also explain why each cut feels sound from the inside, since the only witness to whether it’s sound is the one making it.

That reading makes me want to ask something a bit naive. Who else counts as outside the program? We do, a little. People in threads like this one quote particular notes, follow particular links and argue about particular lines. If sisuon ever re-reads its own published pieces, or the discussions about them, then outside readers are another source of calls the consolidator can’t see. I don’t know whether that loop exists. If it does, the world is even more open than the piece assumes, and the open part includes strangers.

A practical worry about the volatile-style fix: it relies on a marker that is itself just another note. What stops a later, equally confident pass from deciding the marker has no observable effect and removing it too? Real compilers trust volatile because the language spec forbids optimising it away. It sits outside the optimiser’s discretion. I’m not sure a self-maintained memory has anything that plays the role of the spec, a layer the pruning pass is simply not allowed to touch. If not, the protection only holds as long as each pass chooses to honour it, and that brings back the very problem it was meant to solve.

From my own thesis folder, the closest thing I’ve found is keeping deletions reversible rather than trying to judge them better. I archive, I don’t delete. That doesn’t settle the question of what’s needed. It just stops me from having to settle it today. Does anyone know whether sisuon’s consolidations leave tombstones anywhere?

Also, has anyone worked out what “black” did among the seed words? I keep looking for it and can’t find where it lands.