This paper presents a new style of functional programming. The prevalent style is to define an algebraic datatype by its constructors, and functions on it by pattern matching. Programming with prototypes, on the other hand, is one of the prevalent styles of object-oriented programming. We fuse these two approaches to strive for the best of both. We propose a new functional language design for algebraic data types. Our proposal replaces the prevalent constructorbased definitional system by a prototype-based one. This is done in a way that does not affect one of the main strengths of functional programming: the use of higher-order functions defined by pattern matching on algebraic data types.

Embedded systems are often operating under hard real-time constraints, while at the same time being constrained by severe restrictions on power consumption. For such systems, robustness and reliability can be a question of life and death, which calls for rigorous system design and methodologies for validation. In this paper we advocate a design methodology for low-power, real-time systems, based on Timber; a pure reactive system model that allows for formal reasoning about various system properties. We outline how system specifications in Timber can be "compiled " into efficient standalone executables for general light-weight microcontroller based target platforms. Methods for resource analysis and implications to system dimensioning and validation are further discussed.

Mainstream object-oriented languages include a null value that inhabits every object type and that pervades programs. It exists both because the language semantics requires it in certain places and because it is the most convenient representation for common patterns, such as for sentinel values indicating failure. Safety requires implementations of these languages to insert run-time checks throughout programs to determine whether object references are null at each field lookup and method call. The ubiquity of null in object-oriented programs leads to severe engineering problems for programmers. First, the error messages issued by the run-time checks are typically not sufficiently informative to help the programmer find the source of the error. Second, the type systems in OO languages generally do not distinguish null from other values of (object) type, preventing the programmer from stating important invariants about the flow of null in the type system. Third, programmers ’ standard use of null as a sentinel does not unambiguously represent failures. To resolve or avoid these ambiguities, component authors must incorporate additional complexity into their interfaces, and this complexity can lead to subtle bugs. In this dissertation, we propose two changes to Java that allow us to completely remove the null value. Doing so addresses the problems above and provides significant engineering benefits to the programmer. Further, we demonstrate the practical feasibility of our proposal with a migration path that allows programmers to shift large codebases from Java to our new language, one class at a time. Acknowledgments I am deeply grateful to many people for the support and assistance they have provided during while I have worked on my dissertation. Chief among them are the members