The paper introduces a higher-order synchronous data-flow language in which communication channels may themselves transport programs. This provides a mean to dynamically reconfigure data-flow processes. The language comes as a natural and strict extension of both Lustre and Lucid Synchrone. This extension is conservative, in the sense that a first-order restriction of the language can receive the same semantics. We illustrate the expressivity of the language with some examples, before giving the formal semantics of the underlying calculus. The language is equipped with a polymorphic type system allowing types to be automatically inferred and a clock calculus rejecting programs for which synchronous execution cannot be statically guaranteed. To our knowledge, this is the first higher-order synchronous data-flow language where stream functions are first class citizens. Categories and Subject Descriptors C.3 [Special-purpose and application-based systems]: Real-time and embedded systems; D.3.2 [Language classifications]: Data-flow languages; F.3.2 [Semantics of programming languages]: Operational semantics.

One of the appreciated features of the synchronous data-flow approach is that a program defines a perfectly deterministic behavior. But the use of the delay primitive leads to undefined values at the first cycle; thus a data-flow program is really deterministic only if it can be shown that such undefined values do not affect the behavior of the system.

Functional Reactive Programming (FRP) is an approach to reactive programming where systems are structured as networks of functions operating on time-varying values (signals). FRP is based on the synchronous data-flow paradigm and supports both continuous-time and discretetime signals (hybrid systems). What sets FRP apart from most other reactive languages is its support for systems with highly dynamic structure (dynamism) and higher-order reactive constructs (higher-order data-flow). However, the price paid for these features has been the loss of the safety and performance guarantees provided by other, less expressive, reactive languages. Statically guaranteeing safety properties of programs is an attractive proposition. This is true in particular for typical application domains for reactive programming such as embedded systems. To that end, many existing reactive languages have type systems or other static checksthatguaranteedomain-specificconstraints, suchasfeedbackbeingwell-formed(causality analysis). However, comparedwithFRP,theyarelimitedintheircapacitytosupportdynamism andhigher-orderdata-flow. Ontheotherhand, asestablishedstatictechniquesdonotsufficefor highly structurally dynamic systems, FRP generally enforces few domain-specific constraints, leaving the FRP programmer to manually check that the constraints are respected. Thus, there

types can be dened. Their syntax is inherited from Objective Caml and is reminded here.