what is the point of timestep?

[stevengj]

Why bother passing time() when the dependencies are updated? I don't understand the need for this.

[shashi]

I was following what Elm does. They don't use it anywhere either. In send and recv it's just a nice to have, I guess. You can distinguish one signal propagation from another, also gives a pure function feel to things. The #9 removes it.

[dcjones]

We talked last week about the idea of throttling updates. E.g. updating plots according to a slider can lag if it tries to redraw on every intermediate value. Would timestamps be necessary to implement that?

I've been looking through the Elm documentation, it seems like we may eventually want to implement some of the functions in Time, like since, every, fps. Not that it should be a priority, but I wonder if timestamps would end up being important.

[shashi]

You can create fps, every, since as input nodes or lifted nodes thereof that update periodically. This timestep won't be important. The Elm thesis uses timestep and NoChange updates (see #4) to provide a premise where each signal node can execute in its own lightweight thread. I will leave this issue open till I figure out this stuff properly. I'll start working on the timing signals once I get the widget stuff back up and running.

Also see this discussion: https://groups.google.com/forum/#!topic/elm-discuss/YcvPwhcq_sU

[stevengj]

A node that needs to timing can always call time() itself. A node that needs to update automatically after a certain time interval should create a Timer asynchronous task so that the Julia event manager can wake it up as needed.

[shashi]

There are no timesteps now. I discussed this with Evan and it turns out this is used in a concurrent FRP context, which I will not look into right now.