Defines a stream of events, encapsulating them in a structure isomorphic to an infinite list [Bird87], thus all properties of lists may also be applied to Streams. While, in combination with lazy evaluation, it is possible to create and simulate infinite signals, we need to ensure that the first/previous event is always fully evaluated, which is equivalent to ensuring the the monotonicity property in dataflow systems. This translates in the following composition rule:

non-causal feedback is forbidden

also called "zero-delay" feedback loops, are caused by un-evaluated self-referential calls. In a feedback loop, there always has to be enough events to ensure the data flow.

This rule imposes that the stream of data is uninterrupted in order to have an evaluatable kernel every time a new event is produced (i.e. to avoid deadlocks), which is ther equivalent to ensuring continuity in dataflow systems. This translates in the following rule:

cleaning of signals in a feedback is forbidden

in other words, whenever a feedback composition occurs, for each new input at any instant in time, a process must react with at least one output event.

This is a type class defining interfaces for the MoC layer atoms. Each model of computation exposes its tag system through a unique event type which is an instance of this class, defining \( T \times V \).

To express all possible MoCs which can be described in this layer we need to capture the most general form of their atoms. Depending on the execution regime of a MoC, its atoms might or might not need additional parameters to determine the behavior for evaluating each argument. These additional parameters we call, in loose terms, as the execution context.

execution context

Additional information which, paired with a function, completely determines the behavior of a MoC atom (i.e. process).

\[ \Gamma \vdash \alpha^m \rightarrow \beta^n \simeq \Gamma_{\alpha,1} \times \alpha_1 \rightarrow ... \rightarrow \Gamma_{\alpha,m} \times \alpha_m \rightarrow (\Gamma_{\beta,1}\times \beta_1) \times ... \times (\Gamma_{\beta,n}\times \beta_n) \]

The left-hand side expression above shows the most general notation used to describe a function with m inputs of (possibly different) types \(\alpha\) and n outputs of (possibly different) types \(\beta\) executed in context \(\Gamma\). The right-hand side expression shows that in ForSyDe-Atom context is associated with each and every argument in order to enable the applicative mechanisms. Depending on the MoC, \(\Gamma_{\alpha,i}\) would translate to e.g.:

\[ \Gamma_{\alpha,i} \in \begin{cases} \emptyset, & \text{for all timed MoCs (e.g. SY, DE, CT)} \\ \mathbb{N}, & \text{for static variants of SDF}\\ \mathbb{N}^n, & \text{for CSDF}\\ S \times \mathbb{N} \rightarrow \mathbb{N}, & \text{where } S \text{ is a state space,} \\ & \text{in the most general case of untimed data flow} \end{cases} \]

One example of execution context is the consumption and production rates for synchronous data flow MoCs (e.g. SDF). In this case the passed functions are defined over sequences or partitions of events, i.e. groupings of events with the same partial order in relation to a process firing.

Although a more elegant approach of passing execution context would be using type-level arithmetics, this is a non-trivial task to implement in Haskell. This is why we chose the pragmatic approach of pairing a context parameter per argument, similar to the formula above, where:

• any function representing a partition of \(\alpha\) is operating on a recursive type, namely a list \([\alpha]\).
• to aid in pairing contexts with each argument in a function, the general purpose ctxt utilities are provided (see ctxt22).
• this artifice is masked using the generic type families Fun and Ret.

The delay process provides both initial token(s) and shifts the phase of the signal. In other words, it "delays" a signal with one or several events.

Infix variant for delay.

(*) to be read a1 -> a2 -> (b1, b2) where each argument may be wrapped along with a context.

The comb processes synchronizes multiple input signals and maps combinatorial functions on the values they carry.

This module exports constructors of type comb[1-8][1-4].

(*) to be read a1 -> a2 -> (b1, b2) where each argument may be wrapped along with a context.

The reconfig processes constructs adaptive processes, whose functional behavior "changes in time". Its first input is a signal carrying functions which is synchronized with all the other input signals. The output signal carry the results of mapping those functions at each synchronization/firing point.

This library exports constructors of type reconfig[1-8][1-4].

(*) meaning st1 -> st2 -> a1 -> a2 -> (st1,st2) where each argument may be wrapped along with a context.

(**) inferred from the prefixes of the signals passed as arguments. See the documentation for -<- for an explanation.

The state processes generate process networks corresponding to a simple state machine with "un-latched" outputs like in the graph above. In other words, the process starts with a state transition and outputs the next state as the first event.

This library exports constructors of type state[1-4][1-4].

(*) meaning st1 -> st2 -> a1 -> a2 -> (st1,st2) where each argument may be wrapped along with a context.

(**) inferred from the prefixes of the signals passed as arguments. See the documentation for -<- for an explanation.

The stated processes generate process networks corresponding to a simple state machine with "latched" outputs like in the graph above. As compared to state22, this process outputs the current state, and the state transition is observed from the second evaluation onwards. There exists a variant with 0 input signals, in which case the process is a signal generator.

This library exports constructors of type stated[0-4][1-4].

(*) meaning st -> a1 -> a2 -> st where each argument may be wrapped along with a context.

(**) meaning st -> (b1, b2) where each argument may be wrapped along with a context.

(***) inferred from the prefixes of the signals passed as arguments. See the documentation for -<- for an explanation.

The moore processes model Moore state machines.

This library exports constructors of type moore[1-4][1-4].

(*) meaning st -> a1 -> a2 -> st where each argument may be wrapped along with a context.

(**) meaning st -> a1 -> a2 -> (b1, b2) where each argument may be wrapped along with a context.

(***) inferred from the prefixes of the signals passed as arguments. See the documentation for -<- for an explanation.

The mealy processes model Mealy state machines.

This library exports constructors of type mealy[1-4][1-4].

\[ \mathtt{ctxt} (\Gamma_{\alpha}, \Gamma_{\beta}, \alpha^m \rightarrow \beta^n) = \Gamma \vdash \alpha^m \rightarrow \beta^n \]

Wraps a function with the context needed by some MoCs for their constructors (e.g. rates in SDF).

This library exports wrappers of type ctxt[1-8][1-4].

Utilities for extending the -* atom for dealing with tupled outputs. This library exports operators of form -*<[1-8].