3 ms·
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 o
by iamwil 12y ago
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.
- seanmcdirmid 12y agoIf 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).
- iamwil 12y agoI 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.