node's previous output is then ignored. Another method involves delta propagation i.e. incremental change propagation. In this case, information is proliferated along a graph's edges, which consist only of deltas describing how the previous node was changed. This approach is especially important when nodes hold large amounts of state data, which would otherwise be expensive to recompute from scratch. Delta propagation is essentially an optimization that has been extensively studied via the discipline of incremental computing, whose approach requires runtime satisfaction involving the view-update problem. This problem is infamously characterized by the use of database entities, which are responsible for the maintenance of changing data views. Another common optimization is employment of unary change accumulation and batch propagation. Such a solution can be faster because it reduces communication among involved nodes. Optimization strategies can then be employed that reason about the nature of the changes contained within, and make alterations accordingly. e.g. two changes in the batch can cancel each other, and thus, simply be ignored. Yet another available approach, is described as invalidity notification propagation. This approach causes nodes with invalid input to pull updates, thus resulting in the update of their own outputs. There are two principal ways employed in the building of a dependency graph: The graph of dependencies are maintained implicitly within an event loop. Registration of explicit callbacks, then results in the creation of implicit dependencies. Therefore, control inversion, which is induced via callback, is thus left in place. However, making callbacks functional (i.e. returning state value instead of unit value) necessitates that such callbacks become compositional. A graph of dependencies is program-specific and generated by a programmer. This facilitates an addressing of the callback's control inversion in two ways: either a graph is specified explicitly (typically using a domain-specific language (DSL), which may be embedded), or a graph is implicitly defined with expression and generation using an effective, archetypal language. Implementation challenges in reactive programming Glitches When propagating changes, it is possible to pick propagation orders such that the value of an expression is not a natural consequence of the source program. We can illustrate this easily with an example. Suppose seconds is a reactive value that changes every second to represent the current time (in seconds). Consider this expression: t = seconds + 1 g = (t > seconds) Because t should always be greater than seconds, this expression should always evaluate to