The programming language Standard ML is an amalgam of two, largely orthogonal, languages. The Core language expresses details of algorithms and data structures. The Modules language expresses the modular architecture of a software system. Both languages are statically typed, with their static and dynamic semantics specified by a formal definition.

In this dissertation I argue that modal type systems provide an elegant and practical means for controlling local resources in spatially distributed computer programs. A distributed program is one that executes in multiple physical or logical places. It usually does so because those places have local resources that can only be used in those locations. Such resources can include processing power, proximity to data, hardware, or the physical presence of a user. Programmers that write distributed applications therefore need to be able to reason about the places in which their programs will execute. This work provides an elegant and practical way to think about such programs in the form of a type system derived from modal logic. Modal logic allows for reasoning about truth from multiple simultaneous perspectives. These perspectives, called "worlds," are identified with the locations in the distributed program. This enables the programming language to be simultaneously aware of the various hosts involved in a program, their

There has been much work in recent years on extending ML with recursive modules. One of the most difficult problems in the development of such an extension is the double vision problem, which concerns the interaction of recursion and data abstraction. In previous work, I defined a type system called RTG, which solves the double vision problem at the level of a System-F-style core calculus. In this paper, I scale the ideas and techniques of RTG to the level of a recursive ML-style module calculus called RMC, thus establishing that no tradeoff between data abstraction and recursive modules is necessary. First, I describe RMC’s typing rules for recursive modules informally and discuss some of the design questions that arose in developing them. Then, I present the formal semantics of RMC, which is interesting in its own right. The formalization synthesizes aspects of both the Definition and the Harper-Stone interpretation of Standard ML, and includes a novel two-pass algorithm for recursive module typechecking in which the coherence of the two passes is emphasized by their representation in terms of the same set of inference rules.

We propose F � , a calculus of open existential types that is an extension of System F obtained by decomposing the introduction and elimination of existential types into more atomic constructs. Open existential types model modular type abstraction as done in module systems. The static semantics of F � adapts standard techniques to deal with linearity of typing contexts, its dynamic semantics is a small-step reduction semantics that performs extrusion of type abstraction as needed during reduction, and the two are related by subject reduction and progress lemmas. Applying the Curry-Howard isomorphism, F � can be also read back as a logic with the same expressive power as second-order logic but with more modular ways of assembling partial proofs. We also extend the core calculus to handle the double vision problem as well as type-level and termlevel recursion. The resulting language turns out to be a new formalization of (a minor variant of) Dreyer’s internal language for recursive and mixin modules.

separate compilation. The system gives meaning to individual program fragments, called units. Units may depend on one another in a way specified by the programmer. A dependency may be mediated by an interface (the type of a unit); if so, the units can be compiled separately. Otherwise, they must be compiled in sequence. We also propose a methodology for programming in SMLSC that reflects code development practice and avoids syntactic repetition of interfaces. The language is given a formal semantics, and we argue that this semantics is implementable in a variety of compilers.

ML provides unusually powerful mechanisms for building programs from

Abstract. Boyer and Moore’s ACL2 theorem prover combines firstorder applicative Common Lisp with a computational, first-order logic. While ACL2 has become popular and is being used for large programs, ACL2 forces programmers to rely on manually maintained protocols for managing modularity. In this paper, we present a prototype of Modular ACL2. The system extends ACL2 with a simple, but pragmatic functional module system. We provide an informal introduction, sketch a formal semantics, and report on our first experiences. 1 A logic for Common Lisp, Modules for ACL2 In the early 1980s, the Boyer and Moore team decided to re-build their Nqthm theorem prover [1] for a first-order, functional sub-language of a standardized, industrial programming language: Common Lisp [2]. It was an attempt to piggyback theorem proving on the expected success of Lisp and functional programming. Although Common Lisp didn’t succeed, the ACL2 system became the most widely used theorem prover in industry. Over the past 20 years, numerous hardware companies and some software companies turned to ACL2 to verify critical pieces of their products [3]; by 2006, their contributions to the ACL2 regression test suite amounted to over one million lines of code. The ACL2 team received the 2005 ACM Systems Award for their achievement. 1 During the same 20 years, programming language theory and practice have evolved, too. In particular, programming language designers have designed, implemented, and experimented with numerous module systems for managing large functional programs [4]. One major goal of these design efforts has been to help programmers reason locally about their code. That is, a module should express its expectations about imports, and all verification efforts for definitions in a module should be conducted with respect to these expectations. Common Lisp and thus ACL2, however, lack a proper module system. Instead, ACL2 programmers emulate modular programming with Common Lisp’s namespace management mechanisms, or by hiding certain program fragments from the theorem prover. Naturally, the manual maintenance of abstraction boundaries is difficult and error prone. Worse, it forces the programmer to choose between local reasoning and end-to-end execution, as functions hidden from the theorem prover cannot be run.

This is a proposal for an extension to the Standard ML programming language to support separate compilation. The extension allows the programmer to write a program broken into multiple fragments in a way that would be compatible between different implementations. It also allows for the separate compilation of these fragments, for incremental recompilation strategies such as cut-off recompilation, and for a range of implementation strategies including whole-program compilation. The semantics of separate compilation is defined independent of the underlying semantic framework

Abstract. The understanding of programming paradigms has not been fully established yet, though many mainstream languages, e.g. C++, Java, ML, offer more than one paradigm. This paper addresses this understanding problem through a programming experiment: considering the classic object-oriented programming (OOP) design patterns as described in the GoF book [GHJV95], we systematically look at them from the viewpoint of other paradigms, in particular the generic modular and the functional paradigms. The main results of this experiment are: (1) Many OO design pattern intents are meaningful in a more general setting than OOP, and as such they are good candidates for exploring paradigms; (2) Many OO design patterns have counterparts in generic modular programming, but with different properties, in particular with respect to dynamic/static behavior and type safety; (3) Some OOP design patterns can be implemented by using basic functional programming, justifying the idea that functional programming can also be seen as a simplified OOP having its place in a OO language; (4) Some OOP design patterns seem definitely associated with the OOP paradigm, stressing the intrinsic properties of this paradigm. 1

Type-preserving compilation Compilation is type-preserving when each intermediate language is explicitly typed, and each compilation phase transforms a typed program into a typed program in the next intermediate language. Why preserve types during compilation? • it can help debug the compiler; • types can be used to drive optimizations; • types can be used to produce proof-carrying code; • proving that types are preserved can be the first step towards proving that the semantics is preserved [Chlipala, 2007].3 / 71 Type-preserving compilation A classic paper by Morrisett et al. [1999] shows how to go from System F to Typed Assembly Language, while preserving types along the way. Its main passes are: • CPS conversion fixes the order of evaluation, names intermediate computations, and makes all function calls tail calls; • closure conversion makes environments and closures explicit, and produces a program where all functions are closed; • allocation and initialization of tuples is made explicit; • the calling convention is made explicit, and variables are replaced with (an unbounded number of) machine registers. 4 / 71 Translating types In general, a type-preserving compilation phase involves not only a translation of terms, mapping t to �t�, but also a translation of types, mapping T to �T�, with the property: Γ ⊢ t: T implies �Γ � ⊢ �t � : �T� The translation of types carries a lot of information: examining it is often enough to guess what the translation of terms will be.5 / 71