A Question about Overlap

I was reading the Wikipedia introduction to Dataflow, and noticed Functional reactive programming was listed as a 'See Also' term. So it seems that Dataflow programming and Functional reactive programming are somewhat related.

Then, while I was working my way through SICP, I came across the section dealing with Constraints; I noticed that these constraint systems are quite similar to Dataflow and FRP systems.

It seems all these systems deal with ways to describe node relations that have values which change continuously based on their inputs.

It seems to me then, that these three fields are dealing with a lot of overlap. Am I correct in this thinking, or are these three fields really a subset into a larger more comprehensive topic which I have presently overlooked?

Comment viewing options

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

sounds like a good question to me

since i've come across different parts of that <elephant>, but don't know what the right word for <elephant> is.

I usually call this particular elephant...

...a finite state machine.

But that does depend on one's particular paradigm. But no matter which way you look at it, you NEVER get to see the entire elephant.

There is a LOT of overlap among the different views of computing, and many times it's simply a matter of different words being used for the same concepts. Being able to deal with that is an enormously useful skill to master, especially in technical disciplines.

You might want to look into

You might want to look into Oz wich combines the dataflow and constraint aproches.

reactive systems

I've struggled with this question :) I'm assuming the reference to dataflow is more about actor systems than 80s dataflow hardware.

They all provide ways of abstracting over time so that a change can cleanly be reacted to. To lump them together, I'd say they are ways of specifying reactive systems.

Implementation techniques are often very close as well. FRP typically is for synchronous computation over functional streams, where each stream and sub-computation can be viewed as a node in a data flow network. In lucky cases (see clock calculus or 'lowering' optimizations) you can compile away from explicit actors/nodes into more basic transition functions. Constraint solvers can often use incremental computation techniques (see adaptive/kinetic algorithms), which are common to see in FRP (and thus data flow) programs. The bag of implementation tricks has a lot of overlap.

At the expressive level... they embody diverse sets of languages. Decisions about synchrony, dynamism, and higher order flows for FRP and dataflow languages are similar, but I don't know enough about constraint programming to say anything there (would CSS, or more out there, datalog with changing external relations count?). FRP can be thought of as a special form of dataflow/stream computing built to leverage functional techniques (see synchronous kahn networks), have a nice denotational semantic, and provides (in my novice opinion) more reasoning footholds than most actors / process calculi. Perhaps constraint systems have closer ties to equational or model-theoretic reasoning, but I'm way out of my element there. There is both a lot of logical and optimization work in this area so clarification might help.

Related taxonomy

saw that PVR points out a possibly related taxonomy elsewhere on LtU.