The views and conclusions contained in this document are those of the authors and should not be interpreted as

The design of a module system for constructing and main- taining large programs is a difficult task that raises a number of theoretical and practical issues. A fundamental issue is the management of the flow of information between program units at compile time via the notion of an interface. Experience has shown that fully opaque interfaces are awkward to use in practice since too much information is hidden, and that fully transparent interfaces lead to excessive interdependencies, creating problems for maintenance and separate compilation. The "sharing" specifications of Standard ML address this issue by allowing the programmer to specify equational relationships between types in separate modules, but are not expressive enough to allow the programmer com- plete control over the propagation of type information be- tween modules.

This paper presents a variant of the SML module system that introduces a strict distinction between abstract types and manifest types (types whose de nitions are part of the module speci cation), while retaining most of the expressive power of the SML module system. The resulting module system provides much better support for separate compilation. 1

The views and conclusions contained in this document are those of the authors and should not be interpreted as representing o cial policies, either expressed or implied, of the Advanced Research Projects Agency or the U.S. Government. Any opinions, ndings, and conclusions or recommendations expressed in this material are those of the We study the typing properties of closure conversion for simply-typed and polymorphic-calculi. Unlike most accounts of closure conversion, which only treat the untyped-calculus, we translate well-typed source programs to well-typed target programs. This allows later compiler phases to take advantage of types for representation analysis and tag-free garbage collection, and it facilitates correctness proofs. Our account of closure conversion for the simply-typed language takes advantage of a simple model of objects by mapping closures to existentials. Closure conversion for the polymorphic language requires additional type machinery, namely translucency in the style of Harper and Lillibridge's module calculus, to express the type of a closure.

Compilers for monomorphic languages, such as C and Pascal, take advantage of types to determine data representations, alignment, calling conventions, and register selection. However, these languages lack important features including polymorphism, abstract datatypes, and garbage collection. In contrast, modern programming languages such as Standard ML (SML), provide all of these features, but existing implementations fail to take full advantage of types. The result is that performance of SML code is quite bad when compared to C. In this thesis, I provide a general framework, called type-directed compilation, that allows compiler writers to take advantage of types at all stages in compilation. In the framework, types are used not only to determine efficient representations and calling conventions, but also to prove the correctness of the compiler. A key property of typedirected compilation is that all but the lowest levels of the compiler use typed intermediate languages. An advantage of this approach is that it provides a means for automatically checking the integrity of the resulting code. An important

We present a variant of the Standard ML module system where parameterized abstract types (i.e. functors returning generative types) map provably equal arguments to compatible abstract types, instead of generating distinct types at each application as in Standard ML. This extension solves the full transparency problem (how to give syntactic signatures for higher-order functors that express exactly their propagation of type equations), and also provides better support for non-closed code fragments.

The FLINT project at Yale aims to build a state-of-the-art systems environment for modern typesafe languages. One important component of the FLINT system is a high-performance type-directed compiler for SML'97 (extended with higher-order modules). The FLINT/ML compiler provides several new capabilities that are not available in other type-based compilers: ffl type-directed compilation is carried over across the higher-order module boundaries; ffl recursive and mutable data objects can use unboxed representations without incurring expensive runtime cost on heavily polymorphic code; ffl parameterized modules (functors) can be selectively specialized, just as normal polymorphic functions; ffl new type representations are used to reduce the cost of type manipulation thus the compilation time. This paper gives an overview of these novel aspects, and a preliminary report on the current status of the implementation. 1 Introduction The FLINT project at Yale aims to build a state-of-the-ar...

Abstract not found

A hierarchical module system is an effective tool for structuring large programs. Strictly hierarchical module systems impose an acyclic ordering on import dependencies among program units. This can impede modular programming by forcing mutually-dependent components to be consolidated into a single module. Recently there have been several proposals for module systems that admit cyclic dependencies, but it is not clear how these proposals relate to one another, nor how one might integrate them into an expressive module system such as that of ML. To address this question we provide a type-theoretic analysis of the notion of a recursive module in the context of a "phase-distinction" formalism for higher-order module systems. We extend this calculus with a recursive module mechanism and a new form of signature, called a recursively dependent signature, to support the defmition of recursive modules. These extensions are justified by an interpretation in terms of more primitive language constructs. This interpretation may also serve as a guide for implementation.

Let S be some type system. A typing in S for a typable term M is the collection of all of the information other than M which appears in the final judgement of a proof derivation showing that M is typable. For example, suppose there is a derivation in S ending with the judgement A M : # meaning that M has result type # when assuming the types of free variables are given by A. Then (A, #) is a typing for M .