This blog is about Reactive Demand Programming (RDP) and some of the concepts and motivations surrounding it, and a planned language RDP-based with preliminary name Awelon. Almost every article is related to RDP at least indirectly.
RDP is a bidirectional, reactive dataflow model that supports commutative, idempotent, continuous effects on external resources: resource state may be influenced by a set of values. RDP is a logical extension of REST architectural style to influence and effect. The resulting programming model is deeply symmetric and compositional, and enables much equational reasoning.
The current implementation of RDP is as a set of packages in Haskell, called Sirea (simply reactive). Open discussion of RDP is available at reactive-demand@googlegroups.com, which is a better venue for questions than comments on this blog.
Meta Comments: I accept discussion in comments, but I also believe in moderating them. Not immediately, mind – no need to hurt someone doing this, and time provides some emotional distance – but, a few months after you’ve commented, I may try to trim comments down to those of great relevance, pith, or clarity. If that is not for you, consider use of external fora for comments such as reddit or reactive-demand@googlegroups.com or your own blog.
Awelon Blue 
Can you provide some reading recommendations that’ll help someone with basic computer science knowledge make sense of your more technical posts? I’d be very grateful.
For general knowledge, I would recommend two books above most others: Peter van Roy’s Concepts Techniques and Models in Computer Programming, and Benjamin Pierce’s Types and Programming Languages.
For more specific knowledge that might help you better grok RDP’s concurrency and computation model, I would recommend reading a few papers: Dedalus: Datalog in Time and Space, The Synchrony Hypothesis, and about Time Warp protocols.
If you’re having trouble with the RDP composition, you could read Understanding Arrows from the Haskell wiki for a few metaphors. But I think that the best way to understand arrows is one specific arrow at a time, with small program examples. (I also recommend learning Haskell. You’ll learn a lot of good abstractions on a deeper level.) For more on securable, open composition (modularity, linking) I would recommend reading about the object capability model. Finally, the Sirea Readme is essentially an article on RDP.
It’s hard to provide a good survey list for all posts. I try to link related material in posts (when I know of it and think it useful) but if you have specific questions for a post you can ask them there.
Are you familiar with programming or specification languages based on category theory? I think they have some nice ideas that might be useful for RDP.
Some main ones are Charity (http://pll.cpsc.ucalgary.ca/charity1/www/home.html) and Specware (http://specware.org/)
There are many links for interesting ideas found here:
http://mathoverflow.net/questions/4235/relating-category-theory-to-programming-language-theory
http://www.haskell.org/haskellwiki/Category_theory
I am familiar with Charity. It did influence some of my earlier approaches to language design, though less now. I am also aware of the relationship between RDP and many categories (e.g. the Sirea.Behavior classes align with many classes of the ‘categories’ package in Haskell, by design).
I guess that’s why I saw some ideas I thought was a bit similar.
Among the Specware papers, this is the one I’ve found most interesting myself:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.4784
Is RDP has any relation to B. Pierce et la. Boomerang http://www.seas.upenn.edu/~harmony
No. Well, at a philosophical level, there is some relationship: both RDP and Boomerang support influence of a system through a view of the system. But RDP does not ensure reversibility, and is a very different approach from Boomerang.
Hello
How is this this model different from concurrent constraint programming?
RDP was inspired in part by temporal concurrent constraint programming (TCCC). But TCCC is not very composable, e.g. there is no sensible ‘reply’ to declaring a constraint. And TCCC tends to not scale very well.
RDP does not have any built-in constraint model. In RDP, each resource can receive a set of ‘demands’ which may represent constraints or other things, e.g. a demand for information. Each distinct demand may receive a distinct reply (duplicate demands must receive duplicate replies). To model TCCC above RDP would mostly involve interpreting demands on some resources as describing constraints.
I think such constraint systems would make useful resources within the larger RDP system for many problems (cf [1][2]). But I imagine most RDP behaviors will focus instead on information gathering (e.g. demanding information from sensors or databases) and ad-hoc influence over state or actuators. Reactive concurrent constraint models would be small subsystems within the larger RDP system.