In the context of statically-typed, class-based languages, we investigate classes that can be extended with trait composition. A trait is a collection of methods without state; it can be viewed as an incomplete stateless class. Traits can be composed in any order, but only make sense when imported by a class that provides state variables and additional methods to disambiguate conflicting names arising between the imported traits. We introduce FeatherTrait Java (FTJ), a conservative extension of the simple lightweight class-based calculus Featherweight Java (FJ) with statically-typed traits. In FTJ, classes can be built using traits as basic behavioral bricks; method conflicts between imported traits must be resolved explicitly by the user either by (i) aliasing or excluding method names in traits, or by (ii) overriding explicitly the conflicting methods in the class or in the trait itself. We present an operational semantics with a lookup algorithm, and a sound type system that guarantees that evaluating a well-typed expression never yields a message-not-understood run-time error nor gets the interpreter stuck. We give examples of the increased expressive power of the trait-based inheritance model. The resulting calculus appears to be a good starting point for a rigorous mathematical analysis of typed class-based languages featuring trait-based inheritance.

A mixin module is a programming abstraction that simultaneously generalizes λ-abstractions, records, and mutually recursive definitions. Although various mixin module type systems have been developed, no one has investigated principal typings or developed type inference for first-class mixin modules, nor has anyone added Milner’s let-polymorphism to such a system. This paper proves that typability is NP-complete for the naive approach followed by previous mixin module type systems. Because a λ-calculus extended with record concatenation is a simple restriction of our mixin module calculus, we also prove the folk belief that typability is NP-complete for the naive early type systems for record concatenation. To allow feasible type inference, we present Martini, a new system of simple types for mixin modules with principal typings. Martini is conceptually simple, with no subtyping and a clean and balanced separation between unification-based type inference with type and row variables and constraint solving for safety of linking and field extraction. We have implemented a type inference algorithm and we prove its complexity to be O(n 2), or O(n) given a fixed bound on the number of field labels. 1 To prove the complexity, we need to present an algorithm for row unification that may have been implemented by others, but which we could not find written down anywhere. Because Martini has principal typings, we successfully extend it with Milner’s let-polymorphism. Categories and Subject Descriptors D.3.3 [Programming Languages]: Language Constructs and Features—Data types and structures; modules, packages; polymorphism

We present FJig, a simple calculus where basic building blocks are classes in the style of Featherweight Java, declaring elds, methods and one constructor. However, inheritance has been generalized to the much more exible notion originally proposed in Bracha's Jigsaw framework. That is, classes play also the role of modules, that can be composed by a rich set of operators, all of which can be expressed by a minimal core. We keep the nominal approach of Java-like languages, that is, types are class names. However, a class is not necessarily a structural subtype of any class used in its de ning expression. The calculus allows the encoding of a large variety of di erent mechanisms for software composition in class-based languages, including standard inheritance, mixin classes, traits and hiding. Hence, FJig can be used as a unifying framework for analyzing existing mechanisms and proposing new extensions. We provide two di erent semantics of an FJig program: attening and direct semantics. The di erence is analogous to that between two intuitive models to understand inheritance: the former where inherited methods are copied into heir classes, and the latter where member lookup is performed by ascending the inheritance chain. Here we address equivalence of these two views for a more sophisticated composition mechanism.

separate compilation. The system gives meaning to individual program fragments, called units. Units may depend on one another in a way specified by the programmer. A dependency may be mediated by an interface (the type of a unit); if so, the units can be compiled separately. Otherwise, they must be compiled in sequence. We also propose a methodology for programming in SMLSC that reflects code development practice and avoids syntactic repetition of interfaces. The language is given a formal semantics, and we argue that this semantics is implementable in a variety of compilers.

This is a proposal for an extension to the Standard ML programming language to support separate compilation. The extension allows the programmer to write a program broken into multiple fragments in a way that would be compatible between different implementations. It also allows for the separate compilation of these fragments, for incremental recompilation strategies such as cut-off recompilation, and for a range of implementation strategies including whole-program compilation. The semantics of separate compilation is defined independent of the underlying semantic framework

The obvious simple type system for a λ-calculus extended with record concatenation has a typability problem that was believed to be expensive, and which we prove NP-complete. Some previous approaches to this problem employ subtyping polymorphism. We present Bowtie, a system of simple types for record concatenation which has principal typings, no subtyping, and a clean separation between unification-based type inference with type and row variables and constraint solving for safety of concatenation and field selection. Because Bowtie has no subtyping, we succeeded in straightforwardly generalizing it to a similar type system, Martini, for mixin modules. The type inference complexity for both systems is O(n 2), or O(n) given a bounded number of field labels. 1 We have implemented type inference for both type systems. Because they have principal typings, extending either with Milner’s let-polymorphism is straightforward.

Abstract. We define a core language combining computational and architectural primitives, and study how static typing may be used to ensure safety properties of component composition and dynamic reconfiguration in object-based systems. We show how our language can model typed entities analogous of configuration scripts, makefiles, components, and component instances, where static typing combined with a dynamic type-directed test on the structure of objects can enforce consistency of compositions and atomicity of reconfiguration. 1

(will be inserted by the editor)