Many large software systems originate from untyped scripting language code. While good for initial development, the lack of static type annotations can impact code-quality and performance in the long run. We present an approach for integrating untyped, or dynamically typed, code and typed code in the same system to allow an initial prototype to be smoothly evolved into an efficient and robust program. Our approach adds like types, a novel intermediate point between dynamic and static typing. Locally to their scope, like types variables are checked statically, but as they may be bound to dynamic values their usage is checked dynamically. Thus like types provide some of the benefits of static typing without substantially decreasing the expressiveness of the language. We provide a formal account of like types in a core object calculus and evaluate their applicability in the context of a new scripting language. 1.

Developers who write code in a statically typed language are denied the ability to obtain dynamic feedback by executing their code during periods when it fails to type-check. They are further confined to the static typing discipline during times in the development process where it does not yield the highest productivity. If they opt instead to use a dynamic language, they forgo the many benefits of static typing. We present a novel approach to giving developers the benefits of both static and dynamic typing, throughout the development process, and without the burden of manually separating their program into statically- and dynamically-typed parts. Our approach relaxes the static type system and provides a semantics for many type-incorrect programs. We implemented our approach in a publicly available tool, DuctileJ, for the Java language. In case studies, DuctileJ conferred benefits both during prototyping and during the evolution of existing code. Categories and subject descriptors: General terms: Keywords:

Abstract. Manifest contracts track precise properties by refining types with predicates—e.g., {x:Int | x> 0} denotes the positive integers. Contracts and polymorphism make a natural combination: programmers can give strong contracts to abstract types, precisely stating pre- and post-conditions while hiding implementation details—for example, an abstract type of stacks might specify that the pop operation has input type {x:α Stack | not (empty x)}. We formalize this combination by defining FH, a polymorphic calculus with manifest contracts, and establishing fundamental properties including type soundness and relational parametricity. Our development relies on a significant technical improvement over earlier presentations of contracts: instead of introducing a denotational model to break a problematic circularity between typing, subtyping, and evaluation, we develop the metatheory of contracts in a completely syntactic fashion, omitting subtyping from the core system and recovering it post facto as a derived property.

I would like to express my heartfelt gratitude to my two great mentors throughout my time at Willamette: Fritz Ruehr and John Lasseter. I also would like to extend my thanks to Genevieve Orr and Haiyan Cheng for their assistance and aid as thesis class leaders. Finally, I thank my family, for their encouragement, support, and love (and proofreading!) Numerous approaches to the problem of determining the correctness of computer programs have been proposed and implemented, such as dynamic and static type checking. Static typing enables earlier error checking and more e cient execution in many programs, while dynamic type systems allow for greater expressiveness and exibility. This paper presents a type system, hybrid typing, and a programming language utilizing it, Gnarly, that negotiate the space between static and dynamic typing by allowing the programmer to select which typing paradigm he or she wishes to use at the level of individual terms rather than entire languages. Furthermore, any program in Gnarly that is entirely static is provably type safe, and therefore is inherently more trustworthy than it would be otherwise. This results in a very robust language, capable of expressing a wider range of possible programs than any static language, but still retaining a far stronger degree of

Abstract. Developing rich web applications requires mastering different environments on the client and server sides. While there is considerable choice on the server-side, the client-side is tied to JavaScript, which poses substantial software engineering challenges, such as moving or sharing pieces of code between the environments. We embed JavaScript as a DSL in Scala, using Lightweight Modular Staging. DSL code can be compiled to JavaScript or executed as part of the server application. We use features of the host language to make client-side programming safer and more convenient. We use gradual typing to interface typed DSL programs with existing JavaScript APIs. We exploit a selective CPS transform already available in the host language to provide a compelling abstraction over asynchronous callback-driven programming in our DSL.