Reactive Types. Jean-Pierre Talpin. Campus de Beaulieu, Rennes, France.

Similar documents
Synchronous Specification

SIGNAL A DECLAF:~TIVE LANGUAGE FOR SYNCHRONOUS PROGRAMMING OF REAL-TIME SYSTEMS

An Eect Type System for Modular Distribution of Dataow Programs

Argos: an automaton-based synchronous language

Programming Languages Third Edition

the application rule M : x:a: B N : A M N : (x:a: B) N and the reduction rule (x: A: B) N! Bfx := Ng. Their algorithm is not fully satisfactory in the

hal , version 1-7 Dec 2010

Synchronous reactive programming

Polyhedral Analysis for Synchronous Languages

Lecture Notes on Program Equivalence

Lambda Calculus and Type Inference

A Lift Controller in Lustre. (a case study in developing a reactive system) Leszek Holenderski

Proving the Correctness of Distributed Algorithms using TLA

Natural Semantics [14] within the Centaur system [6], and the Typol formalism [8] which provides us with executable specications. The outcome of such

The Esterel language

To be or not programmable Dimitri Papadimitriou, Bernard Sales Alcatel-Lucent April 2013 COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

to automatically generate parallel code for many applications that periodically update shared data structures using commuting operations and/or manipu

Type and Eect Systems via Abstract Interpretation. Jer^ome Vouillon. Pierre Jouvelot. CRI, Ecole des Mines de Paris. Abstract

Formal Verification of Synchronous Data-flow Program Transformations Toward Certified Compilers

Introduction 2 The first synchronous language (early 80 s) Gérard Berry and his team (École des Mines de Paris / INRIA Sophia-Antipolis) Imperative, s

Resource-bound process algebras for Schedulability and Performance Analysis of Real-Time and Embedded Systems

Lecture 2. The SCADE Language Data Flow Kernel. Daniel Kästner AbsInt GmbH 2012

Verification of Synchronous Data-flow Program Transformations Toward Certified Compilers.

UML Profile for MARTE: Time Model and CCSL

Simulink/Stateflow. June 2008

CS 242. Fundamentals. Reading: See last slide

Lambda Calculus. Type Systems, Lectures 3. Jevgeni Kabanov Tartu,

CS4215 Programming Language Implementation. Martin Henz

Efficient compilation of array iterators for Lustre

DRAFT for FINAL VERSION. Accepted for CACSD'97, Gent, Belgium, April 1997 IMPLEMENTATION ASPECTS OF THE PLC STANDARD IEC

Centre for Parallel Computing, University of Westminster, London, W1M 8JS

A Verification Approach for GALS Integration of Synchronous Components

XEVE, an ESTEREL Verification Environment

Proofs-Programs correspondance and Security

Algebraic Properties of CSP Model Operators? Y.C. Law and J.H.M. Lee. The Chinese University of Hong Kong.

Lecture Notes on Static and Dynamic Semantics

Com S 541. Programming Languages I

Mode-Automata based Methodology for Scade

Module 6. Knowledge Representation and Logic (First Order Logic) Version 2 CSE IIT, Kharagpur

Term Algebras with Length Function and Bounded Quantifier Elimination

Written Presentation: JoCaml, a Language for Concurrent Distributed and Mobile Programming

with an interpretation of the function and relation symbols occurring in. A valuation is a mapping : Var! D from the given innite set of variables Var

Module 3. Requirements Analysis and Specification. Version 2 CSE IIT, Kharagpur

Lectures 20, 21: Axiomatic Semantics

Embedded software design with Polychrony

CSCI-GA Scripting Languages

Reconciling Dierent Semantics for Concept Denition (Extended Abstract) Giuseppe De Giacomo Dipartimento di Informatica e Sistemistica Universita di Ro

Safe Reactive Programming: the FunLoft Proposal

Clock-directed Modular Code-generation for Synchronous Data-flow Languages

An Introduction to Lustre

Programming Languages

StateClock: a Tool for Timed Reactive Modules

Section 8. The Basic Step Algorithm

Meta-programming with Names and Necessity p.1

A Multiparadigm Language for Reactive Systems

1. true / false By a compiler we mean a program that translates to code that will run natively on some machine.

Principles of Real-Time Programming

