DrScheme is a programming environment for Scheme. It fully integrates a graphicsenriched editor, a parser for multiple variants of Scheme, a functional read-eval-print loop, and an algebraic printer. The environment is especially useful for students, because it has a tower of syntactically restricted variants of Scheme that are designed to catch typical student mistakes and explain them in terms the students understand. The environment is also useful for professional programmers, due to its sophisticated programming tools, such as the static debugger, and its advanced language features, such as units and mixins. Beyond the ordinary programming environment tools, DrScheme provides an algebraic stepper, a context-sensitive syntax checker, and a static debugger. The stepper reduces Scheme programs to values, according to the reduction semantics of Scheme. It is useful for explaining the semantics of linguistic facilities and for studying the behavior of small programs. The syntax checker annotates programs with font and color changes based on the syntactic structure of the program. On demand, it draws arrows that point from bound to binding occurrences of identifiers. It also supports α-renaming. Finally, the static debugger provides a type inference system that explains specific inferences in terms of a value-flow graph, selectively overlaid on the program text.

Programmers constantly design, implement, and program in little languages. Two different approaches to the implementation of little languages have evolved. One emphasizes the design of little languages from scratch, using conventional technology to implement interpreters and compilers. The other advances the idea of extending a general-purpose host language; that is, the little language shares the host language’s features (variables, data, loops, functions) where possible; its interpreters and compilers; and even its type soundness theorem. The second approach is often called a language embedding. This paper directs the attention of little language designers to a badly neglected area: the programming environments of little languages. We argue that an embedded little language should inherit not only the host language’s syntactic and semantic structure, but also its programming environment. We illustrate the idea with our DrScheme programming environment and S-XML, a little transformation language for XML trees. DrScheme provides a host of tools for Scheme: a syntax analysis tool, a static debugger, an algebraic stepper, a portable plugin system, and an interactive evaluator. S-XML supports the definition of XML languages using a simple form of schemas, the convenient creation of XML data, and the definition of XML transformations.

Abstract. xml is a language for describing markup languages for structured data. A growing number of applications that process xml documents are transformers, i.e., programs that convert documents between xml languages. Unfortunately, the current proposals for transformers are complex general-purpose languages, which will be unappealing as the xml user base broadens and thus decreases in technical sophistication. We have designed and implemented xt3d, a highly declarative xml specification language. It demands little more from users than a knowledge of the expected input and desired output. We illustrate the power of xt3d with several examples, including one reminiscent of polytypic programming that greatly simplifies the import of xml values into general-purpose languages. 1 XML and Transformations xml [3] is a simplified version of the markup description language sgml. Because of xml’s syntactic simplicity, it is easy to implement rudimentary xml processors and embed them in a variety of devices. As a result, a wide variety of applications are adopting xml as a data representation standard. Declarative programming languages must therefore provide support for xml. They can do better; as this paper demonstrates, ideas from declarative programming can strongly enhance the toolkit that supports xml. Syntactically, xml has a structure similar to other sgml-style markup languages such as html. The difference between xml and a language like html is that xml really represents a family of languages. Concretely, xml provides two levels of specification: – An xml element defines a tree-structured representation of terms. This representation is rich enough to express a wide variety of data. A sample element, which might represent information about music albums, is <album title="everybody else is doing it, so why can’t we?"> <catalog><num>A043</num><fmt>CD</fmt></catalog>

A great deal of work on software maintenance focuses on source code analysis and manipulation. Code is viewed as a static entity that is -- more or less -- separated from the system at runtime. Although there are certainly important open questions in this field, the separation of code and runtime imposes itself an obstacle for the evolution of continuously functioning systems. The goal of the work presented in this paper is to blur the separation between statics and dynamics of a software system on a conceptual level. To achieve this, we propose a system model that combines space, time and level of abstraction and a conceptual framework for incremental evolution of systems during execution. Based on this continuously functioning systems can be maintained in a highly flexible and conceptually sound way.

We describe an s-expression based syntax-extension framework much like Scheme macros, with a key additional facility: the ability to define static semantics, such as type systems or program analysis, for the new, user-defined forms or embedded languages, thus allowing us to construct “towers ” of language levels. In addition, the static semantics of the languages at two adjacent levels in the tower can be connected, allowing improved reasoning power at a higher (and perhaps more restricted) level to be reflected down to the static semantics of the language level below. We demonstrate our system by designing macros for an assembly language, together with some example static analyses (termination analysis, type inference and control-flow analysis).

. Over the past few years, the notion of building software from components has become popular again. The goal is to produce systems by adapting and linking off-the-shelf modules from a pool of interchangeable components. To turn this idea into reality, the formal descriptions of software components need to specify more than the type signatures of their exported services. At a minimum, they should contain assertions about critical properties of a component's behavior. By monitoring such behavioral contracts at run-time, language implementations can pinpoint faulty components, and programmers can replace them with different ones. In this paper, we study the notion of behavioral contracts in an object-oriented setting. While the use of behavioral contracts is well-understood in the world of procedural languages, their addition to object-oriented programming languages poses remarkably subtle problems. All existing contract enforcement tools for Java fail to catch flaws in contract...

Abstract not found

This papers presents a radically new approach for the dynamic evolution of long-lived systems that can not easily be shut-down for maintenance and restarted afterwards. Conventionally, the source code of a software system is viewed as a static entity and separated from the system at runtime. This seems intuitive as a single piece of code is usually associated with multiple components at runtime. Obviously, this viewpoint is a major obstacle for dynamic evolution during runtime as it raises di#cult consistency issues concerning the relationship between static code and the dynamically executing system. The evolution approach presented in this paper takes a completely di#erent direction by seamlessly integrating static code with dynamic execution. By this and sound concepts for component categories, incompleteness and dynamic completion, software can be generalized and adapted during runtime in a highly flexible way.

Abstract not found