// HACKER NEWS — CYBERSECURITY
Super Mario Derivations
One of the most surprising aspects of the Nix language is that it is lazy, especially if you have never used a lazy language before. This laziness is what makes much of Nixpkgs possible, and its complexity.
One of the simplest ways to observe the laziness is by understanding that only the attributes you access are evaluated.
The more whackier version of this is you can have endless recursion in an attribute set. Nixpkgs is filled with these bottomless attribute sets:
The same store path every time. pkgs contains itself, and so does every package set inside it. 🤯
If laziness is what lets a recursive attribute set terminate, then the recursion doesn’t have to bottom out at all:
That attribute set is infinitely deep. Indexing three levels into it costs exactly three levels of evaluation, and the rest of the infinite tree is never built because nobody asked.
So an attribute path is a walk through a lazily-generated tree. Which made me wonder: what if the attribute path were input to something? 🤔
I decided to take that idea and make the attribute path a sequence of button presses in Super Mario Bros. 3. Each node in the tree is a frame of the game, and each child is a button press that produces a new frame. Game states are recursive by nature.
.rightb is right + B, which in Super Mario Bros. 3 is “run right”. .rightab is run and jump. The output is the frame you’d be looking at if you’d pressed those buttons in that order, on real hardware, in that game.11The prefix .#level1 is a precanned sequence of button presses that gets you to the start of level 1-1.
Append .play anywhere along the path and you get the whole run stitched into a recording: