1ML – Core and Modules United (F-ing First-class Modules) Andreas Rossberg Google, Germany [email protected] Abstract ference [18, 3], and an advanced module system based on concepts ML is two languages in one: there is the core, with types and ex- from dependent type theory [17]. Although both have contributed pressions, and there are modules, with signatures, structures and to the success of ML, they exist in almost entirely distinct parts functors. Modules form a separate, higher-order functional lan- of the language. In particular, the convenience of type inference is guage on top of the core. There are both practical and technical available only in ML’s so-called core language, whereas the mod- reasons for this stratification; yet, it creates substantial duplication ule language has more expressive types, but for the price of being in syntax and semantics, and it reduces expressiveness. For exam- painfully verbose. Modules form a separate language layered on ple, selecting a module cannot be made a dynamic decision. Lan- top of the core. Effectively, ML is two languages in one. guage extensions allowing modules to be packaged up as first-class This stratification makes sense from a historical perspective. values have been proposed and implemented in different variations. Modules were introduced for programming-in-the-large, when the However, they remedy expressiveness only to some extent, are syn- core language already existed. The dependent type machinery that tactically cumbersome, and do not alleviate redundancy. was the central innovation of the original module design was alien We propose a redesign of ML in which modules are truly first- to the core language, and could not have been integrated easily. class values, and core and module layer are unified into one lan- However, we have since discovered that dependent types are not guage. In this “1ML”, functions, functors, and even type construc- actually necessary to explain modules. In particular, Russo [26, 28] tors are one and the same construct; likewise, no distinction is made demonstrated that module types can be readily expressed using between structures, records, or tuples. Or viewed the other way only System-F-style quantification. The F-ing modules approach round, everything is just (“a mode of use of”) modules. Yet, 1ML later showed that the entire ML module system can in fact be does not require dependent types, and its type structure is express- understood as a form of syntactic sugar over System F! [25]. Meanwhile, the second-class nature of modules has increasingly ible in terms of plain System F!, in a minor variation of our F-ing modules approach. We introduce both an explicitly typed version been perceived as a practical limitation. The standard example of 1ML, and an extension with Damas/Milner-style implicit quan- being that it is not possible to select modules at runtime: tification. Type inference for this language is not complete, but, we module Table = if size > threshold then HashMap else TreeMap argue, not substantially worse than for Standard ML. An alternative view is that 1ML is a user-friendly surface syntax A definition like this, where the choice of an implementation is for System F! that allows combining term and type abstraction in dependent on dynamics, is entirely natural in object-oriented lan- a more compositional manner than the bare calculus. guages. Yet, it is not expressible with ordinary ML modules. What a shame! Categories and Subject Descriptors D.3.1 [Programming Lan- guages]: Formal Definitions and Theory; D.3.3 [Programming 1.1 Packaged Modules Languages]: Language Constructs and Features—Modules; F.3.3 [Logics and Meanings of Programs]: Studies of Program Constructs— It comes to no surprise, then, that various proposals have been Type structure made (and implemented) that enrich ML modules with the ability to package them up as first-class values [27, 22, 6, 25, 7]. Such General Terms Languages, Design, Theory packaged modules address the most imminent needs, but they are Keywords ML modules, first-class modules, type systems, ab- not to be confused with truly first-class modules. They require stract data types, existential types, System F, elaboration explicit injection into and projection from first-class core values, accompanied by heavy annotations. For example, in OCaml 4 the 1. Introduction above example would have to be written as follows: The ML family of languages is defined by two splendid innova- module Table = (val (if size > threshold then (module HashMap : MAP) tions: parametric polymorphism with Damas/Milner-style type in- else (module TreeMap : MAP))) : MAP) which, arguably, is neither natural nor pretty. Packaged modules have limited expressiveness as well. In particular, type sharing with a packaged module is only possible via a detour through core-level polymorphism, such as in: f : (module S with type t = 'a) ! (module S with type t = 'a) ! 'a (where t is an abstract type in S). In contrast, with proper modules, the same sharing could be expressed as [Copyright notice will appear here once ’preprint’ option is removed.] f : (X : S) ! (S with type t = X.t) ! X.t 1 2015/6/18 Because core-level polymorphism is first-order, this approach tool for solving type constraints. And while inference algorithms cannot express type sharing between type constructors – a com- for subtyping exist, they have much less satisfactory properties than plaint that has come up several times on the OCaml mailing list; our beloved Hindley/Milner sweet spot. for example, if one were to abstract over a monad: Worse, module types do not even form a lattice under subtyping: map : (module MONAD with type 'a t = ?) ! ('a ! 'b) ! ? ! ? f1 : ftype t a; x : t intg ! int f2 : ftype t a; x : intg ! int There is nothing that can be put in place of the ?’s to complete this g = if condition then f else f function signature. The programmer is forced to either use weaker 1 2 types (if possible at all), or drop the use of packaged modules and There are at least two possible types for g: lift the function (and potentially a lot of downstream code) to the g : ftype t a = int; x : intg ! int functor level – which not only is very inconvenient, it also severely g : ftype t a = a; x : intg ! int restricts the possible computational behaviour of such code. One could imagine addressing this particular limitation by introducing Neither is more specific than the other, so no least upper bound higher-kinded polymorphism into the ML core. But with such an exists. Consequently, annotations are necessary to regain principal extension type inference would require higher-order unification and types for constructs like conditionals, in order to restore any hope hence become undecidable – unless accompanied by significant for compositional type checking, let alone inference. restrictions that are likely to defeat this example (or others). 1.3 F-ing Modules 1.2 First-Class Modules In our work on F-ing modules with Russo & Dreyer [25] we have Can we overcome this situation and make modules more equal demonstrated that ML modules can be expressed and encoded citizens of the language? The answer from the literature has been: entirely in vanilla System F (or F!, depending on the concrete core no, because first-class modules make type-checking undecidable language and the desired semantics for functors). Effectively, the F- and type inference infeasible. ing semantics defines a type-directed desugaring of module syntax The most relevant work is Harper & Lillibridge’s calculus into System F types and terms, and inversely, interprets a stylised of translucent sums [9] (a precursor of later work on singleton subset of System F types as module signatures. types [31]). It can be viewed as an idealised functional language The core language that we assume in that paper is System F that allows types as components of (dependent) records, so that (respectively, F!) itself, leading to the seemingly paradoxical situ- they can express modules. In the type of such a record, individual ation that the core language appears to have more expressive types type members can occur as either transparent or opaque (hence, than the module language. That makes sense when considering that translucent), which is the defining feature of ML module typing. the module translation rules manipulate the sublanguage of module Harper & Lillibrige prove that type-checking this language is types in ways that would not generalise to arbitrary System F types. undecidable. Their result applies to any language that has (a) con- In particular, the rules implicitly introduce and eliminate universal travariant functions, (b) both transparent and opaque types, and (c) and existential quantifiers, which is key to making modules a us- allows opaque types to be subtyped with arbitrary transparent types. able means of abstraction. But the process is guided by, and only The latter feature usually manifests in a subtyping rule like meaningful for, module syntax; likewise, the built-in subtyping re- fD1[τ=t]g ≤ fD2[τ=t]g lation is only “complete” for the specific occurrences of quantifiers FORGET ftype t=τ;D g ≤ ftype t;D g in module types. 1 2 Nevertheless, the observation that modules are just sugar for which is, in some variation, at the heart of every definition of signa- certain kinds of constructs that the core language can already ex- ture matching. In the premise the concrete type τ is substituted for press (even if less concisely), raises the question: what necessitates the abstract t. Obviously, this rule is not inductive. The substitution modules to be second-class in that system? can arbitrarily grow the types, and thus potentially require infinite derivations. A concrete example triggering non-termination is the 1.4 1ML following, adapted from Harper & Lillibridge’s paper [9]: The answer to that question is: very little! And the present paper is type T = ftype A; f : A ! ()g motivated by exploring that answer.