Reinhard v. Hanxleden 1, Michael Mendler 2, J. Aguado 2, Björn Duderstadt 1, Insa Fuhrmann 1, Christian Motika 1, Stephen Mercer 3 and Owen Brian 3

Modeling Statecharts and Activitycharts as Signal Equations

CS-XXX: Graduate Programming Languages. Lecture 9 Simply Typed Lambda Calculus. Dan Grossman 2012

SAMOS: an Active Object{Oriented Database System. Stella Gatziu, Klaus R. Dittrich. Database Technology Research Group

Programming Embedded Systems

Introduction to Formal Methods

Topic 3: Propositions as types

Thunks (continued) Olivier Danvy, John Hatcli. Department of Computing and Information Sciences. Kansas State University. Manhattan, Kansas 66506, USA

On Meaning Preservation of a Calculus of Records

Synchronous Formal Design of Cyber-Physical Systems

Rance Cleaveland The Concurrency Factory is an integrated toolset for specication, simulation,

CVO103: Programming Languages. Lecture 5 Design and Implementation of PLs (1) Expressions

JOURNAL OF OBJECT TECHNOLOGY

Polychronous Design of Embedded Real-Time Applications

Program Design in PVS. Eindhoven University of Technology. Abstract. Hoare triples (precondition, program, postcondition) have

CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Dan Grossman Spring 2011

An Evolution of Mathematical Tools

A Type System for Functional Traversal-Based Aspects

Translation Validation for Synchronous Languages. A. Pnueli O. Shtrichman M. Siegel. Weizmann Institute of Science, Rehovot, Israel.

Flight Systems are Cyber-Physical Systems

Dependent Object Types - A foundation for Scala's type system

CLF: A logical framework for concurrent systems

A3. Programming Languages for Writing Safety-Critical Software

Let v be a vertex primed by v i (s). Then the number f(v) of neighbours of v which have

Lambda Calculus and Type Inference

Copyright (C) 1997, 1998 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for

Cyber Physical System Verification with SAL

proc {Produce State Out} local State2 Out2 in State2 = State + 1 Out = State Out2 {Produce State2 Out2}

Project IST , COLUMBUS. Design of Embedded Controllers for Safety Critical Systems. Deliverables DMM1 and DMM2

Semantic Subtyping. Alain Frisch (ENS Paris) Giuseppe Castagna (ENS Paris) Véronique Benzaken (LRI U Paris Sud)

Programming Languages for Real-Time Systems. LS 12, TU Dortmund

A Michael Jackson presentation. CSE503: Software Engineering. The following slides are from his keynote at ICSE 1995

The design of a programming language for provably correct programs: success and failure

A Boolean Expression. Reachability Analysis or Bisimulation. Equation Solver. Boolean. equations.

Do! environment. DoT

Chapter 2 Synchronous Programming: Overview

Provably Correct Software

SORT INFERENCE \coregular" signatures, they derive an algorithm for computing a most general typing for expressions e which is only slightly more comp

MIDTERM EXAM (Solutions)

Program Analysis: Lecture 02 Page 1 of 32

Synchronous Kahn Networks (ten years later)

Type checking. Jianguo Lu. November 27, slides adapted from Sean Treichler and Alex Aiken s. Jianguo Lu November 27, / 39

Higher-Order Conditional Term Rewriting. In this paper, we extend the notions of rst-order conditional rewrite systems

Transcription:

Reactive Types Jean-Pierre Talpin IRISA (INRIA-Rennes & CNRS URA 227) Campus de Beaulieu, 35000 Rennes, France E-mail: talpin@irisa.fr Abstract. Synchronous languages, such as Signal, are best suited for the design of dependable real-time systems. Synchronous languages enable a very high-level specication and an extremely modular implementation of complex systems by structurally decomposing them into elementary synchronous processes. Separate compilation in reactive languages is however made a dicult issue by global safety requirements. We give a simple and eective account to the separate compilation of reactive systems by introducing a specication as type paradigm for reactive languages: reactive types. Just as data-types describe the structure of data in conventional languages, reactive types describe the structure of interaction in synchronous languages. We dene an inference system for determining reactive types in the Signal language and show how to reconstruct adequate compile-time information on reactive programs by means of such specications. 1 Introduction A reactive system is a computer system which continuously reacts to its environment. Many industrial systems are reactive in nature: process control systems, monitoring systems, signal processing systems, communication protocols. Reactive systems are commonly characterized by critical requirements such as fast reaction time or bounded memory usage. Classical design tools for implementing reactive systems, such as real-time operating system or general-purpose concurrent languages (e.g. Ada), neither provide a global and formal view of the system (separated into tasks or services) nor preserve its determinism. Synchronous languages, such as Signal [3], Lustre [5] or Esterel [4], are specically designed to ease the development of reactive systems by providing both a formal view and a logical notion of concurrency preserving determinism: synchronous concurrency, where operations and communications are instantaneous. In a synchronous language, concurrency is meant as a way to logically decompose the description of a system into a set of elementary communicating processes. Interaction between concurrent components within the program is conceptually performed by broadcasting events. In practice, a synchronous program is usually translated into a circuit or into a monolythic automaton. The hypothesis of synchrony is translated into the requirement that the program reacts rapidly to its environment.

As a result, synchronous languages allow a very high-level specication and an extremely modular implementation of complex systems by structurally decomposing their functional components into elementary processes. Although modularity is a key advantages of synchronous languages, separate compilation is made a dicult issue by the requirements of proving global safety properties of the system. To enable separate compilation of the functional components of reactive systems while preserving their global integrity, we introduce the notion of reactive type. Just as data-types describe the structure of data in conventional languages, reactive types describe the structure of interaction in synchronous languages. In conventional languages, function types are the media enabling separate compilation of procedures in a program. Similarly, reactive types can be used as a medium for separately compiling reactive processes and assembling them to form complex systems. In this paper, we present an inference system which associates Signal programs to reactive types. We prove its correctness w.r.t. the dynamic semantics of Signal and show how to reconstruct adequate compile-time information on programs by means of reactive types. 2 An Overview of Signal Signal is an equational synchronous programming language: a Signal program is modularly organized into processes consisting of simultaneous equations on signals. In Signal, an equation is an elementary and instantaneous operation on input signals which denes an output. A signal is a sequence of values dened over a totally ordered set of instants. At any given instant, a signal x is either present or absent (its clock bx denotes the instants at which it is present). Syntax A process p is either an elementary equation, the synchronous composition p j p 0 of two processes p and p 0 or the declaration p=x of a local signal x in a process p. An equation instantaneously maps a signal x to a value v (e.g. an event, a boolean, an integer), to the previous value \y $1" of a signal y, to a synchronous operation f(y; z) on the signals y and z (e.g. an operation on booleans, on numbers), by merging two signals y and z or by sampling a signal y under a condition z. p ::= (p j p 0 ) synchronous composition j p=x encapsulation or scoping j x := v constant declaration j x := f(y; z) synchronous operation j x := y when z down-sampling j x := y default z deterministic merge j x := y $1 init v delay operation Fig. 1. Syntax of processes p in Signal

Dynamic Semantics The dynamic semantics of Signal, written p e p 0, presented in [3], outlined in the gure 2, describes how a process p evolves over time. A transition in the dynamic semantics denes an instant. Each instant is characterized by a set e of simultaneous events and by an instantaneous transition from a state p to a state p 0. The environment e associates a signal x to a value v when it is present (written x(v)) or to? when it is absent (written x(?)). p e p 00 p 0 e0 p 000 e \ e 0 e x(v) p? p 0 p j p 0 e[e0 p 00 j p 000 p=x e p 0 =x x:= v x:= f(y; z) x(v) x:= v x(?) y(?) z(?)??????? x:= f(y; z) x:= f(y; z) x(f (v;v 0 )) y(v) z(v 0 )?????????? x:= f(y; z) x(?) y(?) x:= y $1 init v???? x:= y $1 init v x:= y $1 init v x(v) y(v 0 )???? x:= y $1 init v 0 x := y when z x(?) y(?)???? x:= y when z x:= y when z x:= y when z x:= y when z x:= y default z x:= y default z x:= y default z x(?) y(v) z(?)??????? x:= y when z x(v) y(v) z(t)?????? x:= y when z x(?) y(v) z(f )??????? x:= y when z x(?) y(?) z(?)??????? x:= y default z x(v) y(v)??? x:= y default z x(v) y(?) z(v)??????? x:= y default z Fig. 2. Dynamic semantics of Signal Parallel composition p j p 0 synchronizes the events e and e 0 produced by p and p 0. The relation e \ e 0 is dened i e(x) = e 0 (x) for all x in dom(e) \ dom(e 0 )). A synchronous operation x := f(y; z) instantaneously computes the value of f by y and z and outputs it to the signal x. A delay x := y $1 init v stores the value v 0 of y and outputs the previous value v to x. A merge x := y default z outputs the value of y to x when y is present or the value of z otherwise. A sampling x := y when z outputs y to x when z is present and true. When all the inputs of an equation are absent, a transition takes place but no value is given to its output. Example 1. As a rst example, we consider the stream of positive integers nat as the synchronous composition of two equations. The rst equation denes the local signal y initially as 0 and then as the previous value of x. The second equation denes x as y plus 1. process nat (out integer x) = ( y := x $ 1 init 0 x := y + 1 ) / y At each instant n, both equations are executed simultaneously (this explains why x n is dened by x n?1 + 1 and not by x := x + 1 as in a conventional programming language). Notice that the rate of the execution of the program is not constrained by an external input signal. The schedule of its execution will actually depend on the use of x in the environment.

Data-Flow Graphs As outlined in the previous example, the compilation of Signal requires the static resolution of temporal relations between signals. In order to ensure the respect of synchronization constraints expressed in programs. c ::= bx j bxnby j [x] j c ^ c j c _ c clock g ::= ; j (bx = c) j (x c y) j g [ g 0 j 9x:g graph Fig. 3. Clocks c and conditional data-ow graphs g The control model of a Signal program is represented by a set of temporal relations bx = c between signal clocks bx and expression clocks c. The clock bx denotes the instants when x is present. The clock [x] denotes the presence of a boolean signal x with the value true. The clock bxnby denotes the instants where x is present and y absent. The formula c ^ c 0 and c _ c 0 denote the conjunction and disjunction of the instants c and c 0. The data-ow model of a program is represented by a graph composed of arrows x c y. An arrow x c y denotes a dependency from x to y at the clock c. References to local signals x in a graph g are bound by existential quantication 9x:g. We write fv(g) and bv(g) for the free and bound signals of g. We write 9y:g = 9x:(g[x=y]) and (9x:g 0 ) [ g = 9x:(g [ g 0 ) i x 62 fv(g) [ bv(g). We identify 9y:(9x:g) and 9x:(9y:g). Clock Calculus The analysis which determines the conditional data-ow graph g of a Signal program is called the clock calculus (introduced in [3], outlined in the gure 4). Using the graph g produced by clock calculus, the Signal compiler generates an optimal compile-time scheduling of the actions specied in the source program by hierarchizing the temporal relations in g and by ruling the execution of the program using its master clock [2]. Using the graph g, causal dependencies in the source program can easily be detected as constrained boolean conditions on signals (e.g. [x] = ^y) or cyclic data dependencies (e.g. x c x). x := v ) ; x := y $1 )? ^x = ^y x := y when z ) y [z] x ^x = ^y ^ [z] y ^x x; z ^x x x := f(y; z) ) ^x = ^y; ^x = ^z p ) g p=x ) 9x:g y ^y x := y default z ) x; z ^zn^y x ^x = ^y _ ^z p ) g p 0 ) g 0 p j p 0 ) g [ g 0 Fig. 4. Clock calculus p ) g

