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

A module system ought to enable assembly-line programming using separate compilation and an expressive linking language. Separate compilation allows programmers to develop parts of a program independently. A linking language gives programmers precise control over the assembly of parts into a whole. This paper presents models of program units, MzScheme's module language for assembly-line programming. Units support separate compilation, independent module reuse, cyclic dependencies, hierarchical structuring, and dynamic linking. The models explain how to integrate units with untyped and typed languages such as Scheme and ML.

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.

This dissertation provides a framework for modularity in programming languages. In this framework, known as Jigsaw, inheritance is understood to be an essential linguistic mechanism for module manipulation. In Jigsaw, the roles of classes in existing languages are "unbundled," by providing a suite of operators independently controlling such effects as combination, modification, encapsulation, name resolution, and sharing, all on the single notion of module. All module operators are forms of inheritance. Thus, inheritance is not in conflict with modularity in this system, but is indeed its foundation. This allows a previously unobtainable spectrum of features to be combined in a cohesive manner, including multiple inheritance, mixins, encapsulation and strong typing. Jigsaw has a rigorous semantics, based upon a denotational model of inheritance. Jigsaw provides a notion of modularity independent of a particular computational paradigm. Jigsaw can therefore be applied to a wide variet...

Abstract not found

Several related typed languages for modular programming and data abstraction have been proposed recently, including Pebble, SOL, and ML modules. We review and compare the basic type-theoretic ideas behind these languages and evaluate how they

Abstract not found

Standard ML is an excellent language for many kinds of programming. It is safe, efficient, suitably abstract, and concise. There are many aspects of the language that work well. However, nothing is perfect: Standard ML has a few shortcomings. In some cases there are obvious solutions, and in other cases further research is required.

Standard ML is a major revision of earlier dialects of the functional language ML. We describe the first compiler written for Standard ML in Standard ML. The compiler incorporates a number of novel features and techniques, and is probably the largest system written to date in Standard ML. Great attention was paid to modularity in the construction of the compiler, leading to a successful large-scale test of the modular capabilities of Standard ML. The front end is useful for purposes other than compilation, and the back end is easily retargetable (we have code generators for the VAX and MC68020). The module facilities of Standard ML were taken into account early in the design of the compiler, and they particularly influenced the environment management component of the front end. For example, the symbol table structure is designed for fast access to opened structures. The front end of the compiler is a single phase that integrates parsing, environment management, and type checking. The m...