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.

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.

We describe support for modularity in Newspeak, a programming language descended from Smalltalk [33] and Self [68]. Like Self, all computation — even an object’s own access to its internal structure — is performed by invoking methods on objects. However, like Smalltalk, Newspeak is class-based. Classes can be nested arbitrarily, as in Beta [44]. Since all names denote method invocations, all classes are virtual; in particular, superclasses are virtual, so all classes act as mixins. Unlike its predecessors, there is no static state in Newspeak, nor is there a global namespace. Modularity in Newspeak is based exclusively on class nesting. There are no separate modularity constructs such as packages. Top level classes act as module definitions, which are independent, immutable, self-contained parametric namespaces. They can be instantiated into modules which may be stateful and mutually recursive.

We present a mechanized formalization and type safety proof for the variant of Dreyer’s RTG language [2] (for Recursive Type Generativity) used in Dreyer and Rossberg’s work on ML-style mixin modules [3]. This is a core module calculus with the ability to forward declare type variables and then later give them (possibly recursive) definitions. The static semantics of RTG involves tracking the definability of these type variables, which is a linear resource — for soundness reasons, a type variable may only be defined once. Once a type variable is defined, the knowledge of its definition must be added to the context for typechecking subsequent code. The linear nature of definability, combined with the use of context effects to add definitions for existing type variables, means that the mechanized encoding of the metatheory of RTG is not obvious. Our mechanization uses the Twelf proof system. For the most part, we employ standard techniques for formalizing λ-calculi using HOAS. However, for handling type definability and type definitions, we needed to develop more advanced techniques. Type definability is a linear resource. In order to ensure that a module defines an abstract type exactly once, we employ a judgment defonce ([a] M a), which identifies when M a is a module that defines a only once. Within M a, the variable a can also appear in other non-definition sites, such as type ascriptions, an arbitrary number of times. While our use of the defonce judgment is a standard trick, we additionally need to impose well-formedness

Abstract. SML/NJ and other Standard ML variants extend the ML module system with higher-order functors, elevating the module language to a full functional language. In this paper, we describe the implementation of the higher-order module system in SML/NJ, which is unique in providing “true ” higher-order behavior at the static level. This second generation implementation of higher-order modules in SML/NJ is based on three key techniques: unique internal variables (entity variables) for naming static entities, a factorization of the static information in both basic modules and functors into signatures and realizations, and a static lambda calculus we call the entity calculus with static “effects” to represent the type-level mapping performed by a functor. This system implements MacQueen-Tofte’s re-elaboration semantics without having to re-elaborate functor bodies or appeal to fragile stamp properties. 1

A practical type system for ML-style recursive modules should address at least two technical challenges. First, it needs to solve the double vision problem, which refers to an inconsistency between external and internal views of recursive modules. Second, it needs to overcome the tension between practical decidability and expressivity which arises from the potential presence of cyclic type definitions caused by recursion between modules. Although type systems in previous proposals solve the double vision problem and are also decidable, they fail to typecheck common patterns of recursive modules, such as functor fixpoints, that are essential to the expressivity of the module system and the modular development of recursive modules. This paper proposes a novel type system for recursive

Building reusable libraries and reliable, maintainable programs requires modular design, yet JavaScript currently provides little support for modularity. In this paper, we present the design of a module system for JavaScript. Our design is currently the basis for the module system in the next version of the JavaScript standard. The design provides a simple model for programmers and supports developing both client-side applications in the browser as well as standalone, server-side applications. Modules in our system are lexically scoped, may be nested and recursive, and can be statically loaded from external sources, allowing existing programs to be refactored naturally. In addition to static modules, our design provides a flexible mechanism for dynamically loading code that maintains isolation from untrusted modules. Finally, the system supports programmatic transformation and validation of code, supporting emerging practices in the JavaScript community. 1.

ML modules are a powerful language mechanism for decomposing programs into reusable components. Unfortunately, they also have a reputation for being “complex ” and requiring fancy type theory that is mostly opaque to non-experts. While this reputation is certainly understandable, given the many non-standard methodologies that have been developed in the process of studying modules, we aim here to demonstrate that it is undeserved. To do so, we give a very simple elaboration semantics for a full-featured, higher-order ML-like module language. Our elaboration defines the meaning of module expressions by a straightforward, compositional translation into vanilla System Fω (the higher-order polymorphic λ-calculus), under plain Fω typing environments. We thereby show that ML modules are merely a particular mode of use of System Fω. We start out with a module language that supports the usual second-class modules with Standard ML-style generative functors, and includes local module definitions. To demonstrate the versatility of our approach, we further extend the language with the ability to package modules as first-class values—a very simple extension, as it turns out—and a novel treatment of OCaml-style applicative functors. Unlike previous work combining both generative and applicative functors, we do not require