'''[http://en.wikipedia.org/wiki/Flow-based_programming%|%Flow-based
programming]''', or '''FBP''', is a type of [dataflow programming] in which
program steps communicate with each other by transmitting data through some
kind of [channel].  The channels are managed by the larger system, leaving
the connected components free to focus on processing input and producing output. 



** See Also **

   [Concurrency concepts]:   In flow-based programming, the steps of a program are logically current

   [http://plasma.cs.umass.edu/emery/Flux%|%Flux]:   a language for flow-based programming

   [http://people.cs.clemson.edu/~jsorber/papers/sorber07sensys.pdf%|%Eon:  A Language Runtime for Perpetual Systems]:   

   [http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects%|%Flow-Like Projects]:   

   [http://www.pervasivedatarush.com/%|%DataRush] :   a proprietary java library implementation of Paul Morrison's concepts. Uses a graphical interface to implements FBP.



** Reference **

   [http://en.wikipedia.org/wiki/Flow-based_programming%|%Wikipedia] :   

   [http://c2.com/cgi/wiki?FlowBasedProgramming%|%c2] :   

   [http://www.jpaulmorrison.com/cgi-bin/wiki.pl%|%Wiki], [Jpaulm%|%J Paul Morrison]:   

   [https://www.createspace.com/3439170%|%Flow-Based Programming, 2nd Edition], J. Paul Morrison, Van Nostrand Reinhold, 2010 :   The entire book is available [http://www.jpaulmorrison.com/fbp/book.pdf%|%here]

   [https://groups.google.com/forum/#!forum/flow-based-programming%|%Flow Based Programming Google Group] :   

   [https://groups.google.com/d/msg/flow-based-programming/Gnd_ZA7lSME/cPlmixfiUNAJ%|%Flow-Based vs Data-Flow], 2010-09-14 :   



** Examples **

   [http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication%|%Brokerage Application]:   

   [shell] pipes:   

   [make]:   Use the ''-j'' option to get parallel target construction



** Description **

Whereas in [dataflow programming] the next step fires only after all the
outputs from the previous step are prepared, in flow-based programming the
next step is executed whenever data is available on any input channel.  This is
known as '''asynchronous dataflow''' and is in keeping with the articulated
view of inputs as channels that transport messages.  Essentially, the
semantics of a dataflow program are those of a group of subroutines running
currently, with each performing blocking reads on its inputs, processing data
when it is available, and producing some output.  The blocking reads are the
primary means of controlling the flow of execution.  Tcl, with its [virtual
channel] features, is a natural platform for flow-based programming.
[coroutine%|%Coroutines] are another natural fit.  The arguments passed to
instantiate the coroutine are analagous to '''initial information packets'''
(IIP) in flow-based programming. 

[Jpaulm]: [Bwise] and [LabView] are both mentioned on the FBPWiki page, [http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects%|%Flow-like Projects] - including quite a long discussion about LabVIEW with Jim Kring.

[Roy Terry] recommends this as not only illuminating in its
own right, but "amenable to Tcl implementation".

----

[Arjen Markus]: I was inspired by [http://www.pearsonhighered.com/educator/product/Software-Architecture-Perspectives-on-an-Emerging-Discipline/9780131829572.page%|%Software Architecture: Perspectives on an Emerging Discipline], Mary Shaw, David Garlan, to start thinking about implementing "pipelines" in Tcl. Consider the following example: we want to remove all comment lines from a C source file. One way to do this, is to read in the file, filter out those lines and pieces of text that belong to a comment and write out the remainder.

In one line:

======
output [nocomments [readfile $input_name]] $output_name
======

Or:

======
set content          [readfile $input_name]
set filtered_content [nocomments $content]
output $filtered_content $output_name
======

So, you get a more or less complicated chain of commands, the one taking the output from the previous one.

The drawbacks of this approach are:

   * You need to keep the whole file in memory and possibly one or more processed copies.
   * You need to wait for the whole file to be read or processed before the next step can proceed.

What, on the other hand, if we do it like this:

======
set infile  [open $input_name  r]
set outfile [open $output_name w]
while {[readline $infile line] >= 0} {
    set filtered_line [nocomments $line]
    outputline $filtered_line $outfile
}
close $infile
close $outfile
======

Well, this solves the first objection to the previous method, but the second is changed into:

   * You need to wait for output to become available, if the input file is the output from a separate process or a socket

Two new disadvantages are added, which may even be more serious:

   * How do you handle the case where `nocomments` filters out the entire line? This requires additional logic, probably in the outer loop.

   * What if one line of input causes multiple lines of output from `nocomments` (or some other command, say a pretty printer)?

The book on flow-based programming by J. Paul Morrison describes a method of thinking about programs and designing them that deals with precisely the above difficulties. The solution is to have the input items (lines in this case) generate events that are then treated ''in order of generation'' by other tasks.

How can we achieve this in Tcl? Let us keep it simple - we want to show the principle, so the filtering is: convert everything to upper case.

(To be continued ...)

----
[RS] still wonders how this differs from [Streams] à la [SICP]...

[Lars H]: Or how this relates to [bwise].

[TV] (Long ago maker of [Bwise], inspired by Khoros and Avs and schematic diagrams (I'm Uni EE)) Thank you! The answer is: take Hoare and Milner, check out the long-existing original (? for me anyhow) AT&T and Berkeley versions of [Unix] from the 70s (depending on what you want, some things from the 80s) and you suddenly know most fundamentals of practical and theoretical flow based programming. Of course your concept terminology milage may vary, flow isn't usually meant the same as stream, parallelism isn't the same as multiprocessing, etc...


** See also **

   [Bwise]:   

   [Dataflow programming]:   

   [flow-based programming]:   

<<categories>> Concurrency | Design | Language