This article describes the concepts and strategies that have guided the design and implementation of this simulator, with emphasis on those features that are particularly relevant to its most efficient use. 1.1 The problem domain

Abstract: After a period of oblivion, a renewal of interest in coroutines is being observed. However, most current implementations of coroutine mechanisms are restricted, and motivated by particular uses. The convenience of providing true coroutines as a general control abstraction is disregarded. This paper presents and discusses the coroutine facilities provided by the language Lua, a full implementation of the concept of asymmetric coroutines. It also shows that this powerful construct supports easy and succint implementations of useful control behaviors.

Abstract. A variety of application domains are interactive in nature: a primary task involves responding to external actions. In this paper, we introduce explicit programming language support for interactive programming, via the concept of a responder. Responders include a novel control construct that allows the interactive logic of an application to be naturally and modularly expressed. In contrast, the standard approaches to interactive programming, based on the event-driven style or the state design pattern, fragment this logic across multiple handlers or classes, with the control flow among fragments expressed only indirectly. We describe ResponderJ, an extension to Java supporting responders. A responder is simply a class with additional abilities, and these abilities interact naturally with the existing features of classes, including inheritance. We have implemented ResponderJ as an extension to the Polyglot compiler for Java. We illustrate ResponderJ’s utility in practice through two case studies: the implementation of a GUI supporting drag-and-drop functionality, and a re-implementation of the control logic of JDOM, a Java library for parsing and manipulating XML files. 1

Pure Python code is slow, primarily due to the dynamic nature of the language. I have begun building a compiler to produce fast native code from Python source programs. While compilation can improve performance, any such gains will be modest unless the compiler can statically resolve most of the dynamism present in source programs. Static type inference for Python programs would enable the safe removal of most type checks and most instances of dynamic dispatch and dynamic binding from the generated code. Removing dynamic dispatch and binding leads to large performance benefits since their existence precludes many traditional optimization techniques, such as inlining. I have built a static type inferencer for Python called Starkiller. Given a Python source file, it can deduce the types of all expressions in the program without actually running it. Starkiller’s primary goal is to take a Python source program as input and deduce the information needed to make native code compilation of that program easy. This paper is describes Starkiller’s design and operation. It is partially

The Iterator design pattern allows client code to access the elements of an aggregate object sequentially without exposing its underlying representation. Several modern

This paper defends the revival of coroutines as a general control abstraction. After proposing a new classification of coroutines, we introduce the concept of full asymmetric coroutines and provide a precise definition for it through an operational semantics. We then demonstrate that full coroutines have an expressive power equivalent to one-shot continuations and oneshot partial continuations. We also show that full asymmetric coroutines and one-shot partial continuations have many similarities, and therefore present comparable benefits. Nevertheless, coroutines are easier implemented and understood, specially in the realm of procedural languages. Finally, we provide a collection of programming examples that illustrate the use of full asymmetric coroutines to support direct and concise implementations of several useful control behaviors, including cooperative multitasking.

ion requires the data structure interface be independent of the implementation. Hence, a user 2.5. GENERATOR 15 #include <uC++.h> #include <uIOStream.h> struct seqNode : public uSeqable { // inherit forward and backward link fields int v; seqNode( int v ) : v( v ) {} }; void uMain::main() { uSequence<seqNode> seq; // top pointer to list uSeqGen<seqNode> gf; // forward traversal of list uSeqGenRev<seqNode> gr; // backward traversal of list seqNode * f, * r; // pointer to list element // create list . . . // print list in both directions for ( gf.uOver(seq), gr.uOver(seq); gf >> f & gr >> r; ) { uCout << f->v << " " << r->v << " "; } uCout << endl; . . . } Figure 2.2: Sequence and Sequence Generator cannot construct a loop that accesses any of the link fields in the data structure, precluding any form of direct traversal. Therefore, a mechanism is needed that indirectly traverses the structure without exposing the internal representation. Several different names are ...

We introduce Higher Order Messaging, a higher order programming mechanism for dynamic object-oriented languages. Higher Order Messages allow user-defined message dispatch mechanism to be expressed using an optimally compact syntax that is a natural extension of plain messaging and also have a simple conceptual model. They can be implemented without extending the base language and operate through language bridges.

Sather is an object oriented language designed to be simple, efficient, safe, and nonproprietary. It was originally envisioned as a "cleaned-up" version of Eiffel, addressing perceived failures in simplicity and efficiency. The first public implementation (Sather 0) was first released to the public by ICSI in 1991. Shortly after, a compiler group at the University of Karlsruhe created the first native code compiler. A major effort then began to redesign the language to correct shortcomings in Sather 0 and to make Sather suitable for general-purpose, large scale programming. In part because each compiler group was building a compiler for a moving design target, the two parallel efforts resulted in two dialects, Sather 1 and Sather K. This report analyzes the essential causes of the differences, which result from differences in each group's goals. 1 Introduction Sather is an object oriented language designed to be simple, efficient, safe, and nonproprietary. Sather was originally deve...

A complete traversal of a container C (such as a set) is informally described by the iteration scheme for all x 2 C F(x; C) where F is a function that might possibly modify C by inserting new elements into it. We assume that the order in which the elements are treated is not relevant, as long as the iteration continues until F has been applied to all elements currently in C, including those F has inserted. Standard iteration mechanisms, such as the iterators provided in the C++ Standard Template Library (STL), do not directly support complete traversals. In this paper we present two approaches to complete traversals, both extending the STL framework, one by means of generic algorithms and the other by means of a container adaptor.