Home » forums » LtU Forum

Coherent Reaction

Coherent Reaction by Johathan Edwards

Side effects are both the essence and bane of imperative programming. The programmer must carefully coordinate actions to manage their side effects upon each other. Such coordination is complex, error-prone, and fragile. Coherent reaction is a new model of change-driven computation that coordinates effects automatically. State changes trigger events called reactions that in turn change other states. A coherent execution order is one in which each reaction executes before any others that are affected by its changes. A coherent order is discovered iteratively by detecting incoherencies as they occur and backtracking their effects. Unlike alternative solutions, much of the power of imperative programming is retained, as is the common sense notion of mutable state. Automatically coordinating actions lets the programmer express what to do, not when to do it.

Coherence is not a problem of constraint satisfaction — it is a problem of constraint discovery. Previously there have been two alternative solutions: reduce the expressive power of the language so that constraint discovery becomes decidable (as in state machines and dataflow languages), or leave it to the programmer to deal with.

By Greg Buchholz at 2009-04-26 03:42 | LtU Forum | previous forum topic | next forum topic | other blogs | 4474 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I've been thinking along

Section 2.1 seems to be within the bounds of traditional FRP (e.g., handling mutation via cells) and I bet other systems -- 2.1 is the typical case and not a big deal. E.g., I had a rejected paper last year mostly showing how it's useful to allow reactions to variable and field mutations when bridging imperatively reactive code to use functional reactivity.

Section 2.2 is about an intuitive semantics for effects in reactive systems and a wide open problem (devil is in the details). The rejected paper also proposed adding state viz. big steps on the store, similar to Esterel. Reactions occur on a snapshot of the store, and to preserve synchrony, effects are delayed: all the reactions within a synchronous clock tick are essentially transactional. I believe this achieves a property similar to coherency.

I considered transactions to be an appealing way of implementing the steps, and, once you start thinking this way, search is how you'd get progress in such a implementation. However, putting search at the semantic level seems like one of the *least* intuitive things you can do, only a notch below observable non-determinism. I'm curious to read section 3 tomorrow to see if I'm swayed (and that I understand the proposal!).

Cool to see some more thinking about this problem, even if not in a mainstream embedding. There were some odd edge cases I was worried about when working through my design, so I'm looking forward to giving this a more detailed read.

By lmeyerov at Sun, 2009-04-26 08:07 | login or register to post comments