• Corpus ID: 5559193

Type-level module aliases : independent and equal

@inproceedings{Garrigue2014TypelevelMA,
  title={Type-level module aliases : independent and equal},
  author={Jacques Garrigue and Leo White},
  year={2014}
}

• Jacques Garrigue, Leo White
• Published 2014
• Computer Science

The richness of ML’s module system theoretically allows one to flexibly structure libraries, without requiring extra features found in other languages, such as namespaces. Nested structures allow one to define hierarchies of modules, and functors provide flexible linking. However, while this may be true from an internal point of view, the module system alone does not account for all aspects of libraries. A prominent problem is how to map module names to the file system. Another is how to support separate compilation, in a way that minimizes recompilations. OCaml [5] chooses an extremely simple approach: module names which are not found in the internal environment are searched on the file system (under the same name), using a library path which is just an ordered list of directories. Such external modules are called compilation units. Separate compilation is supported by providing separate interface files for compilation units, containing only their signatures, which allows one to compile other units independently of the concrete implementation. Since the pair of a compilation unit’s interface and implementation can be understood as a module with an opaque signature, this mechanism directly fits inside the semantics of the language. Coherence is enforced by keeping digests of all dependencies in compiled files. Smart recompilation is left to external tools. However, this simplicity comes at a cost: the file system view of modules being completely flat, there is no way to have two compilation units with the same name linked into the same program. For programs relying on multiple libraries, this can be a severe stumbling block. Since Objective Caml 3.05, this problem can be avoided by combining several compilation units as submodules of a packed unit. Note however that this packed unit completely replaces the original compilation units, and the packed unit’s implementation must contain (or link) the implementations of all its submodules. This means that using any of these submodules requires you to link all of them. In that respect, one can say that it weakens separate compilation, even though what is no longer separate is not compilation but rather the result of compilation. For SML/NJ, these problems are handled by the Compilation Manager [2, 1]. The compilation manager uses special files, written in a dedicated syntax, whose role is to define the mapping from module names to their implementations inside libraries, and where to find them on the file system. Using this information, it is possible to provide smart recompilation, and to avoid module name clashes, either by making names local to a library, or by using local mappings that modify the original module name binding. Thanks to its rich expressivity, the compilation manager avoids most restrictions of a file-system based approach. However, in order to do that, it introduces another language whose semantics is external to that of ML. All this seems to lead to a contradiction: if the ML module system is so powerful, why should we need something else to express the namespace structure of concrete programs? In this presentation, we propose a new approach to this problem, based on type-level module aliases, i.e. allowing interfaces express the aliasing structure of modules, and use this information to improve separate compilation. By extending OCaml with a single syntactic construct, we are able to handle namespaces inside the language itself, in a transparent and intuitive way. This feature is available in OCaml 4.02.