We describe twinning and its applications to adapting programs to alternative APIs. Twinning is a simple technique that allows programmers to specify a class of program changes, in the form of a mapping, without modifying the target program directly. Using twinning, programmers can specify changes that transition a program from using one API to using an alternative API.We describe two related mapping-based source-to-source transformations. The first applies the mapping to a program, producing a copy with the changes applied. The second generates a new API that abstracts the changes specified in the mapping. Using this API, programmers can invoke either the old (replaced) code or the new (replacement) code through a single interface.Managing program variants usually involves heavyweight tasks that can prevent the program from compiling for extended periods of time, as well as simultaneous maintenance of multiple implementations, which can make it easy to forget to add features or to fix bugs symmetrically. Our main contribution is to show that, at least in some common cases, the heavyweight work can be reduced and symmetric maintenance can be at least encouraged, and often enforced.

The C language definition leaves the sizes and layouts of types partially unspecified. When a C program makes assumptions about type layout, its semantics is defined only on platforms (C compilers and the underlying hardware) on which those assumptions hold. Previous work on formalizing C-like languages has ignored this issue, either by assuming that programs do not make such assumptions or by assuming that all valid programs target only one platform. In the latter case, the platform's choices are hard-wired in the language semantics.In this paper, we present a practically-motivated model for a C-like language in which the memory layouts of types are left largely unspecified. The dynamic semantics is parameterized by a platform's layout policy and makes manifest the consequence of platform-dependent (i.e., unspecified) steps. A type-and-effect system produces a layout constraint: a logic formula encoding layout conditions under which the program is memory-safe. We prove that if a program type-checks, it is memory-safe on all platforms satisfying its constraint.Based on our theory, we have implemented a tool that discovers unportable layout assumptions in C programs. Our approach should generalize to other kinds of platform-dependent assumptions.

Recent functional logic languages such as Curry and Toy combine lazy functional programming with logic programming features including logic variables, non-determinism, unification, narrowing, fair search, concurrency, and residuation. In this paper, we show how to extend a conventional interpreter for a lazy functional language to handle these features by adding support for reference cells, process-like and thread-like concurrency mechanisms, and a novel form of multi-versioned store. Our interpretation scheme is practical, and can be easily extended to perform compilation. The language specified by our interpreter is designed so that programs are deterministic in a novel and useful sense.

No abstract

Abstract.Portable low-level C programs must often support multiple equivalent in-memory layouts of data, due to the byte or bit order of the compiler, architecture, or external data formats. Code that makes assumptions about data layout often consists of multiple highly similar pieces of code, each designed to handle a different layout. Writing and maintaining this code is difficult and bug-prone: Because the differences among data layouts are subtle, implicit, and inherently low-level, it is difficult to understand or change the highly similar pieces of code consistently.We have developed a small extension for C that lets programmers write concise declarative descriptions of how different layouts of the same data relate to each other. Programmers then write code assuming only one layout and rely on our translation to generate code for the others. In this work, we describe our declarative language for specifying data layouts, how we perform the automatic translation of C code to equivalent code assuming a different layout, and our success in applying our approach to simplify the code base of some widely available software.