> Chess is a lot trickier than it looks. It has so many rules: castling, en passant, pawn promotion, pinning, the discovered check, and the deadlock case of stalemate.
Nit: Pinning and the discovered check are not really rules, but rather names of tactics.
JohnKemeny 2 hours ago [-]
Well, if a piece is pinned it's illegal to move it.
Rule 3.9.2: No piece can be moved that will either expose the king of the same colour to check or leave that king in check.
gobdovan 1 hours ago [-]
You can also pin a pawn to a queen, but the pawn can still legally move.
HiroProtagonist 5 minutes ago [-]
You're both right, depending on whether you mean relative pin vs absolute pin.
TheOtherHobbes 1 hours ago [-]
Unlike en-passant and castling, pinning and discovered checks are consequences of lower-level rules.
At the "Is this move legal?" level, they don't need unique rules of its own if the lower-level rules are specified correctly.
JohnKemeny 1 hours ago [-]
3.9.2: no piece can be moved if that exposes or leaves its own king in check.
333c 45 minutes ago [-]
That's a consequence of not being allowed to put yourself in check (by any means).
munchler 48 minutes ago [-]
The point is that, logically, the first part of that rule (“expose the king”) is implied by the second part (“leave that king”), so the first part is redundant. You could simplify the rule to:
No piece can be moved that will leave the king of the same color in check.
juujian 1 hours ago [-]
And discovered check means that it is not sufficient to check the position of the piece you have moved, you also need to check the position of other pieces to see whether there is a new check.
duesabati 10 minutes ago [-]
While I think everything written in this post is correct, what really is starting bothering me is this over-focus/attention on data even when what you want to express is behavior, let me explain:
The post talks about "transition invariants" that should be somehow different from "state invariants" yet it describe them as:
> These are predicates over a <<state, next-state>> pair ...
i.e. it still is about state, but I find it much more useful to focus on behavior so instead of thinking about how state transition you focus on what the program is allowed to perform, regardless of the underlying data structure.
What I mean is that I'd like the code to tell me why a certain piece can't do such move instead of why it cannot transition it's position to another position and basically dumping its state in my head and there I have to execute the program myself.
NicoHartmann 1 hours ago [-]
I can't wait to show this to my manager next time he asks why it's taking three weeks to build a simple CRUD app.
"Look, if this guys TLA+ logic struggles to model a 1,500-year-old game without crying over a French pawn-capture rule, you can't expect me to integrate Stripe billing without a few state invariant violations."
epolanski 17 minutes ago [-]
Payments have a gargantuan amount of possible transitions and invariants that are far from trivial to encode.
rauljara 26 minutes ago [-]
Anyone know what language is being used in the blogpost?
phoe-krk 18 minutes ago [-]
Screenshots of code? In 2026?...
vintermann 32 minutes ago [-]
That king promotion rule sounds like it made the game more fun.
https://neuroning.com/boardgames-exercise/notebooks/walkthro...
The implementation makes it really easy to add new piece types or rules. For example, here's the full logic for rooks (sans castling):
Nit: Pinning and the discovered check are not really rules, but rather names of tactics.
Rule 3.9.2: No piece can be moved that will either expose the king of the same colour to check or leave that king in check.
At the "Is this move legal?" level, they don't need unique rules of its own if the lower-level rules are specified correctly.
No piece can be moved that will leave the king of the same color in check.
The post talks about "transition invariants" that should be somehow different from "state invariants" yet it describe them as:
> These are predicates over a <<state, next-state>> pair ...
i.e. it still is about state, but I find it much more useful to focus on behavior so instead of thinking about how state transition you focus on what the program is allowed to perform, regardless of the underlying data structure.
What I mean is that I'd like the code to tell me why a certain piece can't do such move instead of why it cannot transition it's position to another position and basically dumping its state in my head and there I have to execute the program myself.
"Look, if this guys TLA+ logic struggles to model a 1,500-year-old game without crying over a French pawn-capture rule, you can't expect me to integrate Stripe billing without a few state invariant violations."