We present a type theory for higher-order modules that accounts for many central issues in module system design, including translucency, applicativity, generativity, and modules as first-class values. Our type system harmonizes design elements from previous work, resulting in a simple, economical account of modular programming. The main unifying principle is the treatment of abstraction mechanisms as computational effects. Our language is the first to provide a complete and practical formalization of all of these critical issues in module system design.

A simple implementation of an SML-like module system is presented as a module parameterized by a base language and its type-checker. This implementation is useful both as a detailed tutorial on the Harper-Lillibridge-Leroy module system and its implementation, and as a constructive demonstration of the applicability of that module system to a wide range of programming languages.

MLis as tatically typed programming language thatis stwR for the consGHw[URY of boths mall and large programs "Programming in thes mall"is captured by StandardML Core language. "Programming in the large" is captured by Modules language that provides consN1N1N for organisw[ related Core language definitions intos elf-contained modules with desAA11w[ e interfaces While the Core is usA to expres details ofalgorithms and data sawRARNw[U Modules is use toexpres the overalla chitecture of asYG wares ysewA In Standard ML, modular programs mus have asANH1Yw hierarchicalslwN---HA1w the dependency between modules can never be cyclic. In particular, definitions of mutuallyrecursA e Core types and values that aris frequently in practice, can neverswN module boundaries This limitation compromisU modular programming, forcing the programmer to merge conceptually (i.e. architecturally) disural modules We prop os a practical and sndwN extensNY of the Modules language thatcaters for cyclic dependencies between both types andterms defined inswHAUYw modules OurdesEH leverages exissH features of the language,s upports stsU---H compilation of mutually recursw e modules and is eas to implement.

9706572, and the US Air Force under grant F19628-95-C-0050 and a generous fellowship. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of any sponsoring institution, the U.S. government or any other entity.

Component-based programming is currently carried out using mainstream object-oriented languages. These languages have to be used in a highly disciplined way to guarantee flexible component composition and extensibility. This paper investigates abstractions for component-oriented programming on the programming language level. We propose a simple prototype-based model for first-class components on top of a class-based object-oriented language. The model is formalized as an extension of Featherweight Java. Our calculus includes a minimal set of primitives to dynamically build, extend, and compose software components, while supporting features like explicit context dependencies, late composition, unanticipated component extensibility, and strong encapsulation. We present a type system for our calculus that ensures type-safe component definition, composition, and evolution.

. Modules and linking are usually formalized by encodings which use the -calculus, records (possibly dependent), and possibly some construct for recursion. In contrast, we introduce the m-calculus, a calculus where the primitive constructs are modules, linking, and the selection and hiding of module components. The m-calculus supports smooth encodings of software structuring tools such as functions (- calculus), records, objects (&-calculus), and mutually recursive definitions. The m-calculus can also express widely varying kinds of module systems as used in languages like C, Haskell, and ML. We prove the mcalculus is confluent, thereby showing that equational reasoning via the m-calculus is sensible and well behaved. 1 Introduction A long version of this paper [43] which contains full proofs, more details and explanations, and comparisons with more calculi (including the calculus of Ancona and Zucca [4]), is available at http://www.cee.hw.ac.uk/~jbw/papers/. 1.1 Support f...

ML-style modules are valuable in the development and maintenance of large software systems, unfortunately, none of the existing languages support them in a fully satisfactory manner. The official SML'97 Definition does not allow higher-order functors, so a module that refers to externally defined functors cannot accurately describe its import interface. MacQueen and ToRe [26] extended SML'97 with fully transparent higher-order functors, but their system does not have a type-theoretic semantics thus fails to support fully syntactic signatures. The systems of manifest types [19, 20] and translucent sums [12] support fully syntactic signatures but they may propagate fewer type equalities than fully transparent functors. This paper presents a module calculus that supports both fully transparent higher-order functors and fully syntactic signa- tures (and thus true separate compilation). We give a simple typetheoretic semantics to our calculus and show how to compile it into an F,-like )-calculus extended with existential types.

Although the functional programming language Haskell has a powerful type class system, users frequently run into situations where they would like to be able to define or adapt instances of type classes only after the remainder of a component has been produced. However, Haskell's type class system essentially only allows late binding of type class constraints on free type variables, and not on uses of type class members at variable-free types. In the current paper we propose a language extension that enhances the late binding capabilities of Haskell type classes, and provides more flexible means for type class instantiation. The latter is achieved via named instances that do not participate in automatic context reduction, but can only be used for late binding. By combining this capability with the automatic aspects of the Haskell type class system, we arrive at an essentially conservative extension that greatly improves flexibility of programming using type classes and opens up new structuring principles for Haskell library design. We exemplify our extension through the sketch of some applications and show how our approach could be used to explain or subsume other language features as for example implicit parameters. We present a typed λ-calculus for our extension and provide a working prototype type checker on the basis of Mark Jones' "Typing Haskell in Haskell".

Modules and linking are usually formalized by encodings which use the lambda calculus, records (possibly dependent), and possibly some construct for recursion. In contrast, we present the m-calculus, a calculus where the primitive constructs are modules, linking, and the selection and hiding of module components. In addition to supporting equational reasoning about modules and linking, the m-calculus allows smooth encodings of software structuring tools such as the lambda calculus, mutually recursive definitions, records (including operations like extension and concatenation), and objects. The m-calculus is extremely well behaved --- we show not only that the m-calculus is confluent but also that it satisfies the strong finite developments property.

This thesis is about a framework for elaborating and interpreting module language constructs at compile time in such a way that (1) arbitrary compile time information about declared identifiers of a module may be propagated to other modules and (2) no code is generated for module language constructs. The framework for interpreting module language constructs is called static interpretation. More information about referenced identifiers than can be obtained from programmer provided interfaces is necessary for analyses such as region inference. Further, many other analyses improve significantly from availability of analysis specific information about referenced identifiers. Static interpretation facilitates intermodule optimisation, yet, it still supports a variant of separate compilation called cut-off incremental recompilation.