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

Dependent types and multi stage programming have both been used, separately, as implementation techniques for programming languages. Each technique has its own advantages — with dependent types, we can verify aspects of interpreters and compilers such as type safety and stack invariants. Multi stage programming, on the other hand, can give the implementor access to underlying compiler technology; a staged interpreter is a translator. In this paper, we investigate how we might combine these techniques to implement a compiler for a resource-safe functional programming language for embedded systems. 1

Abstract. It is commonly believed that in dependently typed programming languages, the blurring of the distinction between types and values means that no type erasure is possible at run-time. In this paper, however, we propose an alternative phase distinction. Rather than distinguishing types and values in the compilation of EPIGRAM, we distinguish compile-time and run-time evaluation, and show by a series of program transformations that values which are not required at run-time can be erased. 1