The MPEG Reconfigurable Video Coding (RVC)[2] working group has adopted CAL as part of their standardization efforts.
The CAL Actor Language was developed in 2001 as part of the Ptolemy II project at University of California at Berkeley.
Another common reason for choosing dataflow is that the goal is an efficient parallel implementation which would be difficult or impossible to achieve using a sequential programming language.
A CAL dataflow program provides simple, understandable, and powerful abstractions that allow the specification of as much or as little parallelism as is required, enabling tools to produce sophisticated implementations that exploit the concurrent structure of a computation.
Rather than being concerned with the step-by-step execution of an algorithm, a dataflow programmer builds a system of asynchronously communicating entities called actors.
One of the key design goals of the CAL language was to allow the description of non-deterministic actors, while at the same time permitting tools to identify possible sources of non-determinism, so that they can warn the user about them.
A key consequence of a non-deterministic actor like NDMerge is that during an actual execution, its output may depend on the timing of its input.
One way to look at non-determinism of the kind that makes an actor dependent on the precise timing of token arrivals is that such an actor only appears to be non-deterministic if we look at it as an operator on streams, because that view abstracts from the temporal properties of the execution, and thus purposefully removes information that is used to determine the sequence in which actions fire.
From the perspective of the CAL language, this is not entirely accurate, but even so, it is easy to write non-deterministic actors that would not be deterministic even if we knew everything about the timing of the tokens and the actor implementation—such as the following: The guard clause of an action contains a number of expressions that all need to be true in order for the action to be fireable.
(Or it will remain there forever, as in the case of the zero token in front of SplitDead, which is never removed because the actor is dead.)
It is similar to the NDMerge actor in the sense that it merges two streams (the ones arriving at its A and B input ports).
The IterSelect actor of the previous section illustrated the use of state to control the selection of actions.
This is an extremely common thing to do in practice, and the CAL language provides special syntax for this purpose in the form of schedules.
Conceptually, one can think of schedules as codifying a particular pattern of using a state variable—they do not add anything to the language in terms of expressiveness.
Unlike in this case of schedules, which could be regarded syntactic sugar because they could be reduced to existing elements of the language (state variables, guards, and assignments), this situation does in fact require a true extension—action priorities.
The basic idea is to add a number of inequalities that relate actions with respect to their firing precedence.
But in general, it is important to understand that priorities, especially when used as in the previous example, need to be well- understood to yield the correct results.
Especially when information about the timing of the communication within the network is vague, it is probably best to think of them as strong implementation directives.