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.

Modular languages support generative type abstraction, ensuring that an abstract type is distinct from its representation, except inside the implementation where the two are synonymous. We show that this well-established feature is in tension with the non-parametric features of newer type systems, such as indexed type families and GADTs. In this paper we solve the problem by using kinds to distinguish between parametric and non-parametric contexts. The result is directly applicable to Haskell, which is rapidly developing support for type-level computation, but the same issues should arise whenever generativity and non-parametric features are combined.

Type-preserving compilation Compilation is type-preserving when each intermediate language is explicitly typed, and each compilation phase transforms a typed program into a typed program in the next intermediate language. Why preserve types during compilation? • it can help debug the compiler; • types can be used to drive optimizations; • types can be used to produce proof-carrying code; • proving that types are preserved can be the first step towards proving that the semantics is preserved [Chlipala, 2007].3 / 71 Type-preserving compilation A classic paper by Morrisett et al. [1999] shows how to go from System F to Typed Assembly Language, while preserving types along the way. Its main passes are: • CPS conversion fixes the order of evaluation, names intermediate computations, and makes all function calls tail calls; • closure conversion makes environments and closures explicit, and produces a program where all functions are closed; • allocation and initialization of tuples is made explicit; • the calling convention is made explicit, and variables are replaced with (an unbounded number of) machine registers. 4 / 71 Translating types In general, a type-preserving compilation phase involves not only a translation of terms, mapping t to �t�, but also a translation of types, mapping T to �T�, with the property: Γ ⊢ t: T implies �Γ � ⊢ �t � : �T� The translation of types carries a lot of information: examining it is often enough to guess what the translation of terms will be.5 / 71

Modular languages support generative type abstraction, ensuring that an abstract type is distinct from its representation, except inside the implementation where the two are synonymous. We show that this well-established feature is in tension with the non-parametric features of newer type systems, such as indexed type families and GADTs. In this paper we solve the problem by using kinds to distinguish between parametric and non-parametric contexts. The result is directly applicable to Haskell, which is rapidly developing support for type-level computation, but the same issues should arise whenever generativity and non-parametric features are combined. 1.

Abstract not found

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

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