Example 2. In the case of the process nat, for instance, the clock calculus determines the temporal relation between x and y: bx = by (i.e. x and y are synchronous) and the data dependency y ^x x (i.e. the computation of x depends on the value of y). Notice that no external constraint exists on the signal x. process nat (out integer x) = ( y := x $ 1 init 0 ^x = ^y x := y + 1 y x ) / y 9 y Separate Compilation As the conditional data-ow graph of a Signal program is the essential medium for checking its safety and compiling it, separate compilation is made a dicult issue by the requirements of proving global safety properties. To illustrate this issue, let us consider a typical situation raised in the following process denition. Let copy be the process which assigns the value of its input signals a and b to its output signals x and y: (x:=a j y:=b). process copy (in a, b; out x, y) = ( x := a a x y := b b y ) To compile it, the Signal compiler has the choice between scheduling either x:=a; y:=b or y:=b; x:=a. However, the appropriate choice depends on the way the process is invoked. For instance, in the case below, only the rst scheduling (i.e. u:=w; v:=u) is correct (the second dead-locks). (u,v) := copy(w,u) w u v Fortunately, this problem can be solved by determining the data dependencies a x and b y between (a,b) and (x,y) where copy is dened and the actual data dependencies w u and u v between u, v and w where copy is used. In a situation of separate compilation that information is however not directly accessible by the textual denition of the process copy. In this case, the explicit declaration of the temporal and data-ow relations between signals appears to be necessary for solving the issue of separate compilation. 3 Reactive Types A common justication of typing in conventional programming languages is that \well-typed programs do not go wrong" [Milner]. Our reactive type system provides simple and eective means for making similar statements on reactive systems. Just as data-types abstract the representation of data, reactive types abstract the interaction structure of processes. The denition of our reactive type system incorporates both a calculus for reasoning on the interaction structure of Signal programs and a way to check basic safety requirements.

