Why can't Elm do back-in-time debugging anymore? (Subscriptions vs Signals)

[John Bugner]

In Elm 0.17, signals were removed, and subscriptions were added. Evan says here ( http://elm-lang.org/blog/farewell-to-frp ):

>That is all nice, but the big benefit is that Elm is now significantly easier to learn and use. 

I agree! Thinking about my program in terms of MVU (model, view, update) is easier than trying to put together a signal graph. I'm told that this change broke things like back-in-time debugging, but I don't know why. Why is it not possible anymore? It seems that subscriptions grew out of this successful experiment ( https://github.com/evancz/start-app/blob/master/src/StartApp.elm ) to find a way to simplify programming with signals.

Let's compare the signatures of the 'Program' types ('Config' in StartApp.elm):

from https://github.com/evancz/start-app/blob/master/src/StartApp.elm :

>type alias Config model action =

>    { init : (model, Effects action)

>    , update : action -> model -> (model, Effects action)

>    , view : Signal.Address action -> model -> Html

>    , inputs : List (Signal.Signal action)

>    }

from http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html :

>type alias :

>    { init : (model, Cmd msg)

>    , update : msg -> model -> (model, Cmd msg)

>    , subscriptions : model -> Sub msg

>    , view : model -> Html msg }

>    }

>    -> Program Never model msg

They look pretty similar! 'init' is the same. 'update' is the same. But 'view' and 'subscriptions'/'inputs' are different. 'view' lost a parameter, and 'subscriptions' gained a parameter. The magic difference that lost us BiT debugging must be in there, right? I recall reading that BiT debugging was only possible when the signal graph was static. Wouldn't this correspond to 'subscriptions' gaining a parameter? (and thus becoming dynamic?) and about 'view', why did it have/need a 'Signal.Address action' parameter?

I guess my question is: wouldn't it have been possible to make Elm use the MVU model, but still allow BiT debugging? (Basically keep using the StartApp package?) If so, why then was FRP abandoned?

[Mike MacDonald]

It still supports most of the old time-travel functionality; the only thing gone is the ability to resume execution from a historical state. I do not think this is a technical limitation, but rather a decision made to simplify the debugging workflow. (Also, import/export is a super valuable feature for QA.)

[John Bugner]

(1) What do you mean by "gone"? Impossible?, or simply not included?

(2) Isn't "resuming execution from a historical state" the same thing as importing a state?