De nition of a Re ective Kernel for a Prototype-Based ... - CiteSeerX

De nition of a Re ective Kernel for a Prototype-Based Language Philippe Mulet, Pierre Cointe Ecole des Mines de Nantes 3, rue Marcel Sembat 44049 Nantes Cedex 04 (+33) 40.44.83.87 - Fax (+33) 40.71.97.40 [mulet,cointe]@info.emn.fr

Abstract

We present the implementation of Moostrap, a re ective prototype-based language, the interpreter of which is written in Scheme. Moostrap is based on a reduced number of primitives, according to a previous work for de ning a taxonomy for prototype-based languages. Our purpose is to reify the behavior of any object through two steps: the slot lookup and its application. The rst phase is rei ed thanks to behavioral metaobjects, and the second is managed by special objects, called slot-executants. This kernel does not handle any implicit delegation at rst. However, we introduce it, as a rst extension of the basic language using a new behavioral meta-object. Keywords: Prototype, Re ection, Primitive, Slot, Creation, Cloning, Delegation, Extensibility, Behavior, Meta-Object, Self, Smalltalk, Scheme.

1 Introduction Our general area of research is the study of re ection in object-oriented languages (OOLs). We have previously de ned a model of behavioral re ection expressing the computation of a message as the combination of a message lookup and a message application. We have implemented and experimented this model in a newly de ned prototypebased language, which bootstraps itself from a reduced set of primitives, and named Moostrap (standing for \Mini Object Oriented System Towards Re ective Architectures for Programming"). The purpose of this paper is to describe this re ective language. Moostrap belongs to the family of prototype-based languages, a basic alternative to class-based languages. Indeed, we decided to free our language from classes, because they hardly deal with one-of-a-kind objects. Furthermore, we believe that classes interfere with the \emerging" notion of meta-objects [MDC92]. Initially, we realized a Smalltalk'80 implementation of the Self 1.0 prototype-based language [MR91], that we then extended to perform re ective computation [CMDM92].

Our purpose was also to add re ective facilities to control the computation rules of message sending. In standard Self, prototype structure can be consulted thanks to mirror objects [CUL89]. These rst-class objects are created explicitly to provide an interface between a prototype and its internal representation. Unfortunately, mirrors are not causally connected to the internal structure they only give a reading access to and are mainly used to create virtual slot-descriptor objects [MCD91]. In fact, mirrors are not supposed to play the role of behavioral meta-objects; we rather decided to introduce explicit metaobjects (to handle the lookup) and a new rei cation mechanism for slots (to handle the application process and to allow slot extension). This approach allowed us to roughly validate our scheme for behavioral re ection in the context of Self. However our explicit rei cation of slots was not nicely integrated to Self, and rather than changing the kernel of Self (and its virtual machine) we decided to design our own language and to implement its rst interpreter in Scheme [Sch89]. This paper is divided into four parts. We rst describe Moostrap as a prototypebased language, then we introduce the re ective model of this language. In a third part, we extend the kernel, thanks to re ective facilities, in order to add implicit delegation, a kind of inheritance between prototypes. Then we present some implementation details and conclude on our future work.

2 Moostrap: a Tiny Prototype-Based Language The taxonomy of prototype-based languages, established in [DMC92], assumes that these languages are basically built on objects communicating by message sending and supporting cloning facilities. The classi cation is then made according to the following criteria: representation of information either uni ed as slots or separated as variables and methods, dynamic modi cation of object structures, ex-nihilo objects creation, explicit or implicit delegation, and handling of split-objects due to delegation. According to this taxonomy, Moostrap is classi ed as a language where the prototypes store information as slots. It allows dynamic modi cation of prototype structures, creation of objects ex-nihilo empty or even with an initialized structure, but does not provide any mechanism of delegation. This is however supplied by implicit sharing between prototypes achieved by a primitive for adding shared slots.

2.1 Components of the Language The set of primitives of Moostrap prototype-based language is deliberately kept small. Ex-nihilo objects can be created thanks to a special syntax; we only regard as primitives the following operations: cloning objects, adding slots to an object or removing them.

2.1.1 Ex-Nihilo Declaration of Prototypes Prototypes are made up of slots. In Moostrap, the notion of slot corresponds to an association ( name value ), a type of dynamic binding. We distinguish two kinds of



slots: data slots and function slots. Data slots are themselves divided into two categories: mutable and immutable slots. Function slots are immutable slots.

Data Slots

The distinction between mutable and immutable slots occurs at declare time, as in Self [CUL89], according to the following syntax: ( name = value ) declaration of an immutable data slot. The value of the slot is computed at creation time, and cannot be changed afterwards. In fact, the slot produced by such a declaration is only a reading accessor to the data stored. ( name - value ) declaration of a mutable data slot. The value is used for initializing the slot, and can be changed afterwards at will. For such a declaration, the system builds in fact two slots, like in Self: a reading accessor (named as the declared mutable slot) that contains the real data to be stored, and a writing accessor (the name of which is obtained by adding the sux \:" to the declared slot name), which is an assignment slot for updating the slot containing the data. Examples:  (x = 1) declaration of an immutable slot.




false

Extending Message Sending

Like Smalltalk and Self, Moostrap can be extended to provide conditionals using its only existing control structure, i.e, message sending. We introduce the notion of block, representing the evaluation of a sequence of expressions, which is delayed until the block receives the message \value". (-block (arg1 arg2

:::

argn)

: : :

)

Example: Method computing the factorial of its argument recursively. (fact (n) ((n = 0) ifTrueIfFalse (-block () 1) (-block () ((self fact (n - 1)) * n)))) Supposing that hall object owns the fact method. (hall fact 3) ---> 6

2.1.3 Extending and Modifying Prototypes We de ned two primitives inspired by Self, to modify the structure of objects.  Adding slots: -addSharedSlots. Use: (anObject -addSharedSlots anotherObject) It adds all the slots owned by anotherObject to the receiver anObject. Invoking this primitive results in having all the slots of anotherObject shared between anotherObject and anObject. Gathering in the same object several slots having the same name is not allowed, therefore the redundant slots of anObject are replaced by those of anotherObject.  Removing a slot: -removeSlot. Use: (anObject -removeSlot aString) This primitive removes the slot named aString from anObject.

2.1.4 Cloning Cloning is a fundamental aspect of prototype-based languages; it plays the same creation role as instantiation for class-based languages. The primitive -clone copies already existing objects. It creates a shallow copy of the receiver, i.e. the clone object is a set of new slots, sharing respectively the same values with the original object (cf. gure 1).

(p1 -clone)

p1 x x:

1