In the type system of the gure 5, a signal x is an atomic reactive type. A constant has type?. A delay operation on a signal of type t has type t. The down-sampling of a signal of type t by a signal of type t 0 has type t t 0. The deterministic merge between two signals of types t and t 0 has type t t 0. An equation of input type t and of output signal x has type t! x. The recursive (resp. local) denition of x in t is written x:t (resp. 9x:t). The synchronization of two signals of types t and t 0 is written t t 0, its composition t t 0. Fig. 5. Reactive types t t ::=? constant j x signal j t delay j t t 0 sample j t t 0 merge j t! x j x:t j 9x:t j t t 0 j t t 0 equation recursion scoping synchronization composition In the gure 6, we dene the inference system for reactive types. It is written p:t and associates a Signal process p to its reactive type t. x := v :?! x x := y $1 : (y)! x x := y when z : (y z)! x x := y default z : (y z)! x x := f(y; z) : (x (y z)) ((y z)! x) p:t p 0 : t 0 p j p 0 : t t 0 p:t p=x: 9x:t Fig. 6. Inference system p:t In order to identify reactive types which denote identical interaction structures (formally, in the sense of denition 2 and of theorem 3), we equip our type system with algebraic rules. Types constructed with, and are sets with neutral element? and satisfy the distribution rules of the gure 7.? =? (t) = t (x:t) = x:(t) (t t 0 ) = (t) (t 0 ) (t t 0 ) = (t) (t 0 ) (t t 0 ) = (t) (t 0 ) t (t 0?) = t (t 0 t 0 ) = t t 0 t (t 0?) = t (t 0 t 0 ) = t (t (t 0 t 00 )) = (t (t 0 t 00 )) (t (t 0 t 00 )) = (t t 00 ) (t 0 t 00 ) (t t 00 ) t (t 0 t 00 ) = (t t 0 ) (t t 00 ) (t 0 t 00 ) t = (t 0 t) (t 00 t) t t = t t (t 0 t 00 ) = (t t 0 ) (t t 00 ) (t 0 t 00 ) t = (t 0 t) (t 00 t)?? =? Fig. 7. Distribution of t, t t 0 and t t 0

