The specification is text-based and mostly declarative. It is divided into units called "stanzas", each with a different function. The full specification for Split_Interval is given below.

input_ports {}
output_ports { IntegInfo I1; IntegInfo I2;}
shared_vars {}
vars { real a; real b; int n; IntegInfo i1; IntegInfo i2;}
init_comp {}
firing_rules {}
comp {
  a = ReadReal();
  b = ReadReal();
  n = ReadInt();
  i1.a = a;
  i1.b = (a+b)/2.0;
  i1.n = n/2;
  i2.a = i1.b;
  i2.b = b;
  i2.n = n - i1.n;
}

routing_rules {
  TRUE => I1 <- i1; I2 <- i2;
}

Output ports are names that are bound to arcs that leave the node, and input ports are names that are bound to arcs that enter the node. The type name of the data that will be placed on the two ports I1 and I2 is IntegInfo, a structure that contains the endpoints of an interval and the number of points to use in the integration (this type is defined elsewhere, as a C-like struct).

The vars stanza defines local variables that will be used by the sequential computation, defined in the comp stanza. In this example, the computation will define two intervals which it stores into the structures i1 and i2.

Note that although the language used in the comp stanza looks like C, it is actually just a limited subset. It is expected that all substantial sequential computations will be encapsulated in functions defined outside of CODE (in C, for instance). In the example, we refer to ReadInt and ReadReal which are implemented as C functions.

Rules

Routing rules look like this:

Guard, Guard, ... , Guard => Binding; Binding; ... ; Binding;

Guards are Boolean expressions and Bindings are pairs of output ports and expressions joined by <-, indicating the values to be placed on these ports.

A computation is only executed when all of the guards in any of its firing rules are true, in which case it is said to be "satisfied." Firing rules typically look like this:

Guard, Guard, ... , Guard =>

In this case, the guards are either Boolean expressions or pairs of input ports and local variables joined by -> (these expressions are true when data is available and have the side-effect of binding the variable to the value from the input port when the entire firing rule is satisfied). The syntax for firing rules actually permits more complicated expressions than this, including assignment statements on the right-hand side of the =>, but such elaborate firing rules are rarely needed in practice.

Arcs

Since nodes only communicate with their ports, we need some way of connecting the output port of one node to the input port of another. This is done by drawing an arc between them and annotating the arc appropriately. Arc annotations bind port names between nodes. For example,

.I1 => .I

indicates that the output port I1 is bound to the input port I. In the example, this is the annotation on the arc connecting Split_Interval to the left Integ_Half.

It is helpful to use an integrated circuit analogy. The computation nodes are the chips, whose pins have to be connected. The arc annotations describe which "pins" are connected between chips.

How It Works

When data appears on an arc entering a computation node, the firing rules are checked repeatedly until a firing rule is true. It is executed and any bindings are performed. If the computation node is firing for the first time, the init_comp stanza is executed. The comp stanza is then executed, and then the node waits until any of its routing rules become true. Once one does, it is executed, any bindings are performed, data is sent out the ports to the arcs, and the node waits again for more data to appear on an entering arc.

Static vs. Dynamic

introduction dynamic graphs