Mixin’ Up the ML Module System

Abstract

ML modules provide hierarchical namespace management, as well as fine-grained control over the propagation of type information, but they do not allow modules to be broken up into mutually recursive, separately compilable components. Mixin modules facilitate recursive linking of separately compiled components, but they are not hierarchically composable and typically do not support type abstraction. We synthesize the complementary advantages of these two mechanisms in a novel module system design we call MixML.A MixML module is like an ML structure in which some of the components are specified but not defined. In other words, it unifies the ML structure and signature languages into one. MixML seamlessly integrates hierarchical composition, translucent MLstyle data abstraction, and mixin-style recursive linking. Moreover, the design of MixML is clean and minimalist; it emphasizes how all the salient, semantically interesting features of the ML module system (as well as several proposed extensions to it) can be understood simply as stylized uses of a small set of orthogonal underlying constructs, with mixin composition playing a central role.

F-ing modules

“…Nevertheless, the basic ideas of the "F-ing" approach still apply: a semantics for recursive modules can be given using a variation of our elaboration, and targeting a language that is a conservative extension of F ω . The first and last authors' work on MixML, a module system with recursive mixin composition, explores precisely that path (Rossberg & Dreyer, 2013).…”

“…However, with the generalization to applicative functors, this factoring leads to a more complicated algorithm: in that system, lookup and subtyping become intertwined, which means that to separate them, lookup has to duplicate some of the work of subtyping, and its correctness proof needs to make sure that both algorithms operate in sync. The issue of rootedness could be avoided by decorating semantic signatures with "locators" (compare with Rossberg & Dreyer (2013)). A more traditional, interleaved, and algorithmic definition of matching would eliminate the need for a correctness proof altogether (while slightly complicating the declarative semantics and its soundness proof).…”

“…We think not -although this is obviously a fundamentally subjective question. One can certainly engage in a constructive debate about whether the mechanisms that comprise the ML module system are put together in the ideal way, and in fact the first and third authors have recently done precisely that (Rossberg & Dreyer, 2013). But we do not believe that the design of the ML module system is the primary source of the "complexity" complaint.…”

1ML – core and modules united (F-ing first-class modules)

“…For example, the previous functions could equivalently be written as It may seem surprising that we can just reify types as first-class values. But reified types (or "atomic type modules") have been common in module calculi for a long time [16,6,24,25]. We are merely making them available in the source language directly.…”

“…Packaged Modules The first concrete proposal for extending ML with packaged modules was by Russo [27], and is implemented in Moscow ML. Later work on type systems for modules routinely included them [6,4,24,25], and variations have been implemented in other ML dialects, such as Alice ML [22] and OCaml [7]. To avoid soundness issues in the combination with applicative functors, Russo's original proposal conservatively allowed unpacking a module only local to core-level expressions, but this restriction has been lifted in later systems, restricting only the occurrence of unpacking inside applicative functors.…”