Synchronous data-flow is a programming paradigm which has been successfully applied in reactive systems. In this context, it can be characterized as some class of static bounded memory data-flow networks. In particular, these networks are not recursively defined, and obey some kind of "synchronous" constraints (clock calculus). Based on Kahn's relationship between data-flow and stream functions, the synchronous constraints can be related to Wadler's listlessness, and can be seen as sufficient conditions ensuring listless evaluation. As a by-product, those networks enjoy efficient compiling techniques. In this paper, we show that it is possible to extend the class of static synchronous data-flow to higher order and dynamical networks, thus giving sense to a larger class of synchronous data-flow networks.

This paper presents an attempt to characterize synchronous stream functions within the framework of co-iteration and to use this characterization in building a compiler for (higher order and recursive) synchronous data-flow programs. First length-preserving functions are considered and we show that streams equipped with such functions form a Cartesian-closed category. Then this point of view is extended toward non length-preserving ones and we stress the use of "empty" values in handling this case. Finally, the implementation we did of this material in a synchronous stream package built on top of an ML-like language is briefly described.

Lustre is a data-flow programming language for reactive purposes, which has been given a synchronous operational semantic. Static checks called "clock calculus" restrict Lustre programs to those data-flow networks which can be executed synchronously. As a by-product of this restriction, Lustre programs enjoy efficient compiling techniques. Yet, due to its reactive origin, Lustre applies only to static networks. We show here, that both this operational semantic, and clock calculus can be extended toward accounting for general functional features : abstraction, application and recursion. This allows us to give sense to both higher order, and dynamical synchronous data-flow networks, which can thus be expected to share the same efficient compiling techniques. 1. Introduction 1.1. Some milestones in data-flow programming In the seventies, the Lucid language was proposed 2;1 as a way of overcoming the lack of efficency of functional languages by providing them with stream based iteration...

Introduction 1.1. Flots de donn'ees Dans les ann'ees 70, le langage Lucid a 'et'e propos'e [2, 1], pour pallier l'inefficacit'e des langages fonctionnels, en introduisant un style d'it'eration fond'e sur les suites de valeurs. A peu pr`es `a la meme 'epoque, Gilles Kahn montrait [13] que la s'emantique de r'eseaux de processus asynchrones et d'eterministes, communiquant par des files d'attente, pouvait se d'ecrire comme des syst`emes d"equations de suites, tr`es voisins des programmes Lucid. Parall`element, le concept d"evaluation paresseuse 'emergeait comme un outil pratique [10, 16], permettant d'introduire dans les langages de programmation des types de donn'ees infinis, comme les suites, et maintenant, des langages fonctionnels modernes, comme Lazy ML ou Haskell permettent d"ecrire tr`es facilement des programmes `a la Lucid ou `a la Kahn, en apportant de nombreuse facilit'es d'expression, tels la curryfic