A PLAN program consists of two components: the code, and the
invocation. The code consists of a series of definitions which bind
names to abstractions; these abstractions take the form of functions,
values, and exceptions. The invocation consists of the function
call (i.e., function name f and actual parameters 
) to be
evaluated at the next evaluation point, where the set of all definitions in
the code part (as well as some predefined service functions) serve as the
legal environment for the call. Note that all of the actual parameters in
the invocation must be values, since PLAN supports a
call-by-value semantics.
A PLAN packet consists of a PLAN program that is executed on an active router (or node). In addition to the code, the packet also contains some additional fields: the evaluation destination, the resource bound (explained later), and the routing function. The evaluation destination (or evalDest) names the next active node which should evaluate the program. The routing function serves to define how the packet will be transported from the current node to the evalDest. The resource bound (or RB), indicates the sum total of the number of hops this packet or any of its progeny may make. This serves to limit the network resource usage of any PLAN application.
Finally, a PLAN application consists of a series of PLAN packets that comprise a task. This is different than a host application, which is a program that runs on a end-node in the network, and may be written in some language other than PLAN. In the simplest case, a PLAN application is defined by the injected packet and all of its resulting progeny. More often, PLAN applications may cooperate with host applications to complete a task.