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:
- 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.
- 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.)
- 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.
- 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.
- 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.