The signal x referenced in a type x:t or 9x:t is bound to t. Bound signals x satisfy the scoping rules of the gure 8. We write fv(t) (resp. bv(t)) for the set of free (resp. bound) signals of a type t. We write t x = t ((t 0x)(t 00 x))2t (t 0 t 00 ) for the completion of t w.r.t. x [to show, e.g., that y z = 9x:((?! x) (x y) (x z))]. x:t = t[x:t=x] x 62 fv(t) x:t = t x 62 fv(t) y:t = x:(t[x=y]) x 62 fv(t) t (x:t 0 ) = x:(t t 0 ) 9x:(t (t 0! x)) = tx[x:t 0 =x] x 62 fv(t) 9x:t = t x 62 fv(t) 9y:t = 9x:(t[x=y]) x 62 fv(t) t (9x:t 0 ) = 9x:(t t 0 ) Fig. 8. Scoping properties of reactive types t The algebraic properties of reactive types give rise to the denition of a normal form (denition 1). Every type t obtained from the inference system p: t of the gure 6 can be represented in normal form. Denition1. The normal form of a reactive type is t ::= t 00 t 00 j t 0! x j tt where t 0 and t 00 are of the form t 0 ::=? j t 00 t 00 and t 00 ::= x j x j t 00 t 00 j t 00 t 00 j x:t 00. Example 3. To demonstrate the use of our reactive type system, let us consider a denition of the explicit synchronization of two signals x and y in Signal. process synchro (in x; out y) = (x y) z ( z := ((x = x) = (y = y)) (x y)! z ) / z 9z The inference system of the gure 6 determines the interaction structure of the process synchro: 9z:((x y) z) ((x y)! z)). The algebraic rules of our reactive type system allow us to dene its normal form as 9z:(((x y) z) ((x y)! z)) = (x y) (z:(x y)) = (x y) (x y) = x y. Safety The safety of a process p of reactive type t can be checked using the function A. A x (t) checks that their is no cycles from the input type t and the output signal x of an equation. The function A(t) checks for the absence of cycles in t. The function C(t) checks that the synchronizations in t do not incur causal dependencies. A x(?) A x(t) A(t) A(9x:t) x 6= y A x(y) A x(t) A x(t) A x(t t 0 ) A(t 0 [t=x]) A((t! x) t 0 ) A x(t) A x(t 0 ) A x(t t 0 ) C(t) A(t) A x(t) A x(t 0 ) A x(t t 0 ) C(t t 0 ) C(t 00 ) C((t t 0 ) t 00 ) A x(t) A y(t) A x(y:t) t 0 6= t 00 t C(t t 0 ) Fig. 9. Property A(t)

Example 4. To give an example of causal dependency and illustrate the combined use of our inference system and of the functions A and C, we consider the process sample which computes a value w given two inputs u and v and a condition on them. process sample (in integer u, v; out integer w) = ( x := u < v y := u when x w := v + y ) / logical x; integer y The process sample uses two local signals x and y. Its reactive type declares the signals synchronous to w and the interaction structure leading to w: ((u v) w) ((v (u (u v)))! w) The function C detects that the process sample requires: u (u u). By reconstructing the clock relations of the process sample (as shown in the gure 10), one observes that the constraints ^u = ^v and ^u ^ [x] = ^v (where ^x = ^u _ ^v) cannot be satised simultaneously. This means that the process sample deadlocks if u and v are present and if the condition x is simultaneously false. Graph Reconstruction In a conventional programming language, typing is a medium which enables the separate compilation of the functions in a program. Types allow to determine the representation of data in a program at compile-time. In a synchronous language, clock relations and data-ow dependencies allow to determine the appropriate scheduling of the actions specied as a system of simultaneous equations. This information can be reconstructed given the reactive type of a process.? [[?]]y = 9x:(^x; ;) [[x]] y = (^x; x ^x y)? [[x]] y = (^x; ;) [[t]] y = 9x 1::n :(c; g)??? [[x:t]] y = 9x; x 1::n:(c; (^x = c) [ g n g x ) [[t]] y = 9x 1::n :(c; g)? [[t 0 ]] y = 9xn+1::m :(c 0 ; g 0 )???? [[t t 0 ]] y = 9x 1::m:(c _ c 0 ; g [ g 0 ) [[t]] y = 9x 1::n :(c; g)? [[t 0 ]] y = 9xn+1::m :(c 0 ; g 0 )???? [[t t 0 ]] y = 9x; x 1::m:(c ^ [x]; ^g [ ^g0 [ (^x = c 0 c ) [ 00 ^[x] (z?? y)z c00 ) y2g? [[t]] y = 9x 1::n:(c; g) [[t 0 ]] y = 9xn+1::m :(c 0 ; g 0 )???? [[t t 0 ]] y = 9x 1::m :(c _ c 0 ; g [ ^g0 [ (z c00 nc? y)z c00 y2g 0) [[t]] x = 9x 1::n :(c; g)? [[t 0 ]] x = 9xn+1::m :(c 0 ; g 0 )?? t t 0 = 9x:(^x = c; ^x = c 0 ) [ ^g [ ^g0 Fig. 10. Graph of a reactive type t in normal form t = g t 0 = g 0?? t t 0 = g [ g 0 [[t]] x = 9x 1::n:(c; g)??? t! x = (^x = c) [ g

In the gure 10, the term [[t]] x = 9x 1::n :(c; g) associated to an expression type t consists of a sequence of bound signals x 1::n (introduced during the reconstruction), of a clock c (the clock of the expression) and of a graph g. We write t for the conditional data-ow graph reconstructed from the reactive type t of a Signal process. We write ^g for the set of clock equations ^x = c in a graph g. We write g x = fx c y 2 gg and g x = fy c x 2 gg. 4 Formal Properties Adequacy We show that the reconstruction of the clock and data dependency relations t of a reactive type t is adequate with respect to the clock calculus of Signal (gure 4) in that it is equivalent (in the sense of the denition 2) to the graph g inferred from a Signal process. Denition2. g ' g 0 i there exists a renaming of bv(g) and bv(g 0 ) s.t. ^g, ^g0 and s.t. there exists x c0 y 2 g 0 (resp. g) s.t. g ) (c = c 0 ) for all x c y 2 g (resp. g 0 ). In the above denition, we write ^g, ^g0 i ^g ) ^g0 and ^g0 ) ^g. We write ^g ) ^g0 i for all (^x = c) 2 ^g0, g ) (^x = c). We write g for the transitive closure gj bv(g) of the data-ow dependencies in the graph g w.r.t. its bound signals. We write gj x for the closure of the graph g with respect to x (notice that gj x does not necessarily eliminates all references to x, e.g., when ^x = c 2 g). gj x = ((gng x )ng x ) [ (y c^c0 z) c c (y 0 x;x z)2g xg x The theorem 3 says that the conditional dependency graph t reconstructed from the type t of a process p is equivalent to the transitive closure of the graph g determined by the standard clock calculus of Signal. Theorem 3 (Adequacy). If p:t and p ) g then g ' t. Proof. The proof is by induction on the structure of p using the rules dened in the gures 4 and 6. It uses the fact that the equivalence rules dened in the gure 7 and 8 preserve the denition 2 (i.e. if t = t 0 then t ' t 0 ). Soundness The soundness of our reactive type system with respect to the dynamic semantics of Signal is formulated as a subject reduction theorem. It says that the reactive type of a process is preserved during execution. We write \e : t w.r.t. p" when the events e are consistent with the type t of a process p. We write out(p) for the output signals of p and in(p) for fv(p) n out(p). Denition4. e : t w.r.t. p i, for all x(v) 2 e out(p), t 0! x 2 t and, for all x(v) 2 e in(p), there exists (t 0 t 00 ) 2 t or t 0! y 2 t s.t. x 2 fv(t 0 ). Theorem 5 (Soundness). If p e p 0 and p:t then e:t w.r.t. p and p 0 : t. Proof. The proof is by induction on the structure of p using the rules dened in the gures 2 and 6. It uses the fact that the equivalence rules dened in the gure 7 and 8 preserve the property of the denition 4.

Subtyping An account to the expressiveness of reactive types is that a notion of renement can be introduced in our inference system in terms of a subtyping relation. Renement is an important feature of the programming methodology of Signal. It can be dened by the relation g v g 0 as follows. Denition6. For any graph g, g v g[(x c y) and g v g[(^x = c) i g[(^x = c) ) g. A graph g satises g v g 0 if it has less clock constraints and less data dependencies than g 0. By inducing less clock and data dependencies, the specication g preserves the safety requirements related to the specication g 0. In particular, it ensures that no boolean condition [x] in g 0 is constrained and that no data dependency in g 0 is turned into a causal dependency (i.e a cycle x c x). In our inference system, subtyping can be introduced by means of an additional rule: if the process p has type t and t v t 0, then p also has type t 0. The subtyping relation is dened by: Denition7. t v t 0 i there exists t 00 s.t. t 0 = t t 00 and A(t 0 ). Example 5. To illustrate the use of subtyping, let us reconsider the example of the process copy. The denition of copy has type t = (a! x) (b! y) and its use has type t 0 = (w! u) (w! v). process copy (in a, b; out x, y) = (x:=a y:=b) (a! x) (b! y) (u,v) := copy(w,u) (w! u) (u! v) In order to separately compile the process copy in such a way to support the scheduling required by its usage in the statement (u,v) := copy(w,u) of the program, one may use the subtyping relation t 0 v t 00 in order to give the type t 00 = t 0 (x! b) explicitly to the denition of copy. This would enforce copy to be compiled as x:=a; y:=b and to be compatible with its use. To probe further by making an analogy to data-types, the process copy can be given polymorphic type 8; 0 :( 0 )! ( 0 ) (using a polymorphic type inference algorithm such as that presented in [9]). Similarly, the explicit assignment of the \less general" type (intbool)! (intbool) to copy enforces x and a (resp. y and b) to be represented as integers (resp. boolean) by the Signal compiler and to be used as such in the rest of the program. 5 Related Work The denition of type systems for describing interaction in synchronous programming languages has been the subject of recent investigations. In [6], T. Jensen gives a model of Signal using abstract interpretation and shows how to derive the clock calculus of [3] from this interpretation. In [1], S. Abramsky & al. give a categorical model of synchronous interaction in Signal and Lustre and propose a related type system. In contrast to reactive types both type systems do not satisfy an adequacy theorem (in the sense of theorem 3): they do not permit to reconstruct all the compile-time information the Signal compiler requires. Nonetheless, we believe that reactive types could be given an interpretation in the interaction category.

6 Conclusion We have introduced a notion of reactive type for synchronous languages. Just as data-types describe the structure of data in conventional languages, reactive types describe the structure of interaction in reactive languages. We have introduced an inference system to associate Signal programs to reactive types in the same way types are associated to functions in the lambda-calculus. Using reactive types, we have shown how to reconstruct the information needed for compiling Signal programs and stated the correctness of our inference system with respect to the dynamic semantics of Signal. We have introduced a notion of subtyping, which allows the gradual specication of Signal programs using reactive types. Although our presentation was focused on Signal, we believe that reactive types could equally be used in other synchronous languages, such as Lustre or Esterel, to type synchronous interaction. References 1. S. Abramsky, S. Gay and R. Nagarajan. Interaction categories and the foundations of typed concurrent programming. In Proceedings of the 1994 Marktoberdorf Summer School. NATO ASI Series, Springer Verlag, 1995. 2. T. P. Amagbegnon, L. Besnard and P. Le Guernic. Implementation of the data-ow synchronous language Signal. In Proceedings of the 1995's ACM Conference on Programming Language Design and Implementation, p. 163{173. ACM, 1995. 3. A. Benveniste, P. Le Guernic and C. Jacquemot. Synchronous programming with events and relations: the Signal language and its semantics. Science of Computer Programming, 16:103{149, 1991. 4. G. Berry and G. Gonthier. The Esterel synchronous programming language: design, semantics, implementation. In Science of Computer Programming, 19:87{152, 1992. 5. N. Halbwachs, P. Caspi, P. Raymond and D. Pilaud. The synchronous data-ow programming language Lustre. In Proceedings of the IEEE, 79(9), p. 1305{1320. IEEE Press, September 1991. 6. T. Jensen. Clock analysis of synchronous data-ow programs. In Proceedings of the 1995's ACM Conference on Partial Evaluation and Program Manipulation. ACM, 1995. 7. M. Le Borgne. Systemes dynamiques polynomiaux sur les corps nis. Ph. D. Thesis, Universite de Rennes I, September 1991. 8. O. Maes and P. Le Guernic. Distributed implementation of Signal: scheduling and graph clustering. In 3rd. International Symposium on Formal techniques in Real-Time and Fault-Tolerant Systems, p. 547{566. LNCS no. 863, Springer Verlag, 1995. 9. D. Nowak, J.-P. Talpin, T. Gautier, and P. Le Guernic. An ML-like module system for the synchronous language Signal. Submitted for publication, December 1996.

A Last Example In this appendix, we consider a reasonably scaled Signal process which makes extensive use of constants, of down-sampling and of feed-back loops using delayed signals. process level (in event fill; out logical empty) = ( synchro (when m = 0, fill) n := (10 when fill) default (m - 1) m := n $ 1 empty := when (n = 0) default (not fill) ) / integer n, m init 0 The process level models a system similar to a water reservoir. The input event ll signals that the resource is lled. The local integer variable n measures the current level of water. At each ll event, the level is set to the maximum 10. Then, the level gradually decreases until it reaches 0. In this case, the system outputs the value true to the signal empty. Let us dene f for ll and e for empty. Then, the process level has reactive type: 9n:((((? f) n)! n) (f (? n)) ((? n) f)! e As a matter of comparison, the transitive closure of the graph inferred by the clock calculus of Signal (gure 4) for the process level is: 0 1 ^f = ^c 1 ^ [c 2 ] B 9c 1;::5; m: @ ^e = ( ^c 4 ^ [c 5 ]) _ ^f C A s:t: ^c 2 = ^c 5 = ^m = ( ^c 3 ^ ^f) _ ^m f ^fn( c^ 4 ^[c 5 ])???? e This article was processed using the LaT E X macro package with LLNCS style