3 ms·

> then you could replace any "reactive" program by one which just recomputes its outputs every time something changes, from scratch. Reactive programming solves

by tel 12y ago

> then you could replace any "reactive" program by one which just recomputes its outputs every time something changes, from scratch. Reactive programming solves this by only recomputing parts which change. I find that to be completely desirable. That behavior is exactly what I want... simply done more efficiently [0]. [0] Also modulo a whole bunch of local state. AFRP handles this well by having a good notion of what it means to "switch an arrow in" but it's been a challenge for applicative/monadic FRP. Rx programming (e.g. "not FRP") tends to solve this problem by ignoring its existence and just littering local state everywhere.

seanmcdirmid 12y ago
Just to note, many definitions of "reactive" are not based on recomputation (just react to those events dammit, whatever that means), while even those that are based on recomputation, there are many other issues to consider vs. incremental performance, like state preservation in a stepped recomputation, or implicit state that arises from aggregating over an event stream (FRP). Note that FRP is incremental in the time dimension (add a new time point to the program, you don't have to recompute the program for previous time points), but we really want more than that (don't recompute parts of the program execution that are not affected by changes in the time point). It isn't clear to me that arrowized FRP is incremental. I think some of the less pure FRPs are (like Flapjax) given that they do a topological sort of the signal graph to repair it (if they were going to redo everything, the sort wouldn't be necessary).
- tel 12y ago
  To be clear, I'm trying to state that a (nice) recomputation semantics is desirable because it means it's possible to reason about your program ignorant of time. Obviously, an implementation is preferable if it can speed things up via incremental computation and that ought to be nice as well AFRP is a good example here. AFRP semantics are easily stated in a recomputational way. It makes it necessary to talk about causal AFRP and bounded history AFRP which are nice terms to think about a computation (if sort of obvious). Then, the efficient implementations (of causal AFRP) themselves are incremental for efficiency.
  - seanmcdirmid 12y ago
    Do you have an citations about AFRP implementations being incremental. I haven't been able to find much in my own literature survey.
    - tel 12y ago
      Perhaps I'm not understanding the terminology, but every implementation I've ever seen consumes input incrementally. E.g. data (i ~> o) = A (i -> (o, i ~> o)) data (i ~> o) = forall s. A (i -> s -> (o, s)) in each case, the inputs are consumed sequentially, the outputs returned immediately, and the local state updated for the next time around. If you're referring to the ability for a new event to update the signal network only partially (in Elliott's terminology, "push" semantics) then there's Amsden's TimeFlies library.

by tel 12y ago

seanmcdirmid 12y ago

Just to note, many definitions of "reactive" are not based on recomputation (just react to those events dammit, whatever that means), while even those that are based on recomputation, there are many other issues to consider vs. incremental performance, like state preservation in a stepped recomputation, or implicit state that arises from aggregating over an event stream (FRP). Note that FRP is incremental in the time dimension (add a new time point to the program, you don't have to recompute the program for previous time points), but we really want more than that (don't recompute parts of the program execution that are not affected by changes in the time point). It isn't clear to me that arrowized FRP is incremental. I think some of the less pure FRPs are (like Flapjax) given that they do a topological sort of the signal graph to repair it (if they were going to redo everything, the sort wouldn't be necessary).

tel 12y ago
To be clear, I'm trying to state that a (nice) recomputation semantics is desirable because it means it's possible to reason about your program ignorant of time. Obviously, an implementation is preferable if it can speed things up via incremental computation and that ought to be nice as well AFRP is a good example here. AFRP semantics are easily stated in a recomputational way. It makes it necessary to talk about causal AFRP and bounded history AFRP which are nice terms to think about a computation (if sort of obvious). Then, the efficient implementations (of causal AFRP) themselves are incremental for efficiency.
- seanmcdirmid 12y ago
  Do you have an citations about AFRP implementations being incremental. I haven't been able to find much in my own literature survey.
  - tel 12y ago
    Perhaps I'm not understanding the terminology, but every implementation I've ever seen consumes input incrementally. E.g. data (i ~> o) = A (i -> (o, i ~> o)) data (i ~> o) = forall s. A (i -> s -> (o, s)) in each case, the inputs are consumed sequentially, the outputs returned immediately, and the local state updated for the next time around. If you're referring to the ability for a new event to update the signal network only partially (in Elliott's terminology, "push" semantics) then there's Amsden's TimeFlies library.