Abstract. As domain-specific modeling begins to attract widespread acceptance, pressure is increasing for the development of new domainspecific languages. Unfortunately these DSLs typically conflict with the grammar of the host language, making it difficult to compose hybrid code except at the level of strings; few mechanisms (if any) exist to control the scope of usage of multiple DSLs; and, most seriously, existing host language tools are typically unaware of the DSL extensions, thus hampering the development process. Language boxes address these issues by offering a simple, modular mechanism to encapsulate (i) compositional changes to the host language, (ii) transformations to address various concerns such as compilation and syntax highlighting, and (iii) scoping rules to control visibility of fine-grained language extensions. We describe the design and implementation of language boxes, and show with the help of several examples how modular extensions can be introduced to a host language and environment. 1

iii Acknowledgment My graduate study and life, of which this dissertation is one of the outcomes, benefitted greatly from the time, energy, and enthusiasm of many people.

Compile-time meta-programming allows programs to be constructed by the user at compile-time. Few modern languages are capable of compile-time meta-programming, and of those that do, many of the most powerful are statically typed functional languages. In this paper I present the dynamically typed, object orientated language Converge which allows compile-time meta-programming in the spirit of Template Haskell. Converge demonstrates that integrating powerful, safe compiletime meta-programming features into a dynamic language requires few restrictions to the flexible development style facilitated by the paradigm.

Abstract These lecture notes describe how to write generating extensions,i.e., dedicated program specializers. The focus is on compositional programs and their associated fold functions. Each generating exten-sion is expressed as an instance of this fold function. A number of examples are considered and pointers to related work are provided. *Lecture notes for Marktoberdorf'99, extended version.

Staged languages that allow “evaluation under lambdas” are excellent implementation languages for programs that manipulate, specialize, and execute code at runtime. In statically typed staged languages, the existence of staging primitives demands a sound distinction between open code (that may be manipulated under lambdas) and closed code (that may be executed). We present λ [] , a monomorphic type-safe staged language for manipulating code with free identifiers. It differs from most existing staged languages (such as, for example, derivatives of MetaML) in that its dynamic fragment is not hygienic; in other words, dynamic identifiers are not renamed during substitution. λ [] contains a first-class run operation, supports mutable cells (and other computational effects), and has decidable type inference. As such, it is a promising first step towards a practical multi-stage programming language.

Abstract not found

Abstract. Software must be constantly adapted to changing requirements. The time scale, abstraction level and granularity of adaptations may vary from short-term, fine-grained adaptation to long-term, coarsegrained evolution. Fine-grained, dynamic and context-dependent adaptations can be particularly difficult to realize in long-lived, large-scale software systems. We argue that, in order to effectively and efficiently deploy such changes, adaptive applications must be built on an infrastructure that is not just model-driven, but is both model-centric and contextaware. Specifically, this means that high-level, causally-connected models of the application and the software infrastructure itself should be available at run-time, and that changes may need to be scoped to the run-time execution context. We first review the dimensions of software adaptation and evolution, and then we show how model-centric design can address the adaptation needs of a variety of applications that span these dimensions. We demonstrate through concrete examples how model-centric and context-aware designs work at the level of application interface, programming language and runtime. We then propose a research agenda for a model-centric development environment that supports dynamic software adaptation and evolution. 1

Integration of multiple languages into each other and into an existing development environment is a difficult task. As a consequence, developers often end up using only internal DSLs that strictly rely on the constraints imposed by the host language. Infrastructures do exist to mix languages, but they often do it at the price of losing the development tools of the host language. Instead of inventing a completely new infrastructure, our solution is to integrate new languages deeply into the existing host environment and reuse the infrastructure offered by it. In this paper we show why Smalltalk is the best practical choice for such a host language.

The report gives a defining description of the standard libraries of the programming language Scheme.

This Ph.D. progress report documents a combination of partial evaluation and compilation that enables "just-in-time program specialization". To this end, we have composed a type-directed partial evaluator for OCaml programs with a run-time code generator for the OCaml virtual machine. The composition is deforested, i.e., residual programs are directly expressed as byte code, which is then dynamically loaded. The implementation seamlessly extends OCaml with two new keywords for generating code dynamically. The system has been applied to traditional examples of partial evaluation and run-time code generation, such as the first Futamura projection for Action Semantics and the BSD Packet Filter. iii iv Contents 1 Introduction 1 1.1 Partial evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1 What . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.2 How . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...