Elm Debugger: Stamps [video]
youtube.com
youtube.com
Basically, it's a consequence of Elm's design. All input to the program (timers, mouse, keyboard, etc) comes from signals. Think of a signal as a variable that changes over time. Each signal consists of events over time.
Because Elm's a pure functional language, there are no side effects, meaning, if you put the same parameters into a function, you'll always get the same result. That means if you put in the same event into the program, you'll get the same result. If you record all events of the signals over time, you can replay the state of the program at any time.
Swift's Playground, in contrast, is probably checkpointing in addition to recording events given performance concerns (elm, being non incremental, doesn't have a performance story for time travel). Note there is nothing pure or monady about swift, which is not required for time travel debugging at all, really.
And do you mean that purity has little to do with implementing this kind of debugger in general? Or do you mean that purity is little to do with the Elm debugger shown?
The question asked was, "how does the elm-debugger do this?" not "how do you write this kind of debugger in general?" In answering the former, purity has much to do with it, as I understood his talk.
Purity has little to do with implementing these kinds of debuggers, effects need to be explicit, but this can be dynamic explicitness rather this static kind.
The question can be interpreted in multiple ways, but this is not a feature novel of Elm (see "time steering" in the 90s...and debuggers like xstep).
I was thinking of the former, while you were thinking of the latter. If the entire state of the application is contained in one place, you don't need to reply events from the beginning. You just need the application state at the point.