A history of data-flow languages

Abstract

Data-flow refers both to a language-level paradigm of computation and to a family of processor architectures based on this paradigm. This article elaborates data-flow language issues and the evolution of data-flow languages. In considering limits to the expressive power of these languages, underlying architectural issues are of necessity discussed. Although the article attempts to present a complete history of data-flow languages, it concentrates on those languages that specifically belong to this class and have been implemented for a data-flow machine. In many cases, the distinctions between issues of language semantics and machine architecture are unclear. Usually we have found that this reflects the evolution of data-flow, and the close association between language and architecture development. In some sections of the article, it may appear that there is an imbalance in the amount of detail presented when compared with other sections. This imbalance is proportional to the publications and the amount of information readily available for the topics.ata-flow languages derive from a base paradigm of the D datu-flow graph -that is, the modeling of a program as a set of operator nodes interconnected by a set of datacarrying arcs. Under this paradigm there is no current operation, and each operator is free to execute when its data arrives. The interpretation of the language is naturally concurrent, and the concurrency is inherently fine-grained.The data-flow model has the single-assignment property. Values are data tokens that are transported from their producing node to the node that consumes them; there is no concept of a variable with a state that can be arbitrarily updated at a later time. In data-flow, identifiers may be used to name these data tokens. Such identifiers are thus either undefined (not yet produced) or carry a single unique value; they cannot be updated.For a counterpoint to data-flow, languages belonging to the class referred to as functional languages model programs as nested mathematical functions. In pure functional languages, identifiers denote subexpressions, and given that a sub-expression has a single unique value (which cannot be updated), these languages likewise share the singleassignment property.In examining the development of data-flow languages, a strong mutual influence between data-flow and functional languages appears. This is probably due to their contemporary development, the sharing of certain fundamental properties that stood in stark contrast to the popular imperative languages of their time, and similar problems of efficient implementation shared by both language classes. Most modern data-flow languages do not have their semantics defined in terms of program graphs. There are fundamental limitations of such a strict definition of data-flow. In the first place, certain programming language facilities that have proved to be useful (such as iteration) are not easily represented in terms of a static data-flow graph. Second, the efficient implementation of certain operations, par...

Chapter 12: Panta Rhei: Flexible Execution Engine for Search Computing Queries

“…For example, data flow systems [25] and stream processing systems, e.g. Aurora/Borealis [1], have addressed the problem of scheduling data-intensive computations.…”

A survey on reactive programming

“…These include synchronous programming, dataflow programming and synchronous dataflow programming. In this section, we give a brief review of those paradigms because there exist surveys [Benveniste et al 2003]; [Whiting and Pascoe 1994]; [Johnston et al 2004] that give a full review of the research on the languages in the family of synchronous programming, dataflow programming and synchronous dataflow programming.…”

“…Another approach that has been used to model reactive systems is dataflow programming (originally developed to simplify parallel programming) [Johnston et al 2004]; [Whiting and Pascoe 1994]. A dataflow program is expressed as a directed graph with nodes representing operations and arcs representing data dependencies between computations.…”

“…With interactive applications (e.g., Web applications) becoming increasingly distributed, we believe that reactive programming needs to be further explored to cover distributed environments while giving the same assurances as their non-distributed counterparts. This article builds on prior surveys [Benveniste et al 2003]; [Whiting and Pascoe 1994]; [Johnston et al 2004] that review early research on synchronous programming and dataflow programming.…”

A delta-driven execution model for semantic computing

“…Dataflow languages arose from research into concurrent computing [35], and our future efforts will no doubt leverage the substantial research already undertaken in this area.…”