Rigid Mixin Modules

International audienceMixin modules are a notion of modules that allows cross-module recursion and late binding, two features missing in ML-style modules. They have been well defined in a call-by-name setting, but in a call-by-value setting, they tend to conflict with the usual static restrictions on recursive definitions. Moreover, the semantics of instantiation has to specify an order of evaluation, which involves a difficult design choice. Previous proposals rely on the dependencies between components to compute a valid order of evaluation. In such systems, mixin module types must carry some information on the dependencies between their components, which makes them verbose. In this paper, we propose a new, simpler design for mixin modules in a call-by-value setting, which avoids this problem

Towards modular extensions for a modular language

Modularity allows the construction of complex designs from simpler, independent units that most of the time can be developed separately. In this paper we are concerned with developing mechanisms for easily implementing modular extensions to modular (logic) languages. By (language) extensions we refer to different groups of syntactic definitions and translation rules that extend a language. Our application of the concept of modularity in this context is twofold. We would like these extensions to be modular, in the above sense, i.e., we should be able to develop different extensions mostly separately. At the same time, the sources and targets for the extensions are modular languages, i.e., such extensions may take as input separate pieces of code and also produce separate pieces of code. Dealing with this double requirement involves interesting challenges to ensure that modularity is not broken: first, combinations of extensions (as if they were a single extension) must be given a precise meaning. Also, the separate translation of multiple sources (as if they were a single source) must be feasible. We present a detailed description of a code expansion-based framework that proposes novel solutions for these problems. We argue that the approach, while implemented for Ciao, can be adapted for other languages and Prolog-based systems

A flexible model for dynamic linking in Java and C#

Dynamic linking supports flexible code deployment, allowing partially linked code to link further code on the fly, as needed. Thus, end-users enjoy the advantage of automatically receiving any updates, without any need for any explicit actions on their side, such as re-compilation, or re-linking. On the down side, two executions of a program may link in different versions of code, which in some cases causes subtle errors, and may mystify end-users. Dynamic linking in Java and C# are similar: the same linking phases are involved, soundness is based on similar ideas, and executions which do not throw linking errors give the same result. They are, however, not identical: the linking phases are combined differently, and take place in different order. Consequently, linking errors may be detected at different times by Java and C# runtime systems. We develop a non-deterministic model, which describes the behaviour of both Java and C# program executions. The nondeterminism allows us to describe the design space, to distill the similarities between the two languages, and to use one proof of soundness for both. We also prove that all execution strategies are equivalent with respect to terminating executions that do not throw link errors: they give the same results

Java binary computability is almost correct version 2∝

The Java language description is unusual in that it defines the effect of interleaving separate compilation and source code modifications. In Java, certain source code modifications, such as adding a method to a class, are defined as binary compatible. The Java language description does not require the re-compilation of programs importing classes or interfaces which were modified in binary compatible ways, and it claims that successful linking and execution of the altered program is guaranteed. In this paper we show that Java binary compatibility does not actually guarantee successful linking and execution. We then suggest a framework in which we formalize the requirement of safe linking and execution without re-compilation and we propose a more modest definition of binary compatibility. We prove for a substantial subset of Java, that our definition guarantees safe linking and execution

Linking Types for Multi-Language Software: Have Your Cake and Eat It Too

Large software systems are and should be implemented with many different languages, each suited to the domain of the task at hand. High-level business logic may be written in Java or OCaml, resource-intensive components may be written in C or Rust, and high-assurance components may be written in Coq. In some development shops, domain-specific languages are used in various parts of systems to better separate the logic of particular problems from the plumbing of general-purpose programming. But how are programmers to reason about such multi-language systems? Currently, for a programmer to reason about a single source component within this multi-language system, it is not sufficient for her to consider how her component behaves in source-level contexts. Instead, she is required to understand the target contexts that her component will be run in after compilation - which requires not only understanding aspects of the compiler, but also how target components are linked together. These target contexts may have behavior inexpressible in the source, which can impact the notion of equivalence that justifies behavior-preserving modifications of code, whether programmer refactorings or compiler optimizations. But while programmers should not have to reason about arbitrary target contexts, sometimes multi-language linking is done exactly to gain access to features unavailable in the source. To enable programmers to reason about components that link with behavior inexpressible in their language, we advocate that language designers incorporate specifications for linking into the source language. Such specifications should allow a programmer to reason about inputs from other languages in a way that remains close to the semantics of her language. Linking types are a well-specified minimal extension of a source language that allow programmers to annotate where in their programs they can link with components that are not expressible in their unadulterated source language. This gives them fine-grained control over the contexts that they must reason about and the equivalences that arise

A Calculus for Dynamic Loading

We present the load-calculus, used to model dynamic loading, and prove it sound. The calculus extends the polymorphic λ-calculus with a load primitive that dynamically loads terms that are closed, with respect to values. The calculus is meant to approximate the process of dynamic loading in TAL/Load [4], a version of Typed Assembly Language [7] extending with dynamic linking. To model the key aspects of TAL, the calculus contains references and facilities for named types. Loadable programs may refer to named types defined by the running program, and may export new types to code loaded later. Our approach follows the framework initially outlined by Glew et. al [3]. This calculus has been implemented in the TALx86 [6] version of Typed Assembly Language, and is used to implement a full-featured dynamic linking library, DLpop [4]

Expressive modular linking for object-oriented languages

technical reportIn this paper we show how modular linking of program fragments can be added to statically typed, object-oriented (OO) languages. Programs are being assembled out of separately developed software components deployed in binary form. Unfortunately, mainstream OO languages (such as Java) still do not provide support for true modular linking. Modular linking means that program fragments can be separately compiled and type checked, and that linking can ensure global program type correctness without analyzing program fragment implementations. Supporting modular linking in OO languages is complicated by two expressive features that current OO languages do not support together: mixin-style inheritance across program fragment boundaries, and cyclic dependencies between program fragments. In a previous paper at OOPSLA 2001, we have demonstrated the practical uses for such expressiveness. When such expressiveness is permitted, link-time type checking rules must ensure that method collisions and inheritance cycles do not occur after program fragments are linked into a program. In this paper, we show how modular linking with both cyclic linking and mixin-style inheritance can be supported using a type-checking architecture that can be added on top of existing OO languages, such as Java.