Benjamin Pierce

The past three decades have seen a plethora of language features for
large-scale software composition.  Some of these are fairly simple,
others quite sophisticated.  Each embodies an implicit claim that its
particular combination of features is both necessary and sufficient for
some problem domain.  But there have been few attempts to \textit{compare}
module systems, or to explain the practical and theoretical issues that
motivate the choices they embody.  This can make it difficult to evaluate
which features are really needed for a given setting, and which may be
We offer here an overview of the design space of module systems, with
reference to those of some well-known languages (especially the ML family
and Java), and record the motivating examples and crucial design choices
underlying some central features.  In particular:

  * we identify a fundamental distinction between \textit{unresolved},
    \textit{resolved}, and \textit{generic} references between modules;

  * we compare different ways of handling \textit{families of
    interfaces} (in particular, abstracted vs. augmented interfaces);

  * we investigate the need for \textit{coherence} (or
    ``\textit{sharing}'') \textit{constraints} and consider different ways
    of expressing them;

  * we confirm a folk theorem that \textit{sharing by
    parameterization} doesn't scale as well as \textit{sharing by
    specification}; and

[Joint work with Bob Harper]