A function represents an operation upon a set of stream elements (the bound input parameters), applied over a set of bound dimensions, which produces one or more output stream elements as bound output parameters. The function is the interface between the dataflow graph level of algorithm specification and the lower level (which is data machine dependent.)
While generally equivalent, a Q function isn't necessarily identical to the ``function'' of a typical high level language. It may instead represent one portion of a high level function, a ``code fragment'' or sequence of operations which together access only a small set of parameters, using temporary local storage to intercommunicate intermediate values. Previous work on hybrid dataflow architectures has partitioned these based on any access to non-register memory. Q assumes that data machines will also have relatively exclusive (deterministic) access to larger memories, allowing input and output stream elements to be passed by reference. This relaxation of the code partitioning requirements allows coarser grained (larger) partitions.
Functions are restricted to accessing bound parameters (streams) and whatever local storage (registers, stack) a particular data machine may provide (i.e. no ``side effects'' are allowed). Any local storage is assumed undefined upon function entry, unless used by the data machine ISA for function arguments.
Another restriction is that sequential function implementations must terminate in bounded time. Such a function is viewed as a fundamental unit of execution, which is never ``context-switched'' as all required input data and output data space is by definition available ``local'' to the processing node -- accessible with a deterministic latency, known at compile time of the function implementation.
Sequential function evaluation in Q is strict, in that all function arguments must be present for function evaluation. If non-strictness is desired in an algorithm (and it usually is), a conditional primitive, mcond is provided at the DFG level. A function with a graph implementation will be evaluated in a non-strict manner.
A Q function may be defined as applying over zero or more dimensions, which are specified when the function is applied. These bound dimensions are analogous (and in addition) to the bound variables of a traditional function. All stream fragments generated for a sequential function implementation will have the information about particular dimensions ordered appropriately: bound dimensions are first, and in the same order as their declaration. It is important that a function specify all dimensions accessed; otherwise the function has no way of correctly accessing (indexing) the parameters describing the data along that dimension.
Q functions typically reside in shared libraries. These libraries may have function implementations (compiled object code or configuration data) for multiple machine architectures, including specialized ones. A description of the function, containing the information necessary for proper scheduling -- the function's stream access patterns and available machine implementations along with their performance -- is contained in the function object. The actual function implementations, which are located separately, may be dataflow graphs, or sequential functions: compiled object code or configuration data for particular machine architectures.