The debugger has been available online for a while ( http://debug.elm-lang.org/ ). It explains how it works and has some more interesting examples than stamps :)
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.
Purity has little to do with it since the debugger isn't incremental in replaying the events at all. Local program state is perfectly ok, for example, since you are restarting from the first event anyways (otherwise nothing physics would work), and there are well known ways of dealing with it incrementally.
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.
I don't understand your first sentence. What does "debugger isn't incremental" mean?
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.
If you have 1,000 events, make one change to the code, then you must replay all 1,000 events. If you are at event 999, and want to go back to 998, you have to replay 998 events to get there. If it was incremental, you would have much smaller chunks to compute in the average case.
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 see where things are confused. In this case, I guess it depends on whether you store the entire sequence of states of the application or if you're storing the entire sequence of events emitted.
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.
