This document formally specifies the semantics of local modules and packages - dynamically typed modules that are first-class values - as an extension to the functional programming language Standard ML. The language thus defined is a substantial subset of a larger extension of Standard ML, a language known as Alice ML. Packages are the central feature of Alice ML that enables support for typed open programming.
The need for flexible forms of serialisation arises under many circumstances, e.g. for doing high-level inter-process communication or to achieve persistence. Many languages, including variants of ML, thus offer pickling as a system service, but usually in a both unsafe and inexpressive manner, so that its use is discouraged. In contrast, safe generic pickling plays a central role in the design and implementation of Alice ML: components are defined as pickles, and modules can be exchanged between processes using pickling. For that purpose, pickling has to be higher-order and typed (HOT), i.e. embrace code mobility and involve runtime type checks for safety. We show how HOT pickling can be realised with a modular architecture consisting of multiple abstraction layers for separating concerns, and how both language and implementation benefit from a design consistently based on pickling.
Despite its powerful module system, ML has not yet evolved for the modern world of dynamic and open modular programming, to which more primitive languages have adapted better so far. We present the design and semantics of a simple yet expressive first-class component system for ML. It provides dynamic linking in a type-safe and type-flexible manner, and allows selective execution in sandboxes. The system is defined solely by reduction to higher-order modules plus an extension with simple module-level dynamics, which we call packages. To represent components outside processes we employ generic pickling. We give a module calculus formalising the semantics of packages and pickling.
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 separately compilable, mutually recursive 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 MixML. A MixML module is like an ML structure with some components specified but not defined unifing the ML structure and signature languages into one. MixML seamlessly integrates hierarchical composition, translucent MLstyle data abstraction, and mixin-style recursive linking.Tthe design of MixML is minimalist emphasizing how all the interesting features of the ML module system can be understood simply as stylized uses of a small set of orthogonal underlying constructs, with mixin composition playing a central role.
My thesis clarified the relationships between existing dialects of ML and studied extending ML with support for recursive modules. Solve a critical problem involving the interaction of recursion and data abstraction known as the double vision problem. In other work with Bob Harper and Manuel Chakravarty, I showed how to extend ML with support for overloading and ad hoc polymorphism through Haskell-style type classes. This work exposes connections between ML modules and Haskell type classes, resulting in a unifying account of the two features Andreas and I have developed a novel module system design that addresses one of the key remaining problems with recursive modules, namely separate compilation. This design seamlessly integrates elements of both traditional ML module systems and Bracha-style mixin modules, resulting in a minimalist account of the ML module system that unifies features. A prototype is available
The ML Basis system extends Standard ML to support programming-in-the-very-large, namespace management at the module level, separate delivery of library sources, and more. While Standard ML modules are a sophisticated language for programming-in-the-large, it is difficult, if not impossible, to accomplish a number of routine namespace management operations when a program draws upon multiple libraries provided by different vendors. The ML Basis system is a simple, yet powerful, approach that builds upon the programmer's intuitive notion of the top-level environment (a basis). Here are some of the key features of the ML Basis system: 1. Explicit file order 2. Implicit dependencies 3.Scoping and renaming: The ML Basis system provides mechanisms for limiting the scope of (i.e, hiding) and renaming identifiers. 4.No naming convention for finding the file that defines a module. To import a module, its defining file must appear in some ML Basis file.
"The GeoRSS Module allows users to add geographic point data to outgoing RSS feeds. It supports two formats - Simple GeoRSS and GML - and can be administered at admin/settings/georss."
C. Wimmer, S. Brunthaler, P. Larsen, and M. Franz. Proceedings of the 11th Annual International Conference on Aspect-oriented Software Development, page 203--214. New York, NY, USA, ACM, (2012)