. We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF's lack of classes and explicit variables. To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information and eliminating the apparent space overhead for prototype-based systems. To compensate for dynamic typing, user-defined control structures, and the lack of explicit variables, our system dynamically compiles multiple versions of a source method, each customized according to its receiver's map. Within each version the type of the receiver is fixed, and thus the compiler can statically bind and inline all messages sent to self. Message splitting and type prediction extract and preserve even more static type information, allowing the compiler to inline ma...

Abstract. We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF’s lack of classes and explicit variables. To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information and eliminating the apparent space overhead for prototype-based systems. To compensate for dynamic typing, user-defined control structures, and the lack of explicit variables, our system dynamically compiles multiple versions of a source method, each customized according to its receiver’s map. Within each version the type of the receiver is fixed, and thus the compiler can statically bind and inline all messages sent to self. Message splitting and type prediction extract and preserve even more static type information, allowing the compiler to inline many other messages. Inlining dramatically improves performance and eliminates the need to hard-wire low-level methods such as +, ==, and ifTrue:. Despite inlining and other optimizations, our system still supports interactive programming environments. The system traverses internal dependency lists to invalidate all compiled methods

. Any multiprocessing facility must include three features: elementary exclusion, data protection, and process saving. While elementary exclusion must rest on some hardware facility (e.g., a test-and-set instruction), the other two requirements are fulfilled by features already present in applicative languages. Data protection may be obtained through the use of procedures (closures or funargs), and process saving may be obtained through the use of the catch operator. The use of catch, in particular, allows an elegant treatment of process saving. We demonstrate these techniques by writing the kernel and some modules for a multiprocessing system. The kernel is very small. Many functions which one would normally expect to find inside the kernel are completely decentralized. We consider the implementation of other schedulers, interrupts, and the implications of these ideas for language design. 1. Introduction In the past few years, researchers have made progress in understanding the mecha...

The IEEE/ANSI standard for Scheme requires implementations to be properly tail recursive. This ensures that portable code can rely upon the space efficiency of continuation-passing style and other idioms. On its face, proper tail recursion concerns the efficiency of procedure calls that occur within a tail context. When examined closely, proper tail recursion also depends upon the fact that garbage collection can be asymptotically more space-efficient than Algol-like stack allocation. Proper tail recursion is not the same as ad hoc tail call optimization in stack-based languages. Proper tail recursion often precludes stack allocation of variables, but yields a well-defined asymptotic space complexity that can be relied upon by portable programs. This paper offers a formal and implementation-independent definition of proper tail recursion for Scheme. It also shows how an entire family of reference implementations can be used to characterize related safe-for-space properties, and proves ...

We describe a small set of additions to Scheme to support objectoriented programming, including a form of multiple inheritance. The extensions proposed are in keeping with the spirit of the Scheme language and consequently differ from Lisp-based object systems such as Flavors and the Common Lisp Object System. Our extensions mesh neatly with the underlying Scheme system. We motivate our design with examples, and then describe implementation techniques that yield efficiency comparable to dynamic object-oriented language implementations considered to be high performance. The complete design has an almost-portable implementation, and the core of this design comprises the object system used in T, a dialect of Scheme. The applicative bias of our approach is unusual in object-oriented programming systems. This report describes research done at the Artificial Intelligence Laboratory of the Massachusetts Institute of Technology. Support for the laboratory's artificial intelligence research is ...

Computer programming environments for learning should make it easy to create worlds of responsive and autonomous objects, such as video games or simulations of animal behavior. But building such worlds remains difficult, partly because the models and metaphors underlying traditional programming languages are not particularly suited to the task. This dissertation investigates new metaphors, environments, and languages that make possible new ways to create programs -- and, more broadly, new ways to think about programs. In particular, it introduces the idea of programming with "agents" as a means to help people create worlds involving responsive, interacting objects. In this context, an agent is a simple mechanism intended to be understood through anthropomorphic metaphors and endowed with certain lifelike properties such as autonomy, purposefulness, and emotional state. Complex behavior is achieved by combining simple agents into more complex structures. While the agent metaphor enables...

The traditional Lisp macro expansion facility inhibits several important forms of expansion control. These include selective expansion of subexpressions, expansion of subexpressions using modified expansion functions, and expansion of application and variable expressions. Furthermore, the expansion algorithm must treat every special form as a separate case. The result is limited expressive power and poor modularity. We propose an alternative facility that avoids these problems, using a technique called expansion-passing style (EPS). The critical difference between the facility proposed here and the traditional macro mechanism is that expansion functions are passed not only an expression to be expanded but also another expansion function. This function may or may not be used to perform further expansion. The power of this technique is illustrated with several examples. Most Lisp systems may be adapted to employ this technique.

This paper describes a way of expressing --expressions (which produce closures) in terms of ffl--expressions (--expressions containing only local and global variable references) and calls to an interactive compiler that compiles ffl--expressions. This point of view is an interesting way of describing the semantics of --expressions and closure generation. It also leads to an efficient closure implementation both in time and space. A closure is uniformly represented as a piece of code instead of a compound object containing a code and environment pointer. This method can also be used to simulate closures in conventional dialects of Lisp. KEY WORDS Closure implementation Compiling Lisp Scheme Published in: Journal of Computer Languages, Vol. 17, No. 4, pp. 251-267, Pergamon Press, 1992. 1 INTRODUCTION In many lexically scoped dialects of Lisp, e.g. Scheme[1-3], T[4,5] and Common Lisp[6], procedures are first class objects. They are defined by --expressions of the form (lambda formal-...

Abstract. This paper introduces the Trusted Execution Module (TEM); a high-level specification for a commodity chip that can execute usersupplied procedures in a trusted environment. The TEM is capable of securely executing partially-encrypted procedures/closures expressing arbitrary computation. These closures can be generated by any (potentially untrusted) party who knows the TEM’s public encryption key. Compared to a conventional smartcard, which is typically used by pre-programming a limited set of domain- or application- specific commands onto the smartcard, and compared to the Trusted Platform Module (TPM), which is limited to a fixed set of cryptographic functions that cannot be combined to provide general-purpose trusted computing, the TEM is significantly more flexible. Yet we present a working implementation using existing inexpensive Javacard smartcards that does not require any export-restricted technology. The TEM’s design enables a new style of programming, which in turn enables new applications. We show that the TEM’s guarantees of secure execution enable exciting applications that include, but are not limited to, mobile agents, peer-to-peer multiplayer online games, and anonymous offline payments. 1

ion This principle aims at grouping things together into classes such that common properties of the members can be identified. For example, it is useful to classify all individual participants of a road traffic scenario as vehicles that have properties like size, speed and direction of movement. Collectively, the instances of a class form the extension of that class. Object-oriented languages provide support for classification by allowing to define classes that describe the properties of their instances. Aggregation This principle allows to form new concepts as collections of other concepts. For example, vehicles such as semitrucks are entities composed of parts such as cabin and trailer, each of these again being composed of wheels, axles, etc. In programming, aggregation is achieved by compound data structures that are called objects in the framework of object-oriented programming