Richard Harter's World
Site map
Mathcomp
March 2012
Email

Comments on Flow based programming - I

One of the strengths of Morrison's FBP (to coin a term) is the component/process/IP superstructure. It is what allows us to use flow diagrams to put together programs using precoded elements. An important point is that "processes" (I call them autons which is short for autonomous computing element) are not functions in the ordinary sense of programming. Some differences:

  1. An auton has indefinite duration; it is based on suspend/resume logic rather than invoke/return logic. In other words it is persistent in a way that function invocations are not. Because it is persistent in can be registered in a flow diagram as a permanent constituent.
  2. Autons are not invoked; they are activated by the presence of content in their input queue(s). (Or something that looks like their input queue, but that is another matter.)
  3. Autons have inports (input ports) and outports (output ports). Messages arrive in the inports and are sent out in the outports. What counts as a message is a separate matter.
  4. Flow into and out of autons is managed by an external scheduler that is separate from the code in the auton implementations. In contrast flow into and out of functions is embedded in the implementation, typically on a stack or stacks. This is why the notion of sending one auton to another is problematic.
  5. There can be multiple autons with the same executable code persistently present in a program, potentially each with a different state. Having persistent invocations of impure functions with separate state is not consistent with ordinary imperative code.
The component/process distinction is important in FBP. One way to think of it is to compare it to a shop with a supply of parts. For example, it might be an auto repair shop with a stock of oil filters. The shop has a parts catalog. In the catalog there are various kinds of parts listed along with their part numbers. When I need an oil filter I check the catalog to find the right part number and then get it from the parts bin. That's why I am comfortable with the term "component". However one could think of components as prototypes or templates. Maybe template is a better term.

One of the things about information packets is that they are not messages as such. Each IP is a unique object with a well defined lifetime. It comes into existence either as an input from outside or as a de novo creation. It passes from place to place until it comes to the end of its existence. Messages, on the other hand, are not unique objects as such.


This page was last updated March 1, 2012.

Richard Harter's World
Site map
Mathcomp
March 2012
Email