In this tutorial we’ll look at general ways to store state.
We already know that we can temporarily affect the path of a marble using a switch 
:
This isn’t state, because the checker marble leaves immediately after its job is done.
We could make it more permanent by keeping the checker marble in place:
Here we have two copies of a latch. Depending on whether a checker marble is placed in the latch, the input stream will be permanently routed to one of two paths.
This is a good start, but there’s a problem. Once we choose whether to place a 
or 
, the latch’s behaviour is fixed. We need a way for our pattern to dynamically switch the latch on and off.
dynamic latch
- On the right-hand side, a switch diverts the input stream to the 1 output or 0 output.
- The checker marble c loops back around to reenter the switch .
- Along the way, c encounters a second switch. By sending in another from the top into the checker cell, c gets ejected from the loop, permanently setting the overall latch to 0.
- To turn the latch back to 1, we can inject a new c from the bottom.
This latch lets us store one bit of state. We can write it (set the value) to 1 or 0, and it will stay in that state. We can then read that value out.
There’s a few issues with this latch:
- It takes up nearly a full disk.
- It uses lots of roons.
- We can only read/write it whenever the checker marble finishes its full loop, not once every step.
- It’s messy.
Next we’ll look at a much more compact way of storing state.
