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.

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

The ease of understanding, maintaining, and developing a large program depends crucially on how it is divided up into modules. The possible ways a program can be divided are constrained by the available modular programming facilities ("module system") of the programming language being used. Experience with the Standard-ML module system has shown the usefulness of functions mapping modules to modules and modules with module subcomponents. For example, functions over modules permit abstract data types (ADTs) to be parameterized by other ADTs, and submodules permit modules to be organized hierarchically. Module systems with such facilities are called higher-order, by analogy with higher-order functions. Previous higher-order module systems can be classified as either opaque or transparent. Opaque systems totally obscure information about the identity of type components of modules, often resulting in overly abstract types. This loss of type identities precludes most interesting uses of hi...

Abstract not found

is authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright notation thereon.

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

A function has a dependent type when the type of its result depends upon the value of its argument. The type o all types is the type of every type, including itself. In a typed A-calculus, these two features synergize in a conceptually clean and uniform way to yield enormous expressive power at very little apparent cost. By reconstructing and analyzing a paradox due to Girard, we argue that there is no effective typechecking algorithm for such a language.

Modules provide a grouping mechanism in modern programming languages that provide both syntactic and semantic support for constructing modular programs. Existing languages with modules are stratified - the module system "sits on top of " the core language. This paper presents a language fragment where modules are first-class objects and are hence part of the core language. Modules are defined by extended records, an extension of traditional records with type fields, based on the type theory of translucent sums. As modules are first class, functions then can be used to parameterize modules, avoiding the extra constructs such as functors and generics needed in stratified languages. As well, first-class modules provide increased expressiveness as shown by examples in the paper.