this article we explain how that approach can be applied to software. Our compilation manager provides a language for specifying where individual modules fit into a hierarchy and how they are related semantically. We pay particular attention to the structure of the global name space of program identifiers that are used for module linkage because any potential for name clashes between otherwise unrelated parts of a program can negatively a#ect modularity. We discuss the theoretical issues in building software hierarchically, and we describe our implementation of CM, the compilation manager for Standard ML of New Jersey. Categories and Subject Descriptors: D.2.2 [Software Engineering]: Tools and Techniques--- Modules and interfaces; D.3.3 [Programming Languages]: Language Constructs and Features ---Modules; packages General Terms: Design, Languages, Management Additional Key Words and Phrases: Compilation management, linking, modularity, modules, name visibility, program structure 1.

We define a formal system supporting separate compilation for a small but significant Java-like language.

Separate compilation is an important tool for coping with design complexity in large software projects. When done right it can also be used to create software libraries, thus promoting code reuse. But separate compilation comes in various flavors and has many facets: namespace management, linking, optimization, dependencies. Many programming languages identify modular units with units of compilation, while only a few extend this to permit hierarchies of language-level modules within individual compilation units. When the number of compilation units is large, then it becomes increasingly important that the mechanism of separate compilation itself can be used to control namespaces. The group model implemented in SML/NJ's compilation manager CM provides the necessary facilities to avoid unwanted interferences between unrelated parts of large programs. Compilation units are arranged into groups, and explicit export interfaces can be used to control namespaces. When there are many groups, t...

Automatic dependency analysis is a useful addition to a system like CM, our compilation manager for Standard ML of New Jersey. It relieves the programmer from the tedious and error-prone task of having to specify compilation dependencies by hand and thereby makes its usage more user-friendly. But dependency analysis is not easy as the general problem for Standard ML is NP-complete. Therefore, CM has to impose certain restrictions on the programming language to recover tractability. We prove the NP-completeness result, discuss the restrictions on ML that are used by CM, and provide the resulting analysis algorithms. 1 Introduction For programs written in Standard ML [MTH90, MTHM97], the order of compilation matters. But the task of maintaining order within collections of sources can be tedious. Therefore, CM [Blu95], the compilation manager for Standard ML of New Jersey [AM91], o#ers automatic dependency analysis. CM provides a language for specifying the semantic structure of large pr...

Many programming languages identify modular units with compilation units, while only few extend this to permit hierarchies of language-level modules within individual compilation units. But when the number of such compilation units is large, then it becomes increasingly important that they themselves can be grouped together and that explicit export interfaces can be used to control namespaces. We explain how the group model implemented in SML/NJ's compilation manager CM provides the necessary facilities to avoid unwanted interferences between unrelated parts of large programs. We also discuss the problem of automatic dependency analysis as well as its complexity and show ways of avoiding intractability. 1 Introduction Abstraction and modular design are key elements of modern software engineering. When the number of compilation units is large, then it becomes increasingly important that they themselves can be grouped together and that explicit export interfaces can be used to control n...

this paper we will only mention Java for brevity, but all claims about Java can be replaced with analogous claims about C#

ective recompilation for any SML program consisting of more than one compilation unit. But when the number of compilation units is large, it becomes increasingly important that they themselves can be grouped together and that explicit export interfaces can be used to control namespaces. When there are many groups, then one may want to organize them into supergroups, and so on. Figure 1 shows the dependency graph for CML's sources. CML [Rep91] is implemented as a regular SML/NJ program. Without the help from a compilation manager one would have to invoke a number of use commands---one for each source file---in order to load CML into SML/NJ. Of course, the order in which the commands are issued is important here, because identifiers can only be referred to after they are defined. Therefore, since run-cml.sml refers to objects defined in cml-compat.sml the former must be loaded after the latter. More precisely, the sequence of use<F

This manual describes a new implementation of CM, the ``Compilation and Library manager'' for Standard ML of New Jersey (SML/NJ). Like its previous incarnation, CM is in charge of managing separate compilation and facilitates access to stable libraries.