Sina/st - trese - Universiteit Twente

Universiteit Twente 

<strong>Sina</strong>/st 

faculteit der 

informatica 

On the Definition and 

Implementation of the 

<strong>Sina</strong>/st Language 

M.Sc. Thesis 

Piet S. Koopmans 

August 25, 1995

On the Definition and 

Implementation of the <strong>Sina</strong>/st 

Language 

Graduation Committee: 

Dr.Ir. M. Aksit (supervisor) 

Dr.Ir. L.M.J. Bergmans 

Ing. R.R. van de Stadt 

M.Sc. Thesis 

by 


Enschede 

August 25, 1995

Abstract 

The object-oriented paradigm provides features that are very useful to obtain extensible, 

reusable, and robust software. The conventional object-oriented model supports objects, 

classes, encapsulation, inheritance, part-whole relations, and polymorphic message 

passing. The current object oriented methods, languages and tools, however, have a 

number of deficiencies that make them less suitable for certain categories of applications. 

For this, the TRESE project of the University of Twente, the Netherlands developed the 

composition filters object model which is capable of solving a number of the deficiencies. 

The composition filters object model, an extension to the object-oriented model, 

introduces input and output composition filters which affect the received and sent 

messages respectively. The programming language <strong>Sina</strong> is used to express the concepts of 

the composition filters object model. <strong>Sina</strong> is a real-time concurrent object-oriented 

programming language which adopts the composition filters object model. 

This thesis describes the definition and the implementation of the concurrent object-oriented 

programming language <strong>Sina</strong>⁄st , a Smalltalk implementation of <strong>Sina</strong>. The syntax and 

semantics of the <strong>Sina</strong>⁄st language are described and illustrated with numerous examples. 

We introduce techniques for the implementation of composition filters. The 

implementation addresses the specific features of the composition filters object model: 

reflection on messages, concurrency and synchronization. 

One of the five filters that are provided by this implementation, allows to abstract 

communications among objects into a first-class object called abstract communication 

type (ACT). After an ACT has gained control over a received or sent message, it can 

release the message by letting the message follow its further course, or by supplying a 

reply for the message. In addition to these two methods, we introduces a new way to 

release the message. This allows an ACT to regain control over a message as soon as this 

message receives a reply object. 

The presented <strong>Sina</strong>⁄st implementation provides a programming environment, which 

includes a user interface that allows the user to edit, compile and execute a <strong>Sina</strong>⁄st 

application, a compiler that translates <strong>Sina</strong>⁄st source code to Smalltalk, and a kernel for 

run-time support. This environment can be used to verify and implement applications 

which adopt the composition filters object model. 

On the Definition and Implementation of the <strong>Sina</strong>/st Language 

iii

iv 

Samenvatting 

Het object-georiënteerde paradigma heeft eigenschappen die zeer nuttig zijn voor het 

ontwikkelen van uitbreidbare, herbruikbare en robuuste software. Het conventionele 

object-georiënteerde model biedt objecten, klassen, overerving, part-whole relaties en 

polymorfe message passing. De huidige object-georiënteerde methoden, programmeertalen 

en gereedschappen hebben echter een aantal tekortkomingen waardoor ze minder 

geschikt zijn voor bepaalde categorieën van applicaties. 

Hiertoe heeft het TRESE project van de Universiteit Twente (Enschede, Nederland) het 

compositie filters object model ontwikkeld. Het compositie filters object model is een 

uitbreiding van het object-georiënteerde model en kan een aantal van de tekortkomingen 

van dit model oplossen. Het compositie filters object model beschikt over invoer en 

uitvoer compositie filters die respectievelijk ontvangen en verzonden berichten 

beïnvloeden. De programmeertaal <strong>Sina</strong> maakt het mogelijk om de concepten van dit model 

uit te drukken. <strong>Sina</strong> is een real-time, concurrente, object-georiënteerde programmeertaal 

die gebruik maakt van het compositie filters object model. 

Dit doctoraalverslag beschrijft de definitie en implementatie van de concurrente, objectgeoriënteerde 

programmeertaal <strong>Sina</strong>⁄st , een Smalltalk implementatie van <strong>Sina</strong>. De syntax 

en semantiek van <strong>Sina</strong>⁄st worden beschreven en geïllustreerd met diverse voorbeelden. 

In het verslag worden verder technieken voor het implementeren van compositie filters 

geïntroduceerd. Daarbij wordt rekening gehouden met de specifieke eigenschappen van 

het compositie filters object model, zoals reflectie op berichten, concurrentie en 

synchronisatie. 

Een van de vijf filters die deze implementatie biedt, maakt het mogelijk om communicatie 

tussen objecten te abstraheren in first-class objecten, welke abstracte communicatie typen 

(ACT) worden genoemd. Nadat een ACT controle over een ontvangen of verzonden 

bericht heeft verkregen, kan deze het bericht weer vrijgeven door het bericht zijn normale 

gang te laten gaan, of door een antwoord-object voor het bericht beschikbaar te stellen. Dit 

doctoraalverslag introduceert een nieuwe mogelijkheid voor het vrijgeven van het bericht. 

Hiermee krijgt de ACT weer controle over het bericht zodra het bericht een antwoordobject 

krijgt. 

De beschreven <strong>Sina</strong>⁄st implementatie heeft de beschikking over een programmeeromgeving 

die bestaat uit een gebruikers interface waarmee de gebruiker <strong>Sina</strong>⁄st applicaties 

kan schrijven, vertalen en uitvoeren. Daarnaast heeft de programmeer-omgeving een 

vertaler die <strong>Sina</strong>⁄st bron code vertaalt naar Smalltalk, en een kern voor ondersteuning 

tijdens run-time. Deze programmeer-omgeving kan worden gebruikt voor het verifiëren en 

implementeren van applicaties die gebruik maken van het compositie filters object model. 

Samenvatting

Voorwoord 

Met het voltooien van dit doctoraal verslag zit mijn studie Informatica aan de Universiteit 

Twente in Enschede er dan eindelijk op. Ondanks een aantal moeilijkheden die ik 

ondervond, heb ik met veel plezier bij het TRESE project aan mijn doctoraal opdracht 

gewerkt. Vooral het afgelopen half jaar is stimulerend geweest voor het afronden van mijn 

studie. In deze periode heb ik, naast het afstuderen, ook nog aan andere activiteiten binnen 

het TRESE project mogen meewerken. 

Ik wil dan ook Mehmet Aksit, Lodewijk Bergmans en Richard van de Stadt hartelijk 

bedanken. Niet alleen voor de technische adviezen tijdens het afstuderen, maar vooral ook 

voor het vertrouwen, en de aanmoedigingen om door te gaan. 

Daarnaast wil ik ook Bonne van Dijk noemen. Met hem heb ik vele discussies mogen 

voeren en ook hij heeft mij gestimuleerd om door te zetten. 

Tot slot wil ik mijn kamergenoten Bedir Tekinerdogan en Francesco Marcelloni bedanken. 

De gezamenlijke koppen koffie en thee zijn niet meer te tellen. 



Enschede, 30 augustus 1995 

v

Contents 

Part i Introduction 1 

1 Introduction 3 

1.1 Deficiencies in object-oriented technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.2 The composition filters object model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

1.2.1 Solving modeling problems with composition filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.3 The past, present, and future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

1.4 Problem statement and approach of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

1.5 Outline of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Part ii Definition of the <strong>Sina</strong>⁄st language 13 

2 Language survey 15 

2.1 The composition filters object model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.1.1 The inner object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.1.2 The composition filters object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.2 A composition filters object in <strong>Sina</strong>/st . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2.1 The interface part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.2.2 The implementation part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.2.3 The main method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

2.3 Forthcoming chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

2.3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

2.3.2 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

2.3.3 Structure of a <strong>Sina</strong>/st program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

2.3.4 Where to find what . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

3 Basic language elements 23 

3.1 Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

3.2 Literal constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.2.1 Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.2.2 Strings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.2.3 Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.2.4 The constants nil, true and false . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.3 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.3.1 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

3.3.2 Typedescription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

3.3.3 Initial value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

3.3.4 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

3.4 Global externals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 


vii

viii 

3.5 Pseudo variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

4 Expressions 31 

4.1 Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

4.2 Message expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

4.3 Operator expression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 

5 Control structures 37 

5.1 The conditional statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5.2 The for statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5.3 The while statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 

6 Classes and instances 39 

6.1 Class declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

6.1.1 The interface part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

6.1.2 The implementation part. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 

6.1.3 Class switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

6.2 An instance of a class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 

6.3 The object manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 

7 Methods 45 

7.1 Interface method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

7.2 Private method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

7.3 Initial method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

7.4 Main method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

7.5 Returning a value from a method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

7.6 Normal versus early return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

7.7 Method invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

7.8 Statements in a method body. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 

8 Conditions 57 

8.1 Condition declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

8.2 Condition implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 

8.3 Using a condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

9 Filters 61 

9.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

9.2 Input and output filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

9.3 Filterdeclaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

9.3.1 Reused filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

9.3.2 Local filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

9.3.3 Rewrite rules for filterelements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 

9.4 Filtering a message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 

9.5 The signature of an object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 

9.6 Filterhandlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

9.6.1 Dispatch filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

9.6.2 Error filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

9.6.3 Send filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

9.6.4 Wait filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

9.6.5 Meta filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 

Contents

10 Message passing semantics 73 

10.1 Sending a message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

10.2 The pseudo variable message and class ActiveMessage . . . . . . . . . . . . . . . . . . . . . . . . 75 

10.3 Concurrency with threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

10.4 Message reification and dereification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 

10.4.1 Message reification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 

10.4.2 Message dereification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

10.4.3 Multiple reifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

10.4.4 Writing ACT methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

10.5 The class <strong>Sina</strong>Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 

Part iii Implementation of the <strong>Sina</strong>⁄st language 89 

11 Implementation Approach 91 

11.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 

11.2 Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

11.3 Overview of the implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 

12 Execution Model 95 

12.1 Overview of message execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 

12.2 Representation of an active message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 

12.3 Filtering a message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

12.3.1 Message handling by a filter group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

12.3.2 Message handling by a filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 

12.3.3 The signature of an object and signature matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 

12.4 Filter handler classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 

12.4.1 Dispatch filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 

12.4.2 Error filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

12.4.3 Send filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

12.4.4 Meta filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

12.4.5 Wait filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

12.5 Method invocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

12.5.1 Normal and early returning methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

12.6 Message reification and dereification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 

12.7 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 

12.8 <strong>Sina</strong>⁄st messages to Smalltalk objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 

13 Translation Model 119 

13.1 General object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 

13.2 Instance creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 

13.3 Detecting if a method returns normal or early. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 

13.4 Mapping <strong>Sina</strong> to Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 

14 Programming environment 127 

14.1 Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 

14.2 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

14.3 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

The Implementation of the <strong>Sina</strong>/st Language 

ix

x 

Part iv Evaluation and Conclusions 133 

15 Evaluation 135 

15.1 <strong>Sina</strong>⁄st language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 

15.2 <strong>Sina</strong>⁄st implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

15.2.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

15.2.2 Encountered problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

15.2.3 Known bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

15.2.4 Performance comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

16 Conclusions 141 

16.1 Overview and contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

16.1.1 Definition of the <strong>Sina</strong>⁄st language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

16.1.2 Implementation of the <strong>Sina</strong>⁄st language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

16.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

16.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

Part v Appendices 145 

A <strong>Sina</strong> Class Interfaces 147 

A.1 <strong>Sina</strong>Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 

A.2 ActiveMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 

A.3 <strong>Sina</strong>Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 

A.4 ObjectManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 

B Using Smalltalk classes in <strong>Sina</strong>⁄st 151 

B.1 <strong>Sina</strong>⁄st variable declaration using a Smalltalk class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 

B.2 Smalltalk selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 

C <strong>Sina</strong>⁄st syntax definition 155 

C.1 Token class specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 

C.2 Grammar specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 

D Conversion algorithm 165 

D.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 

D.2 A closer look at the filter initializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 

D.3 Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

D.4 The algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

References 173 

Index 177 

Contents

PART 

i Introduction 


On the Definition and Implementation of the <strong>Sina</strong>/st Language

1 Introduction 

This thesis describes the definition and an approach for the implementation of the 

programming language <strong>Sina</strong>⁄st . <strong>Sina</strong>⁄st is a Smalltalk implementation of the concurrent 

object-oriented programming language <strong>Sina</strong>. The <strong>Sina</strong> language incorporates the 

composition filters object model which aims at solving a number of obstacles that are not 

properly addressed by current object-oriented programming languages and software 

development methods. The first section of this chapter describes these shortcomings. 

Some of the deficiencies of conventional object-oriented technology can be solved by the 

composition filters object model. This object model is an extension to the conventional 

object-oriented model, and can express several concepts, such as inheritance, delegation, 

synchronization, reflection on communication among objects, and real-time specifications 

(section 1.2) 

<strong>Sina</strong>⁄st , <strong>Sina</strong> and the composition filters object model have been developed by the TRESE 

project 1 at the University of Twente, during several years of research. Section 1.3 gives an 

overview of their evolution. 

Section 1.4 defines the problem statement, and describes the approach to the problem. This 

chapter ends by showing the outline of this thesis. 

1.1 Deficiencies in object-oriented technology 

The object-oriented model provides features that are very useful for a large category of 

applications to obtain extensible, reusable, and robust software. The conventional objectoriented 

model supports objects, classes, encapsulation, inheritance, part-whole relations, 

and polymorphic message passing [Wegner87]. The current object oriented methods, 

languages and tools, however, have a number of deficiencies that make them less suitable 

for certain categories of applications. 

The TRESE project has carried out several pilot projects in order to identify the 

shortcomings of current object-oriented technology [Aksit92a] [Aksit95]. This research 

concludes that the deficiencies of the current object-oriented technology can be divided in 

methodological and modeling problems. 

1. Twente Research & Education on Software Engineering, a research project of the SETI group at the 

Department of Computer Science, University of Twente, Enschede, The Netherlands. 


3

4 

Methodological 

problems 

Methodological problems arise if object-oriented software development methods are 

utilized. The difficulties experienced in applying object-oriented analysis and design 

methods are addressed by other research. 

Modeling problems Modeling problems are due to the fact that object-oriented models are not capable of 

expressing certain aspects of applications. This category of problems is addressed by the 

composition filters object model. 

We now describe these modeling problems and indicate in which application domains they 

can be experienced. We classify application domains into a number of basic domains. A 

typical application may comprise several basic domains. The basic domains include 

application generators, concurrency and synchronization, constraint systems, control 

systems, databases, distribution, knowledge processing, numerical (CAD) modeling, realtime, 

and user interfaces. 

After the composition filters object model has been introduced (section 1.2), it is 

demonstrated how composition filters can solve the modeling problems. The alphabetical 

list of these problems and associated application domains is as follows: 

• Atomicity and inheritance (databases and distributed systems) 

Atomic actions are a mechanism to preserve consistency, for example in databases 

where they are called transactions. Due to the conventional procedure-call like 

semantics of transactions, they do not integrate uniformly with object-oriented 

concepts, especially inheritance. 

• Coordinated behavior (control systems, databases, distributed systems, real-time 

applications and user-interfaces) 

Coordinated behavior can be encountered for example in control systems, in which 

several distinct units, such as controlling algorithms, sensors and actuators, must work 

together in order to keep the controlled system in a consistent state. 

In the object-oriented model, objects interact with each other by sending messages, 

where the client object transmits a message to a server object, and depending on the 

synchronization semantics, it either waits until the server object explicitly returns from 

performing its task or continues with its processing. The object-oriented models do not 

provide high-level mechanisms to abstract coordinated behavior among several objects 

since message passing semantics only involves two partner objects. To implement 

coordinated behavior, the application code must be spread over several entities which 

means that the application becomes more complex, less reusable, while its interaction 

semantics is more difficult to enforce and verify. 

• Duality in conception between object databases and languages (databases) 

In most of the current object-oriented language-database systems programming 

language and database models are still separated. There are special constructs 

separated from the language to access the database facilities, and often queries can only 

be applied on a fixed number of objects. 

• Dynamic inheritance and delegation (all application domains) 

Dynamic inheritance (dynamic delegation) means that the inheritance hierarchy 

(delegation structure) is not fixed, but that an object can specify a set of superclasses 

(delegated objects) from which it may possibly inherit (delegate to). Dynamic 

inheritance or delegation can be needed if an application must be able to adapt for 

performance reasons or space requirements, to different clients or contexts, or even to 

different hardware, as for example in distributed systems. 

• Excessive class declarations (non-parameterized hierarchies) (all application 

domains) 

Excessive class declarations can be experienced when all meaningful combinations of 

classes must be composed with (multiple) inheritance and declared as a separate class. 

Chapter 1: Introduction

Because every possible combination must be represented explicitly in the inheritance 

hierarchy, this hierarchy easily becomes unmanageable. 

Consider for example a graphical application which needs to draw points on a display. 

The class Point represents such a display point. Class HistoryPoint inherits from Point 

and keeps a list containing the sequence of locations the point has had. Class 

BoundedPoint has restricted display coordinates and also inherits from Point. Class 

BoundedHistoryPoint combines the features of HistoryPoint and BoundedPoint and 

therefore inherits from both these two classes. 

Assume now that, for the drawing of lines, we want to define class SolidLine which 

inherits from Point. DashedLine inherits from SolidLine but draws dashed lines instead 

of solid lines. If all the combinations of these classes are meaningful then one needs to 

declare all the possible combinations as a separate class, such as Point, HistoryPoint, 

BoundedPoint, BoundedHistoryPoint, SolidLine, DashedLine, HistorySolidLine, 

BoundedSolidLine, BoundedHistorySolidLine, HistoryDashedLine, BoundedDashed- 

Line, BoundedHistoryDashedLine. The inheritance hierarchy will grow further if we 

add more classes to the hierarchy. For example, creating class 3DimensionalPoint as a 

subclass of Point doubles the number of class declarations. 

• Fixed message passing semantics (concurrency and synchronization, user interfaces) 

Although message passing is a key feature in the object-oriented model, the semantics 

of message passing is fixed by the adopted language, or, at best, can be selected from a 

limited set of fixed semantics. Message passing semantics may include remote 

procedure call mechanism, asynchronous message passing, broadcast and multicasting 

of messages, and atomic message send semantics. In most languages, these 

fixed semantics cannot be tailored to model application specific interaction 

mechanisms, while it is even harder to abstract and reuse them. 

• Inheritance versus real-time (real-time systems) 

When classes are reused in applications with different real-time behavior, changes to 

either the application requirements or the real-time specifications in subclasses may 

result in excessive redefinitions of superclasses while this may be intuitively 

unnecessary. This so called real-time specification anomaly can arise when real-time 

specifications have been mixed within the application code, when real-time 

specifications are not polymorphic (i.e. they cannot be used for more than one method), 

or when real-time specifications are orthogonally restricted (i.e. independently defined 

specifications cannot be combined through inheritance without redefinition of the 

related specifications). 

• Inheritance versus synchronization (concurrency and synchronization, user interfaces) 

Conflicts between inheritance and synchronization can appear when a class that 

implements synchronization is extended in a subclass by introducing new methods, 

overriding methods, or by adding synchronization constraints. When this requires 

additional redefinitions, this problem is considered to be an inheritance anomaly2 . 

For instance, when synchronization code is mixed with the application code (i.e. inside 

a method), changing synchronization is impossible without affecting the application 

code. Another source for inheritance anomalies comes from the non-decomposability 

of synchronization specifications in some languages. It is thus hard to add a new 

synchronization constraint, or to redefine a part of the synchronization specification in 

a subclass. 

• Multiple interfaces (views) (all application domains) 

Not all operations provided by an object are necessarily of interest to other objects that 

use its services. Therefore it is desirable to define interfaces for an object, 

differentiating between clients, that is, between the senders of a message. For example, 

a public mailbox should make a distinction between a postman and others, since 

2. This term is not restricted to synchronization. If the introduction of a new method or overriding an inherited 

method in a subclass requires additional redefinitions, this problem is an inheritance anomaly, because this 

should not be necessary. 


5

6 

everybody is allowed to put a letter in it, but only a postman is allowed to empty the 

mailbox. 

• Part-of versus inheritance (all application domains) 

A part in the analysis phase may be implemented by inheritance in the design phase, 

which means that there are conceptual differences between the analysis phase and 

design phase and this may result in changes in the object oriented model of the 

application. As an example, consider a rectangle. Conceptually, a rectangle can be 

described with two points, i.e. they are part of the rectangle. If we would like to 

emphasize reusability, a rectangle could be defined to inherit from class Point instead. 

• Lack of reflection (all domains, but typically in control systems, distributed systems, 

knowledge processing, and user interfaces) 

A reflective system is a system which incorporates models representing (aspects of) 

itself. This self representation is causally connected to the reflected entity, and 

therefore, makes it possible for the system to answer questions about itself and support 

actions on itself. Conventional object-oriented methods and languages do not, or only 

provide a limited support for reflection. 

• Sharing behavior with state (all application domains) 

In conventional object-oriented models, classes cannot conveniently express sharing 

behavior that is affected by shared state information. This is because, in general, 

classes are used to share behavior while their instances store their respective states. 

Sharing behavior with state is needed, for instance, when we want to model a company 

with several departments. Every department has a secretary who takes care of making 

appointments (shared behavior), and maintains the common agenda (shared state) of 

the department’s employees. When an employee is asked to make an appointment, he 

delegates this request to the secretary who takes the agenda and fix a time and date 

based on the employee’s working hours. 

• Unmatched system functionalities (all but specifically in constraint systems, databases, 

and distributed systems) 

The operating system generally provides services that are required by most 

applications. However, some applications may require specific functionalities which 

are not supported by it. These then, must be implemented by the software engineer. For 

example, only a few operating systems provide recovery mechanisms needed by a 

database application after a transaction has failed. 

1.2 The composition filters object model 

The composition filters object model extends the basic object-oriented model in a modular 

way. Its object model can be divided in two separate parts: an implementation part and an 

interface part. The implementation part is the kernel of an composition filters object and 

adheres to the conventional object-oriented model. The interface part is a layer that 

encapsulates the kernel object. This part contains the extensions which are made by the 

composition filters model. The interface part receives incoming messages, processes them, 

and optionally hands them over to the implementation part. The interface part additionally 

processes messages that are sent by the implementation part, and sends them to their 

respective targets. 

The extensions that are introduced by the composition filters object model comprise input 

and output composition filters. Input filters process received messages, while output filters 

process sent messages. Every filter has its own functionality which does not affect other 

filters: filters are orthogonal. Filters can be composed in arbitrary combinations. The 

combined functionalities of these filters are thus added to the kernel object (the 

implementation part). 

A filter specifies in a declarative way which messages it accepts. Whether the filter accepts 

a message depends on the message itself (typically its selector), and some designated 


conditions. These conditions can access the context of the message (e.g. its sender), and 

the state of its receiver. 

The composition filters object model defines the following filters: 

• dispatch filter: a dispatch filter offers a message to a specified target object for further 

processing. Conceptually, a dispatch filter realizes inheritance when the target object is 

encapsulated by (i.e. internal to) the receiver, and delegation when it is external to the 

receiver. In the former case, the target object represents the superclass. Associative 

inheritance and delegation3 is accomplished when conditions —which reflect the 

context or state of the receiver— are used to choose between several target objects. 

• wait filter: a wait filter is used to delay a message. Conditions specify the 

synchronization constraints. The message is allowed to continue when the 

synchronization conditions are met; 

• meta filter: a meta filter suspends a message and offers it to a designated object. This 

object, an abstract communication type (ACT), manipulates the message and releases 

it again. A meta filter allows an ACT to reflect on communication among objects; 

• error filter: an error filter raises an error exception for a message; 

• real-time filter: a real-time filter is able to affect timing constraints of a message; 

• send filter: a send filter offers a sent message its target. 

1.2.1 Solving modeling problems with composition filters 

The object-oriented modeling problems described in section 1.1 can be solved by using the 

composition filters object model. In this section we indicate how. 

• Atomicity and inheritance; 

Atomic messages have been introduced to support atomicity. Because they can be 

specified by every filter, atomic inheritance and delegation is provided for as well 

[Aksit91]. (this subject is not addressed by this thesis) 

• Coordinated behavior; 

An abstract communication type object can be used to coordinate the behavior among 

the group of objects. Messages between a pair of objects in this group can be 

intercepted by a meta filter, and offered to the coordinating object. Because the 

application code implementing the coordinated behavior has not been divided over the 

participating objects, it can be easily extended or replaced [Aksit93]. (refer to 

section 9.6.5, page 71 and section 10.4, page 77) 

• Duality in conception between object databases and languages; 

Database-like features can be accomplished by a dispatch filter, associative inheritance, 

and set operations. There is no separate language construct for these features, while 

queries can be applied to all objects [Aksit92b]. (this subject is not addressed by this 

thesis) 

• Dynamic inheritance and delegation; 

This problem can be solved by using dispatch filter and associative inheritance c.q. 

delegation. Because conditions representing the context or state of the receiver are 

evaluated dynamically, the inheritance and delegation structure changes appropriately 

[Aksit92b]. (refer to section 9.6.1, page 70 and section 9.6.2, page 70) 

Behavior injection Alternative implementations can be realized with behavior injection. Behavior 

injection is defined as replacing or extending the behavior of an object dynamically 

(i.e. at run-time) with new behavior. In the composition filters object model this can be 

accomplished by replacing an object which is the target in a dispatch filter, with 

another object. 

3. By using associative inheritance and associative delegation, the client may affect the inheritance hierarchy, 

c.q. delegation structure to some extent. 


7

8 

• Excessive class declarations (non-parameterized hierarchies); 

The dispatch filter and associative inheritance can be used to avoid excessive class 

declarations. A client can choose the right combination of superclasses from the given 

ones by setting the appropriate conditions at instance creation time [Aksit92b]. (refer to 

section 6.1.1, page 39, section 9.6.1, page 70) 

• Fixed message passing semantics; 

By using meta filters and abstract communication types, we can introduce arbitrary 

message passing semantics. Every abstract communication type object can implement 

specific message passing semantics, such as asynchronous and future message passing. 

Because these abstract communication type objects are instances of ordinary classes, 

message passing semantics can be reused and extended [Aksit93][Bergmans94a]. 

(refer to chapter 10) 

• Inheritance versus real-time; 

The real-time filter can change the timing constraints of a message. Since real-time 

filters separate real-time specifications from methods, the real-time specification 

anomalies are eliminated [Aksit94]. (this subject is not addressed by this thesis) 

• Inheritance versus synchronization; 

A wait filter in combination with conditions can be applied to specify synchronization 

constraints. By using wait filters, the synchronization inheritance anomalies are 

avoided [Bergmans94a]. (refer to section 9.6.4, page 70) 

• Multiple interfaces (views); 

Multiple interfaces can be specified by using a dispatch filter or error filter with 

conditions based on the context. These conditions are used to differentiate between 

(groups of) clients [Aksit92b]. (refer to section 9.6.1, page 70 and section 9.6.2, 

page 70) 

• Part-of versus inheritance; 

This problem can be avoided by using a dispatch filter and an internal as superclass. 

The composition filters object model does not make a distinction between part-of and 

inheritance relation: conceptually there is an inheritance relation when an internal 

object is the target object of a dispatch filter [Aksit88][Aksit92b]. (refer to 

section 6.1.1, page 39) 

• Lack of reflection; 

Reflection on messages and the communication between objects is supported by the 

meta filter and abstract communication types [Aksit93]. (refer to section 9.6.5, page 71 

and section 10.4, page 77) 

• Sharing behavior with state; 

This problem can be solved by applying a dispatch filter which delegates a message to 

an object external to the receiver. As this object is not encapsulated by the receiver, it 

can be shared by several other objects. Since this shared object is an instance of some 

class, it provides common behavior while it encapsulates the shared state 

[Aksit88][Aksit92b]. (refer to section 3.3, page 25 and section 9.6.1, page 70) 

• Unmatched system functionalities; 

Abstract communication type objects, together with meta filters can be used to 

implement extensible system functionalities [Aksit93]. (refer to section 9.6.5, page 71 

and section 10.4, page 77) 

1.3 The past, present, and future 

The composition filters object model evolved from earlier versions of the programming 

language <strong>Sina</strong>. The <strong>Sina</strong> language was named after the medieval philosopher, scientist and 

physician Ibn <strong>Sina</strong> who is also known under the Latin name of Avicenna. 


The first version of <strong>Sina</strong> was developed around 1985 by Mehmet Aksit when he was 

working at the Research department of Océ Nederland B.V. A preliminary version of the 

composition filters concept was called semantic network. This semantic network 

construction served as an extension to objects (classes, messages, instances) which could 

be configured to form other objects, such as classes from which instances could be created. 

An object manager took care of synchronization and message processing of an object. The 

semantic network construction already could express the key concepts of delegation, 

reflection, and synchronization. 

In 1987, when Mehmet Aksit moved to the University of Twente, the semantic network 

concept evolved to interface predicates which describe which messages an object is able 

to handle. In the second version of <strong>Sina</strong>, the functionality of the object manager was 

reduced, and the possibility to configure objects into classes was abolished. To abstract 

communications among objects, the notion of abstract communication type was 

introduced, while atomic delegations made it possible to describe transactions [Aksit89]. 

In this period, Anand Tripathi of the University of Minnesota contributed to the language 

design, while Hans Bank, Ruud Nijhuis, Jan-Willem Dijkstra, Willem Veldkamp, Gerard 

van Wageningen, and Nini Poortenga were involved as students. 

The TRESE project was established by Mehmet Aksit in the beginning of 1991. As result 

of ongoing research, the foundation for the present day composition filters object model 

was defined in the same period. The interface predicates of the prior version were replaced 

by the dispatch filter and the wait filter took over the synchronization functions of the 

object manager. Message reflection and real-time specifications are handled by the meta 

filter and the real-time filter, respectively. The composition filters object model turned to 

be the major focus of attention of the TRESE project while the language <strong>Sina</strong> became an 

expressive instrument for it. As a result, the third version of <strong>Sina</strong>, <strong>Sina</strong>⁄st version 3.00 , 

integrates the composition filters object model. 

Contributions to the composition filters object model and the <strong>Sina</strong> language were made by 

the project members Lodewijk Bergmans, Richard van de Stadt, Jan Bosch, Ken Wakita, 

<strong>Sina</strong>n Vural and Sander Pool, and the students Koen Lesterhuis, William van der Sterren, 

Piet Koopmans, Coen Stuurman, Maurice Glandrup, John Mordhorst, and Wietze van 

Dijk. 

The composition filters object model already has been applied in several projects. These 

include an atomic transactions framework [Tekinerdogan94], a process programming 

framework [Algra94], an image algebra framework [Vuijst94], and a fuzzy-logic 

reasoning framework [Marcelloni95]. 

Currently, the TRESE project is extending the conventional object-oriented languages 

Smalltalk [Goldberg83][Goldberg89] and C++ [Ellis90] with composition filters. This is 

possible because the composition filters object model is a modular extension to the basic 

object-oriented model. Further, some practical improvements to the syntax and semantics 

of composition filters have been introduced, while research continues on new filter types, 

such as the active filter, the multiple-dispatch filter, the atomic filter, and the substitution 

filter. 

1.4 Problem statement and approach of this thesis 

As described in the former sections, <strong>Sina</strong>⁄st is a concurrent object-oriented programming 

language which incorporates the composition filters object model. This model has a 

number of unique features which require a different approach to implement it. 

The major difference with conventional object oriented languages is that the composition 

filters of an object decide how the object handles a received or sent message. In 

conventional object oriented languages such as Smalltalk [Goldberg83][Goldberg89] and 

C++ [Ellis90] the method lookup process to search for a method corresponding to the 

received message. 


9

10 

A message that is sent or received by an object is offered to the filters to be filtered. In 

order to decide what the filter has to do with the message, it must be able to reflect on the 

message (system level reflection). Because conditions, which represent the state of an 

object, can influence this decision, the filtering process has a dynamic nature. Message 

reification and dereification allow an ACT object to reflect on a message (application level 

reflection). Concurrency and synchronization are also important features of the <strong>Sina</strong>⁄st 

language. 

Problem statement The aim of this thesis is to define the syntax and the semantics of the <strong>Sina</strong>⁄st language, and 

to investigate how <strong>Sina</strong>⁄st can be implemented. The third goal is to evaluate the <strong>Sina</strong>⁄st 

language with respect to the syntax and semantics of composition filters. 

One of our concerns is to focus on the interesting aspects of the composition filters object 

model, such as filters, message reification and dereification, concurrency and 

synchronization. We want to develop an implementation that demonstrates the benefits of 

the composition filters object model above the conventional object-oriented model. We 

therefore do not consider performance of the implementation of the uttermost importance. 

Although <strong>Sina</strong>⁄st is a typed language, this thesis does not address type-checking either. 

Approach First of all, the syntax and semantics of the <strong>Sina</strong>⁄st language is defined in an informal way. 

Several examples will be used to demonstrate them. The <strong>Sina</strong>⁄st definition extensively 

describes the filtering process, and the message passing semantics including message 

reification and dereification. We introduce an new message dereification method which 

allows an ACT to regain control over a reified message as soon as this message receives a 

reply object. 

Secondly, we describe an implementation model for the <strong>Sina</strong>⁄st language. This model is 

composed of the execution model and the translation model. The execution model defines 

the run-time aspects and addresses the representation of messages, the filtering process, 

concurrency and synchronization. The translation model defines how <strong>Sina</strong>⁄st can be 

mapped to the target language, which is Smalltalk in this case. The implementation model 

will be used to implement <strong>Sina</strong>⁄st . 

The implementation provides a programming environment, which includes a user interface 

that allows the user to edit, compile and execute a <strong>Sina</strong>⁄st application, a compiler that 

translates <strong>Sina</strong>⁄st source code to Smalltalk, and a kernel for run-time support. The objectoriented 

language Smalltalk [Goldberg83], and the Objectworks\Smalltalk development 

environment [ParcPlace92a] are used to implement <strong>Sina</strong>⁄st . 

Finally, the <strong>Sina</strong>⁄st language and its implementation are evaluated, and suggestions are 

made for enhancements. 

1.5 Outline of this thesis 

This thesis has been divided into five parts. The first part contains this introduction which 

you are reading at this very moment. 

In part II, ‘Definition of the <strong>Sina</strong>⁄st language’, we define the <strong>Sina</strong>⁄st language. This part is 

also included in [Koopmans95]. The first chapter in this part, chapter 2, describes the 

composition filters object model in full detail, gives an overview of the <strong>Sina</strong>⁄st language, 

and outlines the rest of this part. 

The implementation of <strong>Sina</strong>⁄st is described in part III, ‘Implementation of the <strong>Sina</strong>⁄st 

language’. Chapter 11 discusses the implementation problems and gives an outline of the 

approach. The following chapter defines the execution model which addresses the 

representation of messages, the filtering process, message reification and dereification, and 

concurrency and synchronization. Chapter 13 defines the translation model which shows 

how <strong>Sina</strong>⁄st entities are mapped to Smalltalk. Finally, chapter 14 describes the <strong>Sina</strong>⁄st 

programming environment. 


In part IV, ‘Evaluation and Conclusions’, we evaluate the language and the 

implementation, summarize the work presented in this thesis, and give directions for future 

work. 

The final part of this thesis, part V, contains relevant information, including the <strong>Sina</strong>⁄st 

syntax. 


11

12 


PART 


ii Definition of the <strong>Sina</strong>⁄st language 


2 Language survey 

In this chapter, we explain the composition filters object model in short and give an 

overview of the language elements of <strong>Sina</strong>/st. The last section shows how to read the rest 

of this part of the thesis. 

2.1 The composition filters object model 

The composition filters object model is class based: for an application consisting of a 

number of objects, all objects with common characteristics are instances of the same class. 

Objects are only specified on class level; this supports the creation of multiple instances 

and reuse through the inheritance mechanism ([Bergmans94a][Bergmans94b]). 

FIGURE 2-1 An object composed of an interface layer and an inner object 

implementation part 

interface part 

As can be seen in figure 2-1, an object in the composition filters object model is composed 

of an inner object and an interface layer. The inner object implements the object’s specific 

behavior. The interface layer encloses the inner object and manages incoming and 

outgoing messages. 

In <strong>Sina</strong>/st the interface layer is defined by the interface part (section 2.2.2), and the inner 

object by the implementation part (section 2.2.1). The coming section describes the inner 

object, while section 2.1.2 covers the complete composition filters object. 

The Definition of the <strong>Sina</strong>/st Language 

received messages 

sent messages 

interface layer 

inner object 

15

16 

2.1.1 The inner object 

The inner object implements an object’s specific behavior and holds its state. As pictured 

in figure 2-2, the inner object contains three main components: methods, conditions and 

instance variables. The names of the methods and the conditions are visible on the 

encapsulating boundary of the inner object, whereas the instance variables are fully 

encapsulated by it. The inner object is embodied in <strong>Sina</strong>/st by the implementation part and 

is explained in section 2.2.2. 

FIGURE 2-2 The inner object with instance variables, methods and conditions 

conditions 

instance 

variables 

Instance variables An instance variable holds the state of an object. An instance variable is an instance of a 

specific class which is created when the inner object is created. 

Methods The behavior of an object is implemented by its methods. A method defines a number of 

actions that are performed in reaction to the invocation of the method. 

Conditions A condition provides information about the current state of the object. It is a special kind 

of method that takes no parameters and returns a boolean result. 

2.1.2 The composition filters object 

Figure 2-3 shows the inner object being surrounded by an interface layer. The following 

components can be distinguished in the interface layer: internals, externals, input filters 

and output filters. The interface layer is embodied in <strong>Sina</strong>/st by the interface part and is 

explained in section 2.2.1. 

Internals Internals are fully encapsulated objects and are used to compose the behavior of the 

composition filters object: a received message could be delegated to an internal object 

instead of the inner object, for instance. 

Externals External objects are objects that exist outside the composition filters object, such as global 

objects. They can be used to share data among objects. An example of this is a department 

secretary which is an external for all the managers of this department. When a manager is 

asked to make an appointment, he delegates this request to the secretary which maintains 

his agenda. Similarly to internals, they are also used to compose the behavior of the 

composition filters object. 

In figure 2-3 the interior structure of the internal and external objects and instance 

variables is not shown, but they are composition filters objects as well, having an inner 

object and an interface layer. 

Input filters The input filters handle messages that are received by the object. One type of filter that can 

be part of the input filters is the so called dispatch filter which can either invoke a method 

of the inner object, or offer the message to the input filters of an internal or external object. 

Output filters The output filters handle messages that are sent by the object. A so called send filter 

delivers the message at the input filters of the receiver of the message. 

Chapter 2: Language survey 

methods

Sending a message When an object (the sender) sends a message to another object (the receiver), the message, 

in general, is filtered by the output filters of the sender, and then by the input filters of the 

receiver. Every filter decides what to do with the message. Eventually, there is some filter 

(a dispatch filter) that invokes a designated method. Hence, filtering a message can be 

thought of as the method lookup. 

FIGURE 2-3 The composition filters object 

interface layer 

internals 

inner object 

Filtering a message When a filter filters a message, the filter either accepts or rejects the message. When a 

dispatch filter accepts a message, it invokes a method or offers the message to the input 

filters of an internal or external. A rejected message continues in the following filter. 

Similarly, a send filter delivers the message to the input filters of the receiver when it 

accepts a message, and offers it to the next filter when it rejects a message. 

Filtertypes Filtertypes that can appear in the input filters or output filters group include the 

aforementioned dispatch filter and send filter, and further the wait filter, the error filter and 

the meta filter. The wait filter can be used for inter and intra object synchronization: when 

it rejects a message, the execution of the message is suspended. The execution resumes 

when a certain condition is met, causing the message to be filtered by the following filter. 

The error filter raises an error when it rejects a message. The meta filter is able to reflect on 

message communication between objects. When a message is accepted by this filter, it is 

offered to another object. This object is thus able to reflect on the message, i.e. the 

communication between two objects. 

In the class interface part, the input filters and output filters can be declared containing an 

arbitrary set of those filters. In this way, an object’s behavior can be composed by selecting 

the appropriate combination of filters. 

2.2 A composition filters object in <strong>Sina</strong>/st 

As mentioned in the previous section, the interface layer of a composition filters object is 

realized in <strong>Sina</strong>/st by the interface part of a class definition, and the inner object is realized 

by the implementation part of a class definition. This section describes the structure of 

these parts by using class Stack as an illustrative example. Class Stack provides operations 

like push, pop, top and size. An error is raised when an element is popped from an empty 

Stack, or when the top element is requested of an empty Stack. 

In <strong>Sina</strong>/st an application can be started by using the main method. This is demonstrated in 

section 2.2.3. 


received messages 

sent messages 

input filters 

externals 

output filters 

17

18 

2.2.1 The interface part 

Example 2-1A shows the definition of the interface part in <strong>Sina</strong>/st. The name of the class, 

Stack, is placed between the keywords class and interface. We can recognize the 

components from figure 2-3: they are marked by the respective keywords. 

The ordering of the keyword sections are as indicated. When the class has no components 

defined for a section, the keyword can be omitted. The minimum interface of a class is thus 

comprised of the keyword class, its name and the keywords interface and end. 

Comment The section starting with the keyword comment defines the comment of the class 

interface. This kind of comment can only appear at this specific location. A comment 

starting with // can appear everywhere and extends to the end of the line. 

Externals Externals, and also internals, are declared as a named instance of some class. Since the 

external objects lay outside the object, it is checked whether they exist and where they are 

located when the object is created. Class Stack has no externals declared. 

Internals When an instance of the class is created, its internals are created. Since every internal is 

declared as an instance of some class, their internals, if there are any, are created, and so 

on. 

The internal default of class Stack is declared as an instance of the class <strong>Sina</strong>Object. This 

class provides default operations, such as printing, testing and comparison. 

EXAMPLE 2-1A class Stack interface 

comment 

’This class represents a stack containing elements of arbitrary type.’; 

externals 

// This class has no externals, but they could be declared as 

// anExt : ClassName; 

internals 

default : <strong>Sina</strong>Object; 

conditions 

stackNotEmpty; 

methods 

push(object : Any) returns nil; // Stores the argument object. 

pop returns nil; // Removes the top element 

top returns Any; // Answers the top element 

size returns SmallInteger; // Answers the number of elements 

inputfilters 

stackEmpty : Error = { stackNotEmpty => {pop, top}, true ~> {pop, top} }; 

invoke : Dispatch = { true=>inner.*, true=>default.* }; 

outputfilters 

send : Send = { true=>* }; 

end; // Stack interface 

Conditions In the conditions section, the names of the conditions are specified. Conditions can be 

used in a filter to test whether to accept or to reject a message. The class Stack has only 

one condition, stackNotEmpty, which reflects whether the stack is empty or not. 

Methods The methods section defines methods which are available to other objects. The 

parameters and the type of the value returned by these interface methods are specified. 

Apart from interface methods, a class can have private methods which can only be 

accessed by the class itself. Private methods are declared in the implementation part. 

Input filters In the inputfilters section, an arbitrary number of filters are declared. A filter declaration 

defines the name of the filter, the filtertype and the filterinitializer. 

The filter initializer, the part between the curly braces {}, specifies which messages under 

which conditions are accepted by the filter. The filter initializer is comprised of a number 

Chapter 2: Language survey

of filter elements, each of which specifies a condition and a set of messages to be accepted. 

The filter elements are evaluated from left to right: if the message is not accepted by one 

filter element, for instance when the condition is invalid, then the message could still be 

accepted by a following filter element. 

For example, the initializer of Stack’s first input filter, the error filter named stackEmpty, 

specifies that the filter accepts messages with the selector pop or top when the stack is not 

empty. This is expressed by the first filter element stackNotEmpty=>{pop,top}. It could be 

read as “if stackNotEmpty then accept a message with (pop or top)”. 

The second filter element true~>{pop,top} could be interpreted as “if true then accept a 

message not with (pop or top)”, which is the same as “accept a message without pop and 

without top”. This filter element specifies that the filter further accepts messages with any 

selector except pop and top. As a result, the error filter rejects messages with selector pop 

or top when the stack is empty, causing it to generate an error, and accept messages 

otherwise. 

Messages that have passed the error filter, are filtered by the following filter, the dispatch 

filter invoke. This filter accepts messages that are supported by the inner object (the filter 

element true=>inner.*) or that are supported by the internal default (true=>default.*). By 

definition, the messages supported by the inner object are the interface methods, which are 

push, pop, top and size in this case. When the dispatch filter accepts a message, it invokes 

the corresponding method of inner, or offers the message to the object default. This object 

filters the message and eventually invokes a method. Suppose that the default object also 

supports a method size, then, by the evaluation of filter elements from left to right, still the 

size method of inner is invoked. 

From this we can conclude that an instance of class Stack supports the messages push, 

pop, top, size and all the messages which are defined by class <strong>Sina</strong>Object. The message 

pop or top sent to an empty stack generates an error. 

Output filters Like the former section, an arbitrary number of filters can be declared in the outputfilters 

section. The send filter send sends all messages (the filterelement true=>*) sent by a Stack 

instance to the receiver of the message. 

2.2.2 The implementation part 

The implementation part of a class in <strong>Sina</strong>/st is shown in example 2-1B. The name of the 

class is repeated between the keywords class and implementation. The implementation 

part has sections which respectively define a comment, the instance variables, the 

implementation of the conditions, an initial method and the implementations of private and 

interface methods. Again, when the class has no components defined for one of these 

sections, the corresponding keyword can be omitted. 

Comment A comment section in the implementation part can appear just after implementation and 

further in conditions and methods. 

Instance variables The instance variables of the class are defined in the instvars section. Like internals and 

externals, they are declared as a named instance of some class. The instance variables of 

an object are created after the internals have been created. The instance variable storage 

contains the elements of the stack, while the SmallInteger stackPtr points to the last used 

location in this Array. 

Conditions The implementation of the conditions are defined in the conditions section. A condition 

must return a boolean result. In the condition stackNotEmpty, the state of the stack is 

determined with the expression stackPtr > 0. 


19

20 

Initial method The initial method can be used to initialize the instance. It is invoked at instance creation 

time, after the internals and instance variables have been created. The class Stack uses it to 

initialize the stackPtr. 

Methods In the methods section, the implementation of the interface methods are defined. 

Implementations of private methods can also be found here. 

EXAMPLE 2-1B class Stack implementation 

comment 

’The instance variable ”stackPtr” points to the last used location of the 

stack. The instance variable ”storage” holds the elements of the stack’; 

instvars 

stackPtr : SmallInteger; 

storage : Array; 

conditions 

stackNotEmpty 

comment ’This state is true when the stack contains elements’; 

begin return stackPtr > 0; end; 

initial 

comment ’Start with an empty stack’; 

begin stackPtr := 0; end; 

methods 

push(object : Any) 

comment ’Pushes the argument object onto the stack’; 

begin 

stackPtr := stackPtr + 1; 

storage.at:put:(stackPtr, object) 

end; 

top 

comment ’Answers the top element of the stack’; 

temps object : Any; 

begin 

object := storage.at:(stackPtr); 

return object 

end; 

pop 

comment ’Removes the top element from the stack’; 

begin 

stackPtr := stackPtr - 1; 

end; 

size 

comment ’Answers the number of elements on the stack’; 

begin return stackPtr 

end; 

end; // Stack implementation 

Local variables Local variables of a method, and also condition, are defined after the keyword temps. The 

method top, for instance, uses a local variable named object to retrieve the top element of 

the stack. 

Statements The body of a method, surrounded by begin and end, can contain any number of 

statements and expressions. An assignment statement stores a value —an object— in a 

variable. <strong>Sina</strong>/st further defines statements like if-then-else, a while-loop and a for-loop. 

A value can be returned from a method, but also from a condition, by using the return 

statement. The condition stackNotEmpty and the methods top and size demonstrate this. 

Expressions There are two types of expressions in <strong>Sina</strong>/st: an operator expression, like stackPtr + 1, and 

a message expression, like storage.at:(stackPtr) in which the message at: with argument 

stackPtr is sent to the object storage. In fact, an operator expression is a shorthand notation 

for a message expression. The compiler converts every operator expression to an 

equivalent message expression: stackPtr + 1 is replaced by stackPtr.plus(1). 


2.2.3 The main method 

The main method can be used start an application. In general, the main method is very 

small, but you can use it to test newly defined classes. Example 2-2 shows this in which the 

class Stack from example 2-1 is applied and tested. 

EXAMPLE 2-2 main 

comment ’Application of class Stack’; 

externals 

Transcript : TextCollector; 

temps 

stack : Stack; 

begin 

stack.push(’1st element’); 

stack.push(2.0d0); 

stack.push(’3rd element’); 

while stack.size > 0 

begin 

Transcript.print:(stack.top); 

Transcript.cr; 

stack.pop 

end; 

Transcript.flush 

end 

The main method has the same structure as a method implementation. The only difference 

is that global objects that are referred to by main must be declared in the externals section. 

The external Transcript in example 2-2 is a global Smalltalk object which can be used to 

display messages on. The variable stack is local to main and has been declared in the 

temps section. The body shows that the stack is filled with three elements. Then, they are 

displayed on the Transcript and removed from the stack in the while-loop. 

2.3 Forthcoming chapters 

The rest of this part of the thesis discusses the <strong>Sina</strong>/st language in more detail. 

2.3.1 Syntax 

Appendix C contains the complete syntax of the <strong>Sina</strong>/st language. In following chapters, 

we will present parts of the the syntax when we explain certain elements of the language. 

The production for the conditional statement, for example, is denoted as 

conditionalStatement ::= 

if expression 

then statements 

( else statements )? 

end 

A production consists of a nonterminal, called the left side of the production, a ::= 

symbol, and a sequence of terminals, nonterminals and metasymbols, called the right side 

of the production. Terminals are symbols which are shown in boldface font, like the 

semicolon ; and the keywords if, then, else and end. For every nonterminal, shown in 

normal font, there is a production defined. Tokens on the right side of the production can 

be grouped by the metasymbols ( and ). A token or a token group followed by the 

metasymbol ? defines that the token, c.q. group is optional. The metasymbol * defines a 

sequence of zero or more occurrences of the token or group. Finally, the metasymbol | 

between token sequences specifies a choice between them. 


21

22 

2.3.2 Terminology 

In the following chapters, we often refer to the term first-class object and the terms owner, 

owning object or owning class. They are defined here. 

First-class object According to [Wegner87], first-class objects can “be assigned to variables, be passed as 

parameters and be components of structures”. To put it in another way: a first-class object 

can be stored somewhere, while a non first-class object is only available during execution 

and cannot be stored. An active message, an objectmanager and a filter are examples of 

non first-class objects. Some non first-class objects can be accessed, like first-class objects, 

by sending a message to it. These kinds of objects include an active message and the object 

manager, because they are represented by the pseudo variables message, ^self and ^server. 

A filter on the other hand, cannot be accessed by sending a message to it. 

Owner The owning class or owning object of an entity (for instance, a filter or an internal) is the 

class, cq. the particular instance of the class, in which the entity was defined. By the term 

owner we mean the owning class or owning object, depending on the context. We can 

speak of the owner of an internal, a filter, a method, etc. For instance, the owner of the 

error filter stackEmpty in example 2-1A is the class Stack. In example 2-2, its owning 

object would be the object stack. 

2.3.3 Structure of a <strong>Sina</strong>/st program 

A <strong>Sina</strong>/st program consists of a single main method, or one or more class declarations, 

optionally followed by a main method. The syntax is thus: 

program ::= 

main | classDeclaration ( classDeclaration )* main? 

2.3.4 Where to find what 

Each of the following chapters addresses a specific topic of <strong>Sina</strong>/st. The overview below 

shows the subjects covered by each chapter. 

Chapter 3 – Basic language elements 

literals: characters, strings, numbers, nil, true, false; variables: local 

variables, method parameters, instance variables, internals, externals, 

class parameters, global externals; pseudo variables: inner, self, server, 

sender, message, ^self, ^server; 

Chapter 4 – Expressions 

message expression; operator expression; 

Chapter 5 – Control structures 

conditional statement; for statement; while statement; 

Chapter 6 – Classes 

interface part; implementation part; instance creation; object manager: 

class ObjectManager; default behavior: class <strong>Sina</strong>Object; 

Chapter 7 – Methods 

interface method; private method; initial method; main method; 

returning a value; normal vs. early return; statements; 

Chapter 8 – Conditions 

reused condition; local condition; 

Chapter 9 – Filters 

input filters; output filters; reused filter; local filter; filtering a message; 

signature of an object; filtertypes: dispatch filter; error filter, send filter, 

wait filter, meta filter; 

Chapter 10 – Message passing semantics 

sending a message; creating concurrency; thread; message reification; 

message dereification; active message: pseudovariable message, class 

ActiveMessage; reified message: class <strong>Sina</strong>Message; 


3 Basic language 

elements 

This chapter describes the basic language elements in <strong>Sina</strong>/st. The first section discusses 

the comment. Section 3.2 defines the literal constants, such as characters, strings, numbers, 

and the special literals nil, true and false. The following section describes variables and 

their declaration, while section 3.4 discusses the global externals. The last section defines 

the various pseudo variables. 

3.1 Comment 

Two forms of comment are allowed in a <strong>Sina</strong>/st: a one-line comment and a comment that 

begins with the keyword comment. 

The one-line comment starts with two slash-characters (//) and extends to the rest of the 

line. It can contain any character except the newline character, of course. 

The second form of comment consists of the keyword comment followed by a string 

literal and a closing semicolon character. The string literal, as we will see in section 3.2.2, 

can contain any character including a newline character, and therefore this type of 

comment can extend over several lines. This type of comment can only appear at fixed 

locations: 

• the interface part of a class (refer to section 6.1.1); 

• the implementation part of a class (section 6.1.2); 

• the method implementation (sections 7.1-7.3); 

• the main method implementation (section 7.4). 

• the condition implementation (section 8.2); 

The example below shows the use of both an interface comment and a one-line comment 

class Stack interface 

comment ’You should describe here the function 

and behavior of class Stack’; 

... 



23

24 

3.2 Literal constants 

<strong>Sina</strong>/st provides three types of literal constants: 

• characters; 

• strings; 

• numbers. 

In addition, three special constants are defined: nil, true and false. 

3.2.1 Characters 

A character literal is made up of an initial $-character followed by one character which can 

be any character including a newline, a tab or a space character. The following literals are 

all examples of character literals: 

$z 

$$ 

$P 

$3 

$ 

$. 

Every character literal is an instance of class Character. 

3.2.2 Strings 

A string literal is enclosed in single quote characters (’) and can contain any number of 

characters which can be any character including a newline, a tab or a space character. To 

include the single quote character itself, it must be preceded with a single quote character. 

The following four string literals illustrate this. 

’To be or not to be?’ // a string with several characters 

’A tab and a newline 

character can be included’ // a string containing a tab and a newline. 

’’ // an empty string 

’’’’ // a string containing only one quote character 

Every string literal is an instance of class String. 

3.2.3 Numbers 

There are two types of number literals: integer literals which do not have a decimal point 

embedded in them, and floating point literals which do. A negative number is represented, 

as usual, with a preceding minus sign. There must be no space between the minus sign and 

the literal, since the minus sign would otherwise be interpreted as the negation operator 

(see Section 4.3 on page 33). 

1496.0 // positive floating point number 1496 

-1496 // negative integer number -1496 

- 1496 // negated positive integer number 1496 

- -1496 // negated negative integer number -1496 

Number literals can also be expressed in scientific notation by including an exponential 

part. The exponential part is composed of a preceding “e” or “d” and the exponent in 

decimal. The exponential part starting with an “e” can be used both with an integer and a 

floating point literal, whereas the exponential part starting with an “d” can be used only 

with a floating point literal. A floating point literal having an exponential part that starts 

with a “d” represents a double-precision number. A floating point literal without an 

exponential part or with one that starts with an “e” represents a single-precision number. 

Chapter 3: Basic language elements

Variables are references 

to objects 

13e2 // integer number 1300 

-13.0e2 // single-precision floating point number -1300 

-13.0d2 // double-precision floating point number -1300 

Integer literals are instances of class SmallInteger. Every floating point literal having an 

exponential part which starts with a “d” is an instance of class Double. A floating point 

literal without an exponential part or with one that starts with an “e” is an instance of class 

Float. 

-1496 // a SmallInteger 

1496.0 // a Float 

13e2 // a SmallInteger 

-13.0e2 // a Float 

-13.0d2 // a Double 

0.0 // the Float 0.0 

0.0e0 // another representation for the Float 0.0 

0.0d0 // the Double 0.0 

3.2.4 The constants nil, true and false 

The object nil denotes an undefined object. The nil object is the sole instance of class 

UndefinedObject. 

The boolean constants true and false are the sole instances of classes True and False, 

respectively, which are both subclasses of class Boolean. 

3.3 Variables 

<strong>Sina</strong>/st provides six types of variables: 

• local variables of a method, a condition or main. They are declared in the temps 

section of the method, condition or main respectively; 

• parameters of a method. They are declared in the header of the method; 

• instance variables of an object. They are declared in the instvars section of the 

implementation part of a class; 

• internal objects. They are declared in the internals section of the interface of a class. A 

class can uses an internal to compose its behavior from; 

• external objects. They are declared in the externals section of the interface of a class. 

Externals can be used to compose the behavior from and to share data among objects. 

In <strong>Sina</strong>/st version 3.00, externals can only be global externals (see section 3.4) stored 

in the <strong>Sina</strong>Repository. Future versions will implement full scope rules which allow 

externals also to be internal variables, instance variables, or local variables of an 

encapsulating object; 

• parameters of a class which are used to initialize an instance of a class. A class 

parameter behaves like an instance variable of a class. Class parameters are declared in 

the interface part of a class. 

Variables must have been declared before they can be used (sections 3.3.1 and 3.3.2). 

Once a variable has been declared, it has an initial value –an object– which is assigned 

automatically or comes from the environment (3.3.3). The value of a variable can be 

changed by assigning a new object to it (3.3.4). The nil object can be assigned to a variable 

to indicate that its value is undefined. 

In <strong>Sina</strong>/st, every variable is a reference to an object. As a consequence, method and class 

parameters are passed by reference too. When an object is not referred to by other objects, 

its memory is reclaimed automatically. 


25

26 

The consequence of variables being object references is that when one variable is assigned 

to another variable, they both refer to the same object. 

main 

externals Transcript : TextCollector; 

temps john, mary : Person; 

begin 

john.setName(’John’); 

mary.setName(’Mary’); 

john := mary; 

john.setName(’Johnny’); 

Transcript.print:(mary.name); 


end; 

In the example above, the variables john and mary initially refer to two different Person 

objects, one named ’John’ and another named ’Mary’, respectively. Once mary has been 

assigned to john, they both refer to the same object, the Person object with the name 

’Mary’. If we change john’s name to ’Johnny’, mary’s name will be changed at the same 

time. As a result, ’Johnny’ is printed, when mary’s name is requested. 

3.3.1 Declaration 

A variable declaration defines the name and the type of each variable. Variables with the 

same type can be declared in the same declaration by separating their names by commas. 

variableDeclaration ::= 

variableName ( , variableName )* : typeDescription 

The name of a variable is an identifier that consists of a sequence of uppercase or 

lowercase letters (A-Z, a-z) and digits (0-9) which must start with a letter. The name(s) and 

the type are separated by a colon character. In the current version (<strong>Sina</strong>/st version 3.00), 

the colon must be preceded by a space, a tab or a newline character, otherwise the compiler 

issues a syntax error. 

temps 

i, counter : SmallInteger; 

arr : Array(10); 

In the temps section above, i and counter are both declared as variables of type 

SmallInteger. The variable arr is declared of type Array(10), that is, an array with 10 

elements of unspecified type. In these declarations, SmallInteger and Array(10) are so 

called typedescriptions. 

3.3.2 Typedescription 

A typedescription describes the type of the variable. It refers to a class and can have 

arguments. For some variables, it is also used to create their initial value (see below). 

There are four forms of typedescriptions: 

typeDescription ::= 

Any 

| className ( ( expression ( , expression )* ) )? 

| className selector ( ( expression ( , expression )* ) )? 

| variableName 

The type Any The type Any can be used for variables whose type do not matter. An object of arbitrary 

type can be assigned to such a variable. The initial value of variables of type Any and 

which are automatically created (see below) is nil. 


Ordinary 

typedescription 

Typedescription 

with constructor 

Dynamic 

typedescription 

The ordinary typedescription consists of the name of a class, optionally with argument 

expressions which are used to initialize the instance. Instances of <strong>Sina</strong> classes are 

constructed using this form, but it can also be used for the declaration of a Smalltalk 

instance. In the following example, the instance variable bb is declared as an instance of 

the <strong>Sina</strong> class TypedBuffer. It expects two arguments, the size of the buffer and the type of 

its elements. 


bb : TypedBuffer(2 * n, SmallInteger); 

TypedBuffer(2 * n, SmallInteger) is the typedescription of the variable bb. It has two 

argument expressions, 2*n and SmallInteger. Note that the argument SmallInteger is an 

object here, and not a typedescription. Therefore, it should have been declared as an 

external of type Class, otherwise the compiler flags it as an ‘Object not declared’-error. 

The third form of typedescription consists of the name of a Smalltalk class followed by a 

constructor and, optionally, argument expressions. The constructor is a Smalltalk selector 

and is sent to the class to construct an instance of that class. Note that this form is only 

allowed for Smalltalk classes, and that this class must have a class method 1 with the 

mentioned selector. It is responsibility of the programmer to assure that this class method 

does return a new instance of the class. Table B-2, page 151, describes the relationship 

between this form and Smalltalk. We show example declarations using this 

typedescription. 

temps 

today : Date today; 

center : Point x:y:(260,435); 

circle : Circle center:radius:(center, 50); 

pi : Double pi; 

The variable today is initialized with today’s date, center is a Point instance with initial x 

and y coordinates, and the variable circle is a Circle instance with a radius of 50 and the 

former center variable as center. Note that we can use previously defined variables in the 

typedescription argument expressions. The last declaration shows that the variable pi is 

initialized with the Double value of the constant π. 

The final form is the dynamic typedescription. It consists of the name of a variable, called 

the typevariable, which must have been declared as a variable of the type Class. This form 

can be used to declare variables of dynamic type. Such a dynamically typed variable is 

initialized with an instance of the class referred to by the typevariable. Because the 

parameters of a class cannot be specified in this form, only classes which have no 

parameters can be used safely as value of the typevariable. Classes which require 

parameters, such as the earlier mentioned TypedBuffer class, can be used, but their 

parameters are initialized with nil. Whether this will lead to (run-time) errors, depends on 

the robustness of that class. 

newInstanceOfType(t : Class) returns t; 

temps instance : t; 

begin 

return instance 

end; 

exampleMethod 

temps obj1, obj2, obj3 : Any; 

begin 

obj1 := inner.newInstanceOfType(SmallInteger); 

obj2 := inner.newInstanceOfType(Array); 

1. We are talking about Smalltalk classes here. A class method of a Smalltalk class will be executed by the 

class, whereas an instance method will be executed by an instance of that class. Some class methods will 

return a new instance of the class, while other are used for different purposes. 


27

28 

obj3 := inner.newInstanceOfType(TypedBuffer); 

end; 

The parameter t of the method newInstanceOfType above, is the typevariable for the local 

variable instance. This method returns an instance of type t that is passed as a parameter to 

the method. In the exampleMethod, obj1 will be a SmallInteger, obj2 will be an (empty) 

Array, and obj3 will be a TypedBuffer instance with nil as size and elementtype. 

3.3.3 Initial value 

A variable has an initial value, that is, the variable initially refers to some object. 

Parameter variables are initialized with the actual argument objects. Except for externals, 

to the other types of variables a new instance is assigned. The new instance is constructed 

according to variable’s typedescription. An external variable refers to an existing object — 

outside its owner— and is therefore not created. When their owner is created, it is verified 

whether the externals exist. 

Table 3-1 shows for each type of variable whether an instance for it is created 

automatically and when this is done. For Smalltalk classes, an instance is constructed 

according to appendix B.1 (page 151). 

TABLE 3-1 Initial value of variables 

Kind of variable 

Instance 

constructed 

automatically When 

temps yes at method invocation time 

method 

parameters 

no passed as actual argument of a message 

instvars yes at the instance creation time of the owning object 

internals yes at the instance creation time of the owning object 

externals no their existence are verified when the owning 

object is created 

class parameters no passed as actual arguments of a variable 

declaration 

3.3.4 Assignment 

With the assignment statement, the value of a variable can be changed. It has the following 

syntax. 

assignmentStatement ::= 

variableName := expression ; 

All variables can be changed with an assignment, with one exception: it is not allowed to 

change the value of a method parameter 2 . By assigning a new object to an external or an 

internal, the behavior of the owner could be modified. This is in general considered 

dangerous, but it is allowed. The compiler therefore issues a warning when this happens. 

3.4 Global externals 

A global external is an object which is stored in the <strong>Sina</strong>Repository. This is a collection of 

global objects which can be used as an external of a class or main method. 

2. Due to the implementation in Smalltalk. Smalltalk does not allow method parameters to be changed either. 


Creating a new 

global external 

Smalltalk classes and objects are also contained in the <strong>Sina</strong>Repository. By declaring the 

Smalltalk object as an external with its class as type, the object can be accessed in a <strong>Sina</strong> 

class or in main. 

In the following example, the Smalltalk classes Time and Double are used to 

display the current time and the value of the constant π on the Smalltalk system Transcript. 

main 

externals 

Time, Double : Class; 

Transcript : TextCollector; 

begin 

Transcript.print:(Time.now); 


Transcript.print:(Double.pi); 


Transcript.flush 

end 

When in main a value is assigned to an external that did not exist before, it causes the 

creation of that external which is stored in the <strong>Sina</strong>Repository automatically. A value 

assigned to an existing external in main only changes the value of the global external. 

By declaring a local variable —temp— in main of the same type as the non existing 

external and assigning this object to the external, the external is created and stored in the 

<strong>Sina</strong>Repository. 

The following example shows the creation of the external Hello of class HelloWorld. 

main 

externals Hello : HelloWorld; // Hello does not exist yet 

temps newGlobal : HelloWorld ; 

begin 

Hello := newGlobal; // Hello will now be stored in <strong>Sina</strong>Repository 

end 

After executing it, you can select the repository option from the source code view 

menu to see that the <strong>Sina</strong>Repository now includes the object Hello. 

3.5 Pseudo variables 

There are seven pseudo variables whose values change according to the execution context, 

and cannot be changed with an assignment. They are: 

• sender; 

• server; 

• self; 

• inner; 

• message; 

• ^self; 

• ^server. 

These pseudo variables refer to objects involved in the execution of a single message. 

When a message is sent, it is filtered first. Eventually a method is invoke (see chapter 10 

for a more elaborate description of message execution). The aforementioned pseudo 

variables can be referred to inside a condition during the filtering of the message, and 

inside a method during its execution. 


29

30 

sender 

server 

The first three pseudo variables, self, server and sender, are first-class objects, while inner, 

message, ^self and ^server are not. The latter four pseudo variables can only be accessed 

by sending a message to them, but they cannot be assigned to a variable. 

The pseudo variable sender refers to the object which has sent the message. The pseudo 

variable server refers to the object to which the message was sent: it is the first object to 

receive the message. The input filters of this object can decide to delegate the message to 

another object (an internal or external) in which case the input filters of that object filter 

the message. Alternative the input filters may decide to delegate the message to inner. This 

results in the invocation of a method. 

self During the filtering of a message, the pseudo variable self refers to the object that currently 

is filtering it. Once the message has invoked a method, that is, during the method’s 

execution, self refers to the object which is executing the method. The pseudo variables 

self and server do not refer to the same object when the server has delegated the message 

to another object than itself. They do refer to the same object when the server (i.e. the first 

receiver) delegated the message to itself. 

inner The pseudo variable inner refers to the inner object (see section 2.1.1). Unlike self, inner 

refers to the object without the filters. When a message is sent to self, the message is 

filtered by the output filters and then by self’s input filters. A message sent to inner on the 

other hand, does not pass filters, but invokes a method of the object directly. 

message The pseudo variable message can also be referred to inside a condition and method. In the 

former case it refers to the message being filtered, while in the latter case, it refers to the 

message which lead to the invocation of the method. The pseudo variable message is an 

instance of class ActiveMessage. The attributes of a message (selector, arguments, sender, 

server and current receiver) can be retrieved by sending the appropriate message to 

message (see section 10.2). 

^self 

^server 

The final two pseudo variables, ^self and ^server, are object managers related to self and 

server, respectively. They are instances of class ObjectManager and can be referred to 

inside a condition or a method. An object manager controls the access to an object: it keeps 

track of how many messages have been received or sent and which methods are executing 

(see section 6.3). 


4 Expressions 

An expression represents some value: when an expression is evaluated it returns an object. 

This object could be used to send a message to, but it could also be assigned to a variable, 

or passed as parameter to a method. 

EXAMPLE 4-1 Tarzan.setName(’Tarzan’, ’King of the Jungle’); 

Jane.age < Tarzan.age 

Example 4-1 shows the use of two expressions. The first expression is a so called message 

expression: the message setName with two arguments is sent to the receiver object Tarzan. 

Note that the two arguments are expressions on their own. The second expression is a so 

called operator expression: the two message expressions Jane.age and Tarzan.age are 

combined with the less-than operator (

32 

• a literal constant: a number literal (e.g. 3.14), a character literal (e.g. $p) or a string 

literal (e.g. ’King of the Jungle’); 

• one of the special literals nil, true or false; 

• one of the pseudo variables self, server, or sender; 

• a variable: the name of a local variable, a method parameter, an instance variable, an 

internal, an external, or a class parameter. 

In example 4-1, the two string literal arguments of the message setName are operand 

objects. Likewise, the variables Jane and Tarzan serve as receivers in both expressions. 

Note that the pseudo variables inner and message, and the object managers ^self and 

^server do not represent first class objects. This means that they cannot be passed as an 

argument of a message or assigned to a variable on their own. They can be used as the 

receiver in a message expression, however. 

The syntax of the entities we have defined in this section is as follows. 

expression ::= 

operandObject | messageExpression | operatorExpression 

operandObject ::= 

variable | numberLiteral | characterLiteral | stringLiteral | nil | true 

| false | self | server | sender 

4.2 Message expression 

A message expression denotes a message that is sent to an object. It has three main 

components: a receiver, a method selector and zero or more arguments. In the message 

expression Tarzan.setName(’Tarzan’, ’King of the Jungle’), the receiver is Tarzan, the 

method selector is setName, and the two arguments are the string literals ’Tarzan’ and ’King 

of the Jungle’. 

Receiver The receiver of a message expression can be one of the following: 

• an operand object (section 4.1); 

• one of the pseudo variables inner or message; 

• an object manager: ^self or ^server; 

• an expression enclosed by parentheses; 

• a message expression. 

Method selector The method selector is separated from the receiver object by a message send dot. A 

method selector refers to the name of a method and consists of a sequence alphanumeric 

characters. Apart from the name of a method, a Smalltalk keyword selector is also allowed 

as method selector. 

The Smalltalk keyword selector can be used to send a message to an instance of a 

Smalltalk class. A Smalltalk keyword selector contains a non-empty sequence of 

alphanumeric words each ending with a colon. The method selector at:put: in the 

expression anArray.at:put:(i, 0) is an example of such a keyword selector. The <strong>Sina</strong>/st 

compiler will check, wherever it can, if the Smalltalk class has defined a method with such 

a selector. 

Note that the method of a Smalltalk class has one of the following three types of selectors: 

• a unary selector, which consists of alphanumeric characters only, for instance sin. A 

unary selector expects no arguments; 

Chapter 4: Expressions

• a binary selector, which consists of non-alphanumeric characters. A binary selector has 

only one argument. The selector == is an example; 

• a keyword selector, such as the at:put: selector. A keyword selector expects as 

many arguments as there are colons in the selector. 

In <strong>Sina</strong>/st, a Smalltalk method with a unary or keyword selector can be called by just using 

that selector as the method selector of a message. For a method with a binary selector you 

must use the method selector as defined in table table B-3 (appendix B, page 151). 

EXAMPLE 4-2 3.14.sin // Smalltalk unary selector 3.14 sin 

’Tar’.cat(’zan’) // Smalltalk binary selector ’Tar’ , ’zan’ 

anArray.at:put:(i, 0) // Smalltalk keyword selector anArray at: i put: 0 

The previous example shows how in <strong>Sina</strong>/st the Smalltalk selectors can be used. Note that 

in Smalltalk the arguments of a keyword selector are mingled with it. In <strong>Sina</strong>/st, however, 

the message arguments are joined together after the selector. 

Message arguments The arguments of a message expression are enclosed by parentheses and separated by 

commas. If a message expression has no arguments, the enclosing parentheses are omitted. 

An argument is an expression, again. 

Highest priority 

evaluated first. Equal 

priorities evaluated from 

left to right 

We conclude this section by giving the syntax of the message expression. 

messageExpression ::= 

receiver . selector ( ( expression ( ; expression )* ) )? 

receiver ::= 

variable | numberLiteral | characterLiteral | stringLiteral | nil | true 

| false | self | server | sender | inner | message | ^self 

| ^server | ( expression ) | messageExpression 

4.3 Operator expression 

An operator expression, such as 3+4*5, improves the readability of the source code and 

allows the programmer to write a short-hand notation instead of the more tedious, but 

equivalent message expression 3.plus(4.times(5)). <strong>Sina</strong>/st’s compiler will convert each 

operator expression simply to an equivalent message expression. It is important to note 

that only the selector of the equivalent message expression will be sent to the receiver 

object: in the example above, 3 receives the a message with selector plus and not +, and 4 

will receive times and not *. 

An operator expression is made up of an operator and one or more operands each of 

which is an expression again: an operand object, an operator expression, or a message 

expression. 

Table 4-1 lists the available operators, their priorities and their equivalent message 

expressions. For clarity, the table includes the parentheses () and the message send dot (.), 

although they are strictly spoken no operators. A message send will always evaluated 

before any operator is applied. Parentheses can be used to enforce an evaluation order. 

An operator with the highest priority will be evaluated before an operator with a lower 

priority. Operators with equal priority will be evaluated from left to right if and only if the 

operator is left-associative. A left-associative operator is indicated by a bullet • in the 

column "asso-ciates left" of table 4-1. A cross × in the same column indicates that the 

operator cannot be combined with operators having the same priority. For instance, 

Jane.age = Tarzan.age = 50 makes no sense and will be flagged by the compiler as a 

syntax error. By using parentheses, we could write (Jane.age = Tarzan.age) = false, 

though. 


33

34 

TABLE 4-1 Operators with their priority and equivalent message expression 

associates 

sample 

description operator priority left expression 

force order ( ) >7 × (a / b).floor 

message send . >7 • a.atput(b,c) 

The <strong>Sina</strong>/st compiler transforms an operator expression into a message expression as listed 

in the column labeled "equivalent message expression" of table 4-1. The priorities of the 

operators will be taken into account. 

EXAMPLE 4-3 Jane.age < Tarzan.age Jane.age.less(Tarzan.age) 

(b*b - 4*a*c).sqrt ( (b.times(b)).minus( 4.times(a).times(c) ) ).sqrt 

-x+ y.cos + x*y/4 (x.negated).add(y.cos).add(x.times(y).divide(4)) 

a>=0 and a= × a >= b a.atleast(b) 

value equality = 3 × a = b a.equal(b) 

value inequality != × a != b a.unequal(b) 

identity equality == × a == b a.same(b) 

identity inequality =!= × a =!= b a.different(b) 

logical disjunction and 2 • a and b a.and(b) 

logical conjunction or 1 • a or b a.or(b)

Use the method selector quo: for integer division with truncation toward zero. Thus, - 

9.quo:(4) = -2 and -0.9.quo:(0.4) = -2. The method rem: gives the corresponding 

remainder: 9.rem:(4) = 1, -9.rem:(4) = -1. 0.9.rem:(0.4) = 0.1. 

• The operators = and !=, and the corresponding method selectors equal and unequal, are 

used to test whether the values of two objects are equal. The operators == and =!=, and 

the respective method selectors same and different, test the whether the two operands 

(the receiver and the argument object) are the same object. Thus, 4 = 4.0 yields true, 

whereas 4 == 4.0 yields false, since the SmallInteger object 4 and the Float object 4.0 

represent the same values, but are two different objects. 

• Case differences are ignored when two strings are compared by the operators =, !=, =, and the respective method selectors equal, unequal, less, upto, greater or 

atleast. This is due to implementation of the comparison methods of the Smalltalk class 

String. 

Thus, ’A’ < ’a’ and ’A’ > ’a’ both evaluate to false, even though the ASCII value of the 

character $A is less than the ASCII value of $a. The expression ’A’ = ’a’ would evaluate 

to true, and therefore ’A’ != ’a’ yields false. The comparison methods do, however, 

consider the length of the strings: ’a’ < ’ab’ and ’a’ > ’ab’ yield true and false, 

respectively. 

To compare strings considering case differences, you should use the method 

trueCompare: which returns -1, 0 or 1 if the receiver is less than, equal to, or greater 

than the argument. Thus, ’A’.trueCompare:(’a’) yields -1. 

We conclude this chapter by giving the syntax of an operator expression. 

operatorExpression ::= 

monadicOperator operand 

| operand dyadicOperator operand 

operand ::= 

operandObject | operatorExpression | messageExpression 

monadicOperator ::= 

not | - 

dyadicOperator ::= 

or | and | = | != | == | =!= | < | | > | - | + | * | / 

| div | mod 


35

36 

Chapter 4: Expressions

5 Control structures 

<strong>Sina</strong>/st defines three control structures, one conditional selection statement and two 

iterative constructs: 

• the conditional statement; 

• the for statement; 

• the while statement. 

5.1 The conditional statement 

The conditional statement can be used to choose between two alternatives. Its syntax is as 

follows. 

conditionalStatement ::= 

if expression 

then statements 

( else statements )? 

end 

Evaluation of the expression must yield an instance of class Boolean, that is, either true or 

false. If it yields true, the statements in the then-part will be executed. The else-part is 

optional, but when present, the statements in it will be executed when the expression 

yielded false. The following example determines the maximum and minimum of two 

variables a and b. 

EXAMPLE 5-1 if a < b 

then min := a; max := b 

else min := b; max := a 

end 

5.2 The for statement 

The for statement is used for iteration over numbers. It has the following syntax. 


37

38 

forStatement ::= 

for loopvar := startExpression to endExpression ( by stepExpression )? 

begin 

statements 

end 

The variable loopvar must have been declared before it can be used, for instance as a local 

variable or as an instance variable. Inside the loop, it is not allowed to change the value of 

loopvar, but you can assign a value to it outside the loop. The value of loopvar after the 

loop has finished is not defined. Before the iteration of the loop, the startExpression, 

endExpression and stepExpression will be evaluated respectively to determine the start 

value, end value and step value of the loop. The by stepExpression can be omitted, in 

which case a step value of 1 is used. The loopvariable loopvar will be initialized with the 

start value. The statements in the body will be executed as long as the value of loopvar 

does not exceed the end value. After each iteration, the step value will be added to the 

value of loopvar. For positive step values this means that the loop iterates while the value 

of the loopvar is less than or equal to the end value, and for negative step values while the 

value of the loopvar is greater than or equal to the end value. 

In the following example, f’s values are calculated from -2 to 2 in increments of 1/8 and 

plotted on the screen. 

EXAMPLE 5-2 for x := -2.0 to 2.0 by 0.125 

begin 

screen.plot(x, f.value(x) ) 

end 

5.3 The while statement 

The while statement is used for iteration while some condition is met. It has the following 

form. 

whileStatement ::= 

while expression 

begin 


end 

Evaluation of the expression must yield an instance of class Boolean, that is, either true or 

false. The statements in the body will be executed repeatedly until the evaluation of the 

expression yields false. 

The following example could be part of a window controller which tracks the mouse until 

a button is released. 

EXAMPLE 5-3 while mouse.buttonPressed 

begin 

mouse.track 

end 

Chapter 5: Control structures

6 Classes and 

instances 

In this chapter we will describe de structure of a class (section 6.1) and how an instance of 

a such a class is created (section 6.2). Section 6.3 describes the object manager which 

controls such an instance. 

6.1 Class declaration 

A class declaration consists of two parts, the interface part and the implementation part. 

The interface part can be preceded by class switches which can be used to control 

properties of a class. The class switches will be described after the interface and 

implementation part. 

classDeclaration ::= 

( classSwitch )* interfacePart implementationPart 

It is not allowed to define a class with the same name as an existing Smalltalk class, 

although an existing <strong>Sina</strong> class can be redefined. 

6.1.1 The interface part 

The interface part of a class defines 

• its name after the keyword class; 

• its parameters between the class name and the keyword interface. The parameters are 

surrounded by parentheses which must be omitted if the class has no parameters; 

• an interface comment in the section with the keyword comment; 

• the externals in the section with the keyword externals; 

• the internals in the section with the keyword internals; 

• the conditions in the section with the keyword conditions; 

• interface methods in the section with the keyword methods; 

• the set of input filters in the section with the keyword inputfilters; 

• the set of output filters in the section with the keyword outputfilters; 


39

40 

The general form of the interface part of a class is shown below. Some sections or parts of 

them can be omitted. The minimal interface of a class is comprised of the keyword class, 

its name and the keywords interface and end. 

interfacePart ::= 

class className classParameters? interface 

( comment string ; )? 

( externals ( variableDeclaration ; )* )? 

( internals ( variableDeclaration ; )* )? 

( conditions ( conditionDeclaration ; )* )? 

( methods ( interfaceMethodDeclaration ; )* )? 

( inputfilters ( filterDeclaration ; )* )? 

( outputfilters ( filterDeclaration ; )* )? 

end ; 

classParameters ::= 

( variableDeclaration ( ; variableDeclaration )* ) 

6.1.2 The implementation part 

The implementation part of a class defines 

• its name after the keyword class. The name must be the same as in the interface part; 

• an implementation comment in the section with the keyword comment; 

• the instance variables in the section with the keyword instvars; 

• the condition implementations in the section with the keyword conditions; 

• the implementation of the initial method in the section with the keyword initial; 

• the method implementations in the section with the keyword methods; 

The syntax of the implementation part is shown below. Some sections or parts of them can 

be omitted. The minimal implementation of a class is comprised of the keyword class, its 

name and the keywords implementation and end. 

implementationPart ::= 

class className implementation 


( instvars ( variableDeclaration ; )* )? 

( conditions ( conditionImplementation ; )* )? 

( initial ( methodBody ; )* )? 

( methods ( methodImplementation ; )* )? 

end ; 

6.1.3 Class switches 

A class switch can be used to control properties of a class, such as default behavior and 

mutual exclusion. A switch will apply to a single class. Currently supported class switches 

are: 

#Category ’A category’; 

#DefaultObject; 

#NoDefaultObject; 

#DefSyncFilter; 

#NoDefSyncFilter; 

#DefBehaviorFilter; 

#NoDefBehaviorFilter; 

Chapter 6: Classes and instances

Default behavior and 

synchronization 

The keywords of the switches are not case-sensitive: #defaultobject; #DEFAULTOBJECT; 

and #DefaultObject all denote the same switch. The switches will be described below. 

When a class has no switches defined, the class will provide default behavior and mutual 

exclusion. The compiler will realize this by inserting 

• an internal default of type <strong>Sina</strong>Object; 

• an input wait filter defSync which provides mutual exclusion for every instance of the 

class; 

• the conditions free and recursive which are used in the defSync filter; 

• an input dispatch filter defBehavior which provides default behavior for every instance 

of the class; 

#Category ’A category’; This switch controls the category in the Smalltalk system dictionary in which the compiled 

class will be stored. When this switch is not specified, the class will be stored in the 

category defined in the user intrface window (refer to section 14.2, page 129). 

#DefaultObject; 


These switches define whether or not an internal called default of type <strong>Sina</strong>Object will be 

inserted by the compiler automatically. Class <strong>Sina</strong>Object implements default behavior for 

a class, such as printing, copying, etc. (see appendix A.1, page 147). The definition of the 

internal is: 

internals 

default : <strong>Sina</strong>Object; 

The object default will be inserted 

• if the switch #DefaultObject; has been specified, or 

• if the switch #NoDefaultObject; has not been specified. 

The object default will be omitted 

• if the switch #NoDefaultObject; has been specified, or 

• if the class already has an external, internal or instance variable of an arbitrary type 

called default. 

When the internal default is inserted, it will be inserted as the first internal of the class. 

Table 6-1 illustrates where the internal default will be inserted. 

TABLE 6-1 Location of the internal default. 

#DefSyncFilter; 

#NoDefSyncFilter; 

// no switch specified #DefaultObject; #NoDefaultObject; 

class X interface class X interface class X interface 

externals ... externals ... externals ... 

internals internals internals 

default : <strong>Sina</strong>Object; default : <strong>Sina</strong>Object; 

a : A; a : A; a : A; 

b : B; b : B; b : B; 

... ... ... 

conditions ... conditions ... conditions ... 

methods ... methods ... methods ... 

inputfilters ... inputfilters ... inputfilters ... 

outputfilters ... outputfilters ... outputfilters ... 

end; end; end; 

These switches determine whether or not the input wait filter defSync will be inserted. 

This filter provides mutual exclusion for each instance of the class. The input wait filter 

defSync has the following definition: 


41

42 

#DefBehaviorFilter; 

#NoDefBehaviorFilter; 

defSync : Wait = { {free, recursive}=>inner.*, true~>inner.*}; 

The input wait filter defSync will be inserted 

• if the switch #DefSyncFilter; has been specified, or 

• if the switch #NoDefSyncFilter; has not been specified. 

The input wait filter defSync will be omitted 

• if the switch #NoDefaultObject; was specified, or 

• if the switch #NoDefSyncFilter; was specified, or 

• if the class already has an input filter called defSync. 

When the input waitf ilter defSync is inserted, it will be inserted before the first input filter 

that is not a wait filter. When no input filters are defined, or all the input filters are wait 

filters, the defSync filter will be placed after the last after input filter. 

When this filter is inserted, the conditions free and recursive will also be inserted unless 

the are already defined. Their implementations are defined as: 

conditions 

free begin return ^self.active = 0 end; 

recursive begin return message.isRecursive end; 

The defSync filter provides mutual exclusion. Messages with a selector defined by the 

class self, i.e. which are in the inner signature, will be blocked by the filter when there is 

already a local method active. Other message, those in the signature of internals or 

externals will never be blocked by this filter. The location of the defSync filter are 

illustrated in table 6-2. 

TABLE 6-2 Location of the input wait filter defSync and the conditions free and recursive. 

no switch specified #DefSyncFilter; #NoDefSyncFilter; 



internals ... internals ... internals ... 

conditions conditions conditions 

... ... ... 

free; free; 

recursive; recursive; 


inputfilters inputfilters inputfilters 

f1 : Wait = {...}; f1 : Wait = {...}; f1 : Wait = {...}; 


defSync : Wait = { ...} ; defSync : Wait = { ...} ; 

f3 : NonWait = {...}; f3 : NonWait = {...}; f3 : NonWait = {...}; 



... ... ... 



These switches define whether or not the input dispatch filter defBehavior will be inserted. 

This filter provides the behavior of the default object. The input dispatch filter defBehavior 

has the following definition: 

defBehavior : Dispatch = { default.* }; 

Chapter 6: Classes and instances

The input dispatch filter defBehavior will be inserted 

• if the switch #DefBehaviorFilter; has been specified, or 

• if the switch #NoDefBehaviorFilter; has not been specified. 

The input dispatch filter defBehavior will be omitted 

• if the switch #NoDefaultObject; was specified, or 

• if the switch #NoDefBehaviorFilter; was specified, or 

• if the class already has an input filter called defBehavior. 

When the input dispatch filter defBehavior is inserted, it will be inserted before the first 

input filter which is not a wait filter. When no input filters are defined, or all the input 

filters are wait filters, the defBehavior filter will be placed after the last after input filter. 

The location of the filter is shown in table 6-3. 

TABLE 6-3 Location of the input dispatch filter defBehavior. 

// no switch specified #DefBehaviorFilter; #NoDefBehaviorFilter; 



internals ... internals ... internals ... 

conditions ... conditions ... conditions ... 


inputfilters inputfilters inputfilters 



defBehavior : Dispatch = {...} ; defBehavior : Dispatch = {...} ; 



... ... ... 



6.2 An instance of a class 

As described in section 3.3.3, internals, instance variables and local variables are variables 

which will be initialized with a newly created instance of the class specified in the variable 

declaration. 

When an instance of a class is created, or constructed as it will be called here, its internals 

and instance variables will be constructed. This means that every internal and instance 

variable will be initialized with an instance of the class specified in the variable 

declaration. 

The same applies to the local variables (temps) of a method or main. When the method or 

main is invoked, its local variables will be constructed: each variable will be initialized 

with an instance of the class specified in the variable declaration. 

An external, a class or method parameter will not be constructed, since, in case of an 

external, the object already exists, and in case of a parameter, the object will be passed by 

the caller. 

When an instance x of a <strong>Sina</strong> class, say X, is constructed, the following actions will be 

carried out: 

• The class parameters of X, if any, will be initialized with the values of the arguments of 

x’s declaration at the time of its construction; 


43

44 

• The existence of the class’ externals will be verified. If there are externals that do not 

exist, these will be reported on the object’s window and the creation of the instance is 

aborted with the error ‘Can’t create instance Y::x’, where x is the instance of class X 

declared as some internal, instance variable or local variable in class Y; 

• The internals will be constructed. This can, recursively, lead to the construction of 

instances of other classes. It is therefore not allowed to declare an internal of the same 

class from which it is part of; 

• The instance variables will be constructed. Again, this can lead to the construction of 

instances of other classes. It is neither allowed to declare an instance variable of the 

same class from which it is part of; 

• And finally, when class X has defined one, its initial method will be executed. 

6.3 The object manager 

Every instance has associated with it a so-called object manager. As the name implies, an 

object manager controls an object. It keeps track of the number of methods that have been 

invoked and finished, and the number of messages that have been blocked by a wait filter. 

An object manager can be referred to by the pseudo variable ^self and ^server. The former 

refers to the to the object manager of self while the latter refers to the object manager of 

server. An object manager is an instance of the class ObjectManager which provides the 

following methods (see also appendix A.4, page 150): 

TABLE 6-4 Methods of an object manager 

active returns SmallInteger; Answers the number of active (unfinished) 

method invocations in the object. Note that after 

an early return, a method still is active 

(executing). The method will finish only when 

its last statement has been executed. 

activeForMethod(selector : String) 

returns SmallInteger; 

Chapter 6: Classes and instances 

Answers the number of active (unfinished) 

invocations of the method given by the 

argument. 

blockedReq returns SmallInteger; Answers the number of messages that have been 

blocked by an input wait filter. 

blockedInv returns SmallInteger; Answers the number of messages that have been 

blocked by an output wait filter.

Return and early return 

Creating concurrency 

The declaration of 

an interface method 

7 Methods 

In <strong>Sina</strong>/st, there are three kinds of methods: 

• interface method; 

• private method; 

• initial method. 

The interface method is declared at the interface part of the class and can be called by any 

client object. A private method can only be invoked by its owner. Finally, the initial 

method is executed automatically at instance creation time, right after the internals and 

instance variables have been created. Sections 7.1 to 7.3 discuss the three method types in 

more detail. 

main Apart from these methods, which are bound to a class, <strong>Sina</strong>/st also defines the main 

method which can be used to start an application. The main method is the subject of 

section 7.4. 

A method returns a value —an object— when it executes a return statement or the 

equivalent object manager message ^self.reply() (see section 7.5). For normal methods, the 

return is the last statement that is executed by the method. In <strong>Sina</strong>/st, however, it is also 

possible that the method continues with the execution of statements after the it has 

returned a value. In this case, the method is a so called early return method. The 

statements following the return are executed concurrently with the method that invoked 

the early return method. With an early return method it is thus possible to create 

concurrency. Section 7.6 describes when a method is a normal or an early return method, 

while section 7.7 shows the difference between the invocation of a normal method and an 

early return method. 

Finally, section 7.8 describes the statements which are allowed in a method body. 

7.1 Interface method 

An interface method must have been declared at the interface part of a class. They are 

declared in the section of the interface part which starts with the keyword methods. An 

interface method declaration defines the name of the method, the names and types of the 

parameters and the type of the object returned from the method, its so-called returntype. If 


45

46 

the returntype is specified as nil, it means that the method always returns the nil object, i.e. 

that it does not return a relevant object. 

The syntax of an interface method declaration is shown below. 

methodDeclarations ::= 

( methods ( interfaceMethodDeclaration ; )* )? 

interfaceMethodDeclaration ::= 

methodName methodParameters? returns returnType 

methodName ::= 

identifier 

methodParameters ::= 

( variableDeclaration ( ; variableDeclaration )* ) 

returnType ::= 

nil | typeDescription 

The example below shows the interface of class Person which contains the declaration of 

three interface methods, setName, birthDay and age. 

EXAMPLE 7-1 A class Person interface 

comment ’’; 

externals 

internals 

conditions 

methods 

setName(firstname, surname : String) returns nil; 

birthDay returns Date; 

age returns SmallInteger 

// ... other interface methods 

inputfilters 

disp : Dispatch = {inner.*}; 

outputfilters 

end; // Person interface 

Making an 

interface method 

available for a client 

The first method, setName, does not return a value and therefore its returntype is nil. The 

two other methods, birthDay and age, return an instance of class Date and SmallInteger, 

respectively. The setName method has two parameters of the same type: firstname and 

surname both are Strings. The two other two methods, on the other hand, do not have any 

parameters. 

For an interface method to be able to be invoked by a client object, it is necessary that a 

Dispatch filter is declared in the group of input filters which contains a filter element (see 

page 64) that refers to the method. The target of such a filter element must be inner and its 

selector must match with the name of the method: this is the case if the selector of the filter 

element either is a wildcard or is same as the name of the method. 

In example 7-1 A, the input Dispatch filter disp includes such a filter element. The filters 

below exhibit some other combinations of filter elements for the interface methods of 

example 7-1. The f1 filter, for example, uses substitution on a message with selector 

dateOfBirth in order to invoke the method birthDay. Thus, if an object sends a message 

dateOfBirth to a Person, the birthDay method will be invoked and the date of birth of the 

Person will be returned. 

f1 : Dispatch = { [*.dateOfBirth]inner.birthDay, nameUnset => inner.setName }; 

f2 : Dispatch = {..., c2 => inner.*, ...}; 

Chapter 7: Methods

The implementation 

of an interface method 

How to call 

an interface method 

The section of the implementation part of a class which starts with the keyword methods, 

embodies the implementations of interface methods. The ordering of the methods is not 

important: the methods can be in a different order as they are declared at the interface part 

and private methods can be mixed in between as well. The syntax of the implementation of 

an interface method is as follows: 

interfaceMethodImplementation ::= 

methodName methodParameters? 


( temps ( variableDeclaration ; )* )? 

begin statements end 

The implementation of an interface method duplicates the names and types of the 

parameters from the declaration at the interface, and defines further the comment, the 

temporary variables and the body of the method. Note that the returntype is not repeated in 

the implementation. The example 7-1 B shows the implementation part of class Person 

with implementations of the aforementioned interface methods. 

An interface method can be called by sending a message, with a selector that is the same as 

the name of the method, to an object that supports the method. The setName method of 

class Person, for instance, could be called in the following ways: 

• p.setName(’John’, ’Smith’); 

In this case, the sending object sends the message to an object p which should be an 

instance of class Person (or even an instance that eventually delegates the message to 

an instance of class Person); 

• self.setName(’John’, ’Smith’); 

Here, the sending object sends a message to itself. By sending it to self, the message 

passes through the input filters of the object (after it passed through its output filters, to 

be precisely, see section 9.2, page 62); 

• inner.setName(’John’, ’Smith’); 

In this case, the sending object sends the message to inner, which calls the method 

directly, that is, without passing through the output filters or input filters. 

The implementation of the method age shows also a message sent to inner. The selector of 

this method, ageOn, does not refer to an interface method though, but to a private method. 

The private method is described in the coming section. 

EXAMPLE 7-1 B class Person implementation 



birthDay : Date; 

firstName, lastName : String; 

// ... other instvars 

conditions 

initial 

methods 

setName(firstname, surname : String) 

comment ’Define new firstName and lastName’; 

temps // ... no temps 

begin 

firstName := firstname; 

lastName := surname; 

end; // setName 

birthDay 

comment ’Answer my date of birth.’; 

begin 

return birthDay 

end; // birthDay 


47

48 

Joint declaration 

and implementation 

age 

comment ’Answer my current age’; 

temps today : Date today; 

begin 

return inner.ageOn(today) 

end; // age 

// ... other methods 

end; // Person implementation 

7.2 Private method 

A private method implements some behavior that only available to the owning object. 

Therefore, a private method is not declared in the interface part of a class, but its 

declaration and implementation are combined and defined in the implementation part. The 

implementation of a private method is similar to the implementation of an interface 

method. The only difference, though, is that the returntype of the private method is defined 

in the header: 

privateMethodImplementation ::= 

methodName methodParameters? returns returnType 




In the following example, the private method ageOn returns a SmallInteger which denotes 

the Person’s age on the day that is passed as an argument to the method. Note that in this 

specific implementation, the Smalltalk class Date is used and also the Smalltalk selectors 

subtractDate: and fromDays:. 

EXAMPLE 7-2 class Person implementation 

// ... same as in example 7-1 B 

methods 

// ... other methods 

How to call 

a private method 

ageOn(day : Date) returns SmallInteger 

comment ’Answer the age of this person on the argument date ”day” ’; 


dateDiff, date0 : Date; 

begin 

dateDiff := Date.fromDays:(day.subtractDate:(birthDay)); 

date0 := Date.fromDays:(0); 

return dateDiff.year - date0.year 

end; // ageOn 


A private method can be invoked by the owning object only, by sending a message to the 

pseudo variable inner. In this way, the message does not pass the input filters, nor the 

output filters, but the method is invoked directly. In the interface method age (see example 

7-1 B) the private method ageOn is called with today’s date as an argument. 

7.3 Initial method 

The initial method is optional and will be executed, if it has been defined, just after the 

instance has been created, including its internals and instance variables. This method 

allows, for instance, to initialize internals and instance variables with specific values. The 

initial method is specified in the class’ implementation part of a class, between the 

conditions and methods sections. 

Chapter 7: Methods

The returntype of the initial method is not specified, but is, by definition nil: the initial 

method does not return a value. Neither does it have parameters. Like the private and 

interface methods, the implementation of the initial method defines a comment, temporary 

variables, both optionally, and the method body: 

initialMethodImplementation ::= 

initial 



begin statements end ; 

The initial method for class Person is shown in the following example. The name of every 

new Person instance will be initialized with ‘Nomen Nescio’. 

EXAMPLE 7-3 class Person implementation 



// ... from example 7-1 B 

conditions 

initial 

comment ’Define firstName and lastName’; 

temps 

begin 

firstName := ’Nomen’; 

lastName := ’Nescio’; 

end; // initial 

methods 

// ... from examples 7-1 and 7-2 


7.4 Main method 

The main method can be used start an application. In general, the main method is very 

small, but you can use it to test newly defined classes. We have used the main method 

already several times. The syntax form of the main method is as follows: 

main ::= 

main 


( externals ( variableDeclaration ; )* )? 



The externals and temps sections are used to declare externals and local variables, 

respectively. In main, an external refers to a global external stored in the <strong>Sina</strong>Repository. 

The main method can also be used to create a new external (see section 3.4, page 28). The 

body can contain any number of statements. 

The main method returns nil. It is possible to perform an early return in main. The main 

method can be executed by selecting the run option from the menu in the 

source code view (see [Koopmans95]). 

7.5 Returning a value from a method 

A value —an object— can be returned from a method in two ways: 

• by execution of the return statement, or 

• by sending the message reply to the object manager ^self. 


49

50 

^self.reply message The ^self.reply(...) message is an ordinary message expression (see section 4.2, page 32). 

The argument of the reply message is an expression that specifies the value to be returned 

by the method. 

Return statement A return statement consists of the keyword return and is optionally followed by an 

expression. This expression denotes the value to be returned by the method. The 

expression following return can only be omitted if the return value of the method is 

specified as nil. 

The return statement is actually equivalent to the ^self.reply(...) message. Table 7-1 shows 

the equivalence between the return statement and the objectmanager message reply. The 

<strong>Sina</strong>/st compiler translates a return statement into its corresponding reply message. 

The interface methods birthDay, age (example 7-1 B), and the private method ageOn 

(example 7-2) all show the application of the return statement to yield a value from the 

method. By using the objectmanager message reply, the method age, for instance, could 

also be written as follows. 

EXAMPLE 7-4 age 

comment ’Answer my current age’; 

temps today : Date today; 

begin 

^self.reply( inner.ageOn(today) ) 

end; 

Implicit return if no 

return expression 

in method body 

TABLE 7-1 Equivalence of return statement and object manager message reply 

return ^self.reply(nil) 

return nil ^self.reply(nil) 

return expression ^self.reply(expression) 

If a method body does not include a return expression (i.e. a return statement or a 

^self.reply message), the return statement return is implicitly the last statement in the 

method body. Note that this is only possible for methods whose return value is specified as 

nil: the compiler will flag an error if the return value of the method is not nil and its body 

does not contain a return expression. 

The interface method setName (example 7-1 B) and the initial method (example 7-3) of 

class Person are illustrations of methods with an implicit return statement. 

Early return Normally, if the method has returned a value, the method finishes its execution. However, 

if other statements follow the return in the body of the method, the method will continue to 

execute these statements. This kind of method is called an early return method and is 

subject of the next section. 

7.6 Normal versus early return 

In this section we define more precisely if a method is a normal method or an early return 

method (definition 7-2). It is based on the notion called control flow. Further, we define 

requirements which must be obeyed by every control flow (definitions 7-3 to 7-5). This 

section ends by giving examples of early and normal methods. 

DEFINITION 7-1 Control flow in a method 

A control flow in a method (or flow for short) is one possible execution of statements of the 

method body. The flow starts with the first statement of the method body, then the next, 

etcetera. 

There are several flows of control possible if a method body contains a conditional or a 

loop statement. In a conditional statement, depending on the value of the condition, the 

Chapter 7: Methods

flow can either follow the then or else branch. The statements in the body of a while or for 

loop can be executed zero or more times. 

For the following method body we have indicated the possible flows of control. One flow, 

labeled f 1 , starts by evaluating the condition c1 and, if c1 was true, continues in the then 

branch by executing the statement s1 and returning object x (denoted in the flow by ^x). 

Further, there is an infinite number of other flows, all indicated by f 2 (i). They all start by 

evaluating c1 to false (denoted by ~c1) and then continue with the execution of the while 

loop. The statement s2 in the body of the while loop will be executed as long as the 

condition c2 evaluates to true (denoted by (c2, s2) i ). The flow ends by returning the object 

y after c2 becomes false (shown as ~c2, ^y). 

begin 

if c1 

then s1; return x 

else 

while c2 begin s2 end 

end; 

return y 

end; 

f 1 = c1, s1, ^x 

f 2 (i)= ~c1, (c2, s2) i , ~c2, ^y with i=0,1,2,… 

Now that we have defined the control flow in a method, we define when a method is a 

normal or an early return method. 

DEFINITION 7-2 Early return method and normal return method 

A method is an early return method if there is a flow in which the return statement is 

followed by at least one other statement. 

Consequently, a method is a normal method if the last statement in every flow is a return 

statement. 

Examples of normal and early return methods are given at the end of this section. In the 

following section the difference between the invocation of a normal and an early return 

method is explained. But first we define two rules that must be valid for every control flow 

in a method. 

DEFINITION 7-3 Control flow requirements 

The following two requirements must hold for every control flow of a method: 

1. In every flow there must be a return. 

2. Only one return is allowed in a flow. 

The first requirement is needed because the method must always return a value. If this not 

the case, the compiler generates the error ‘No value returned in one flow’. 

The second requirement is needed because a method can return a value only once. The 

compiler produces the error ‘Return after early return is not allowed’ if this requirement is 

disregarded. 


51

52 

The first three of the following method bodies do not follow the first requirement, while 

the last breaches the second. The offending elements are highlighted. 

begin 

begin 

s1; 

if c 

s2; 

then 

s3; 

s1; 

end; 

return x; 

end; 

s2; 

end; 

f= s1, s2, s3 f1 = c, s1, ^x 

f2 = ~c, s2 

We introduce two further rules, one for the conditional statement and another for the two 

loop statements. They are not really necessary since they are already covered by the two 

control flow requirements, but they ‘make life easier’. 

DEFINITION 7-4 Control flow requirement for the conditional statement 

If in a conditional statement either the then-branch or the else-branch has an early return, 

there must be a return in the other branch too. 

The statements following the conditional statement are executed after the execution of 

either branch. These statements are not allowed to have another return, because of the 

early return in one branch. The flow via the other branch thus would have no return, 

thereby breaching the first control flow requirement. The compiler generates the error 

‘Early return in one flow, no return in the other’ in case this rule is not satisfied. 

DEFINITION 7-5 Control flow requirement for the while and the for statement 

An early return inside the body of a loop statement (a while statement or a for statement) is 

not allowed, though a normal return is. 

This is rule is needed because the body of the loop can be executed several times, and 

therefore the (early) return could be executed more than once too. A breach of this rule 

causes the compiler to generate the error ‘Early return not allowed inside loop’. 

The following two method bodies display violations of these rules. 

// Early return in one flow, 

// no return in the other 

begin 

if c 

then s1; return x; s2 

else s3; 

end; 

s4; 

end; 

f 1 = c, s1, ^x, s2, s4 

f 2 = ~c, s3, s4 

Chapter 7: Methods 

begin 

while c1 

begin 

s1; 

if c2 then 

return x; 

end; 

end; 

s3; 

end; 

begin 

s1; 

return x; 

s2; 

return y; 

s3; 

end; 

f 1 (i)= (c1, s1, ~c2) i , ~c1, s3 

f 2 (i)= (c1, s1, ~c2) i ,c1, s1, c2, ^x 

with i=0,1,2,… 

// Early return not allowed 

// inside loop 

begin 

while c 

begin 

s1; 

return x; 

s2; 

end; 

end; 

f(i)= (c, s1, ^x, s2) i , ~c 

For instance if i=2: 

f= s1,^x, s2,^y, s3 

f(2)= c, s1, ^x, s2, ~c, s1, ^x, s2, ~c

Finally, this section presents examples of normal and early return methods. Example 7-5 A 

shows bodies of normal methods and their associated flows of control. Example 7-5 B 

shows the method bodies of some early return methods together with their flows. 

EXAMPLE 7-5 A Normal method bodies and their control flows. 

begin 

s1; 

s2; 

s3; 

return x; 

end; 


begin 

if c 

then s1; 

else s2; 

end; 

s3; return z; 

end; 

f 1 = s1, s2, s3, ^x f 1 = c, s1, s3, ^z 

f 2 = ~c, s2, s3, ^z 

begin 

if c1 

then s1; return x; 

end; 

if c2 

then s3; return y; 

end; 

s5; return z; 

end; 

f 1 = c1, s1, ^x 

f 2 = ~c1, c2, s3, ^y 

f 3 = ~c1, ~c2, s5, ^z 

begin 

while c 

begin 

s1; 

return x; 

end; 

s2; return y; 

end; 

f 1 = c, s1, ^x 

f 2 = ~c, s2, ^y 

begin 

if c1 


else s3; 

if c2 


else s7; return z; 

end; 

end; 

end; 

f 1 = c1, s1, ^x 

f 2 = ~c1, s3, c2, s5, ^y 

f 3 = ~c1, s3, ~c2, s7, ^z 

begin 

while c1 

begin 

s1; 

if c2 


else s3; return y; 

end; 

end; 

s4; return z; 

end; 

f 1 = c1, s1, c2, s2,^x 

f 2 = c1, s1, ~c2, s3,^y 

f 3 = ~c1, s4, ^z 

begin 

if c 



end; 

end; 

f 1 = c, s1, ^x 

f 2 = ~c, s2, ^y 

begin 

while c 

begin s1; s2; 

end; 

s5; return z; 

end; 

f(i)= (c, s1, s2) i , ~c, s5, ^z 

with i=0,1,2,... 

begin 

while c1 

begin 

s1; 

if c2 


end; 

s3; 

end; 

s4; return z; 

end; 

53 

f 1 (i)= (c1, s1, ~c2, s3) i , ~c1, s4, 

^z 

with i=0,1,2,... 

f 2 (i)= (c1, s1, ~c2, s3) i-1 , c1, s1, 

c2, s2, ^y 

with i=1,2,3,...

54 

EXAMPLE 7-5 B Early return method bodies and their control flows. 

When does a method 

invocation start? 

What happens upon 

method invocation? 

begin 

s1; 

return x; 

s2; 

s3; 

end; 

7.7 Method invocation 

This section describes (1) when a method is invoked, (2) what happens upon and during 

the invocation of a method, and (3) the difference between the invocation of a normal and 

an early return method. 

A method is invoked in one of the following cases: 

• if a Dispatch filter accepts a message which was passing the input filters and dispatches 

it to inner. This is possible for interface methods only; 

• if a message is sent to the pseudo variable inner. In this way, both interface methods 

and private methods can be invoked; 

• at instance creation time. The initial method is invoked in this way and in this way 

only. 

Upon invocation of a method, the local variables (temps) of the method are created first: 

every local variable is initialized with a instance of the class which was specified by the 

declaration of the variable. Note that the parameters of a method —the arguments of the 

message— have been passed by reference because all variables are object references in 

<strong>Sina</strong>/st. What happens next depends on whether the invoked method is a normal or an 

early return method. 

Figure 7-1 depicts those differences. An early return method creates a new thread 1 , while a 

normal method does not. The start and the end of a thread are represented by an downward 

and an upward pointing triangle, respectively. The thread itself appears as a continuous or 

1. A thread is a sequence of messages which can execute concurrently with other threads. See section 10.3, 

page 75. 

Chapter 7: Methods 

begin 

if c 



end; 

s5; s6 

end; 

f 1 = s1, ^x, s2, s3 f 1 = c, s1, ^x, s5, s6 

f 2 = ~c, s3, ^y, s5, s6 

begin 

if c1 


else 

s2; 

if c2 



end; 

s5; 

end; 

end; 

f 1 = c1, s1, ^x 

f 2 = ~c1, s2, c2, s3, ^y, s5 

f 3 = ~c1, s2, ~c2, s4, ^z, s5 

begin 

if c1 


else 

s2; 

if c2 



end; 

end; 

s5; 

end; 

f 1 = c1, s1, ^x, s5 

f 2 = ~c1, s2, c2, s3, ^y, s5 

f 3 = ~c1, s2, ~c2, s4, ^z, s5 

begin 

if c 


else s3; return y; s4 

end; 

s5; s6 

end; 

f 1 = c, s1, ^x, s5, s6 

f 2 = ~c, s3, ^y, s4, s5, s6 

begin 

while c 

begin 

s1; s2; 

end; 

s3; 

return x; 

s4; 

s5 

end; 

f(i)= (c, s1, s2) i , ~c, s3, ^x, s4, 

s5 

with i=0,1,2,...

dashed line, and a method as a rectangle. The figure below 2 shows two possible 

invocations of method m1 as the result of the so-called invoking message (obj.m1) which 

has been sent in the so-called invoking method m0. 

FIGURE 7-1 Invocation of a normal method and an early return method. 

Invocation of a 

normal method 

Invocation of an 

early return method 

Pseudo variables 

during the invocation 

normal early return 

method method 

m0 m0 

return x 

If m1 is a normal method, the statements in the body of the method will be executed in the 

same thread in which the invoking message was sent. The statements in the body are 

executed one after another until a return is executed (return x). Then, the invoking method 

(m0) continues with the statement which follows the invoking message (obj.m1). 

For an early return method (shown right in figure 7-1) a new thread is created and the 

statements of the method body are executed in this thread. The invoking method and its 

thread are blocked until the invoked method returns an object (return x). The invoking 

thread then resumes its execution: the remaining statements of the invoking method are 

executed concurrently with the statements following the return in the invoked method. The 

thread in this method ends when its last statement has been executed. 

Using an early return method, we can create a new, concurrent thread. Note that a new 

thread is created every time an early return method is invoked. 

During the invocation of the method, the pseudo variables refer to the following objects: 

• message: the invoking message. It is an instance of class ActiveMessage; 

• inner: the inner part of the executing object, i.e. without the encapsulating interface 

part, without the filters; 

• self: the executing object; 

• server: the object that originally received the invoking message; 

• sender: the object which has sent the invoking message. 

2. This figure shows two diagrams similar to the diagrams used in chapter 10. In the diagrams used here, we 

have omitted the passing of the message through the filters, but we do show the invoking method. 


obj.m1 obj.m1 

m1 m1 

Invoking Thread 

New Thread 

return x 

55

56 

7.8 Statements in a method body 

The statements in the method body are separated by semicolons. It is possible to have an 

empty statement, and thus also to have an empty method body. A statement can further be 

an assignment (section 3.3.4), an expression (chapter 4), one of the control structures 

(chapter 5) or a return statement (section 7.5). The syntax is as follows: 

statements ::= 

statement 

| statements ; statement 

statement ::= 

assignmentStatement 

| messageExpression 

| operatorExpression 

| conditionalStatement 

| forStatement 

| whileStatement 

| returnStatement 

| // i.e. empty 

Chapter 7: Methods

8 Conditions 

A condition provides information about the current state of an object. It is a special kind of 

method that takes no parameters and returns a boolean result. Apart from conditions 

defined by the class self, so called local conditions, it is possible to reuse a condition from 

another class. 

A condition is declared at the interface part of a class (section 8.1), while the 

implementation of a local condition is defined in the implementation part (section 8.2). 

Note that the implementation of a reused condition is defined by the class it has been 

reused from. Section 8.3 describes the use of conditions. 

8.1 Condition declaration 

There are two forms of condition declaration, a reused condition and a local condition 

declaration. The reused condition defines the name of the condition and the object it is 

reused from. This object must be an external or an internal. The local condition declaration 

defines only its name, while its implementation is defined in the implementation part. It is 

not allowed that a condition and a method have the same name. The syntax of a condition 

declaration is shown below. 

conditionDeclarations ::= 

( conditions ( conditionDeclaration ; )* )? 

conditionDeclaration ::= 

localConditionDeclaration | reusedConditionDeclaration 

localConditionDeclaration ::= 

conditionName 

reusedConditionDeclaration ::= 

objectName . conditionName 

conditionName ::= 

identifier 

objectName ::= 

identifier 


57

58 

We show the declaration of two local conditions in the example below. Class 

BoundedBuffer allows you to store and retrieve objects using the put and get method, 

respectively. The condition notFull represent the state in which the buffer is not full yet. 

The condition notEmpty describes the state in which the buffer contains at least one 

element. An object can be stored in the buffer if the buffer is not full, while an object can 

be retrieved from it if the buffer is not empty. The conditions are used in the wait filter 

bufferSync to specify the synchronization of the buffer. Section 9.6.4 will discuss the wait 

filter in more detail. 

EXAMPLE 8-1 A class BoundedBuffer(limit : SmallInteger) interface 

conditions 

notFull; 

notEmpty; 

methods 

put(object : Any) returns nil; 

get returns Any; 

inputfilters 

bufferSync : Wait = {notFull => put, notEmpty => get}; 

dispatching : Dispatch = {inner.*}; 

end; // BoundedBuffer interface 

8.2 Condition implementation 

The implementation of conditions are defined in the conditions section of the 

implementation part of a class. The ordering of the conditions is not important: the 

conditions can be in a different order as they are declared at the interface part. The 

condition implementation has a similar structure as a method implementation. A comment 

and local variables can be defined, while the body can contain any statement also allowed 

in the body of a method. The syntax of the condition implementation as follows: 

conditionImplementations ::= 

: ( conditions ( conditionImplementation ; )* )? 

conditionImplementation ::= 

: conditionName 


( temps ( objectDeclaration ; )* )? 


As an example of condition implementations, we continue with the implementation of 

class BoundedBuffer, shown below. The buffer stores its elements in the instance variable 

store. The instance variables putpos and getpos hold the position in the array store where 

to store (method put) and retrieve (method get) the next object, respectively. Initially, they 

will both be at the first position, i.e. 1. The buffer is empty if putpos and getpos are the 

same. The buffer is full if the putpos is about to overtake the getpos, that is, if (limit + 

getpos - putpos) mod limit = 1. Note that the capacity (the maximum number of objects) of 

the buffer is limit - 1: the last free position, in this particular implementation, is needed to 

be able to recognize the full state. 

The implementation of the notFull and notEmpty conditions are straightforward: they are 

the logical negation of the formerly derived full and empty constraints. 

EXAMPLE 8-1 B class BoundedBuffer implementation 

instvars store : Array(limit); // index ranges from 1 to limit 

putpos, getpos : SmallInteger; 

conditions 

notFull 

begin 

return not((limit + getpos - putpos) mod limit = 1) 

Chapter 8: Conditions

end; 

notEmpty 

begin 

return not(putpos = getpos) 

end; 

initial 

begin putpos := 1; getpos := 1; end; 

methods 

put(object : Any) 

begin 

store.at:put:(putpos, object); 

putpos := putpos mod limit + 1 

end; 

get 

temps object : Any; 

begin 

object := store.at:(getpos); 

getpos := getpos mod limit + 1; 

return object 

end; 

end; // BoundedBuffer implementation 

8.3 Using a condition 

Condition invocation A condition is mainly invoked during the filtering of a message: a filter uses a conditions 

to decide to accept or reject the message. A condition, however, can also be invoked by its 

owner by sending a message to inner. This can be used for creating a condition which is a 

logical combination of other conditions and in a method to provide state information of the 

object. It is however not possible for objects to call a condition by sending a message to its 

owner. 

Pseudo variable 

message 

The notFull and notEmpty conditions of example 8-1 could be combined to provide a 

condition called partial which reflects the state if the BoundedBuffer instance is neither full 

nor empty. Its implementation can be defined as: 

partial 

begin return inner.notFul and inner.notEmpty end; 

The second use of invoking a condition is, for example, in a method printState of class 

BoundedBuffer which displays whether the buffer is full or not. This method could be 

defined as: 

printState 

begin 

if inner.notFull 

then self.print(’The buffer is not full’) 

else self.print(’The buffer is full’) 

end 

end; 

If a condition has been invoked during the filtering of a message, the pseudo variable 

message refers to this message. It can be used to examine the attributes of the filtered 

message. For instance, the condition ifYouAreAPostman (example 9-4, page 68) tests 

whether the sender of a message is a postman, i.e. an instance of class Postman. It could 

have been defined as 

conditions 

ifYouAreAPostman 

begin return message.sender.class == Postman end; 


59

60 

If a condition has been invoked by sending a message to inner, the pseudo variable 

message refers to this message. 

Conditions must be side effect free: this means that the condition must not invoke local 

methods since this can lead to the release of blocked messages. The current compiler 

cannot check whether a condition is side effect free. It is therefore the responsibility of the 

programmer to provide such conditions. 

Finally a warning. Do not send a message to self, server or sender, in the condition body, 

as this can or, in case of a message to self, certainly leads to a deadlock situation. This is 

understandable because the condition is evaluated while the message is filtered by the 

filtergroup. Only one message will be evaluated by a filtergroup at a time. Other arriving 

messages are blocked until the filtered message leaves the filtergroup. If a condition sends 

the aforementioned message, it waits forever for its reply. 

Chapter 8: Conditions

9 Filters 

This chapter discusses the various filter types and the filtering mechanism. First it 

introduces some terminology and general concepts. 

9.1 Introduction 

Every class specifies a group of input filters and a group of output filters. A message sent 

to an object must pass the input filters, and a message sent by an object must pass its output 

filters. Every filter in the group of filters filter a message that passes it. This means that the 

filter determines whether it accepts or rejects the message, and then takes an accept or 

reject action, respectively. A filter accepts a message if it is accepted by one of the 

filterelements specified in the filterinitializer. The message is rejected if no filterelement 

can accept the message. The filterinitializer contains a number of filterelements. A 

filterelement consists of a condition and a messagepattern: it accepts a message if the 

condition is true and the message matches the messagepattern. 

The accept, c.q. reject action of a filter is determined by the filterhandler of the filter. The 

filterhandlers implemented in <strong>Sina</strong>/st version 3.00 include Dispatch, Error, Send, Wait and 

Meta. A filter with such a handler is called a dispatch filter, an error filter, a send filter, a 

wait filter or a meta filter, respectively. 

EXAMPLE 9-1 class Stack interface 

... 

inputfilters 

stackEmpty : Error = { stackNotEmpty => pop, true ~> pop}; 

invoke : Dispatch = { inner.pop, inner.push}; 

... 


The example above shows a group of two input filters as part of the interface of class 

Stack. The filter called stackEmpty is an error filter —its handler is Error— and its 

initializer contains two filterelements: stackNotEmpty => pop and true ~> pop. If the stack 

is not empty, this filter will accept a message with selector pop, since the first filterelement 

accepts such a message: the condition stackNotEmpty evaluates to true and the selector of 

the message matches the messagepattern pop. The second filterelement true ~> pop is an 

exclusion filterelement. Such kind of filterelement will accept a message if the condition 

evaluates to true and the message does not match the message pattern. The exclusion 


61

62 

Which messages pass 

the input filters? 

Which messages pass 

the output filters? 

element true ~> pop thus accepts messages that do not have a selector pop. The 

stackEmpty error filter thus rejects a message pop if the stack is not empty and accepts 

other messages. The accept action of an error filter causes the message to be offered to the 

following filter, while the reject action raises an error. 

The next filter is called invoke. This is a dispatch filter —its handler is Dispatch— which 

accepts a message with a selector pop (accepted by its first filterelement) or push (accepted 

by its second filterelement). The dispatch filter accept action dispatches the message to 

inner which causes the respective methods pop and push to be invoked. A message that is 

rejected by a dispatch filter is passed on to the next filter. If there are no further filters in the 

set, such as in this case, and a message has fallen through the last filter, an error will be 

raised. 

9.2 Input and output filters 

Every object has a group of input filters and a group of output filters. This has been 

depicted in figure 9-1. A group of filters acts like a layered collection of sieves: a message 

is sieved by each filter in that group in turn, until a filter filters it out. If a message has 

passed all the filters in the group, —i.e. no filter has filtered it out— the object cannot 

handle the message and it will raise an error. 

The group of input filters determines how a message that is sent to the object containing 

them, is handled by that object. Every message that is sent to an object passes the group of 

input filters of that object. For instance, in figure 9-1, a message x.m(a1, ..., an) is sent to 

object x first passes the input filters of x. Suppose the input dispatch filter f3 of x accepts 

the message and delegates it to an object z which is an internal or external of x: the 

message then passes through the input filters of z. 

The group of output filters determines how a message that is sent by the object to another 

object is handled. Only a message sent to an object that lays outside the boundary of the 

sending object will pass the output filters of the sending object. That is, if an object sends a 

message to one of its externals, to self, server or sender, the message will pass the output 

filters. A message will not pass through the output filters if it is sent to the pseudovariable 

message, to an object manager ^self or ^server, to an internal or an instance variable of the 

object, or to a local variable of a method, but enters the input filters of the receiver of the 

message directly. A message sent to inner does not pass through the output filters either, 

but since inner is the object without filters, a method is invoked immediately. 

FIGURE 9-1 An object with input and output filters 

object x 

input filters of x 

internals of x 

output filters of x 

In figure 9-1, in a method of the object x message y.m2 is sent. If y is an external of x, the 

message passes the output filters of x, otherwise y is an internal or instance variable of x, or 

a local variable of the method and therefore the message enters the input filters of y 

directly. 

Chapter 9: Filters 

f1 : Error = {...} 

f2 : Wait= {...} 

f3 : Dispatch = {...} 

f4 : Wait = {...} 

f5 : Meta = {...} 

f6 : Send = {...} 

y.m2 

self.m3 

externals of x 

methods of x

A reused filter is bound 

at compile-time 

The group of input and output filters are declared in the class interface part, in the section 

starting with the keywords inputfilters and outputfilters, respectively. 

inputfilters ::= 

inputfilters ( filterDeclaration ; )* 

outputfilters ::= 

outputfilters ( filterDeclaration ; )* 

9.3 Filterdeclaration 

There are two forms of filter declarations: the declaration of a local filter, an d the 

declaration of a reused filter. The former defines the filter handler and the filterinitializer 

self. The second form declares a filter that is reused from an external or internal object. 

This means that the filter handler and initializer is determined by the class of the external 

or internal object. 

9.3.1 Reused filter 

It is possible to reuse a filter from an other class with the reused filter declaration: 

filterDeclaration ::= 

objectName . filterName 

The objectName must be the name of an internal or external object. The filterName must 

be a name of either a reused filter declaration or a local filter declaration of the object to 

which the objectName refers. 

The handler and the initializer are as that of the reused filter declaration. Objects (matching 

and substitution targets) and conditions that are referred to in the initializer are bound to 

those (in the scope) of the reusing object, i.e. not to those of the object from which the 

filter declaration is reused. 

In the current compiler version (version 3.00) only compile-time binding to the filter 

declaration is used. This means that if its handler or initializer changes (in class it is reused 

from) after an object that reused this filter has been compiled, this object is not updated 

with the new definition of the filter. 

9.3.2 Local filter 

With the local filter declaration, the class can specifies its name, handler and initializer: 

filterDeclaration ::= 

filterName : filterHandler = filterInitializer 

The filtername defines the name of the filter. The filterhandler defines the handler of the 

filter which must be on of Dispatch, Error, Wait, Send or Meta. The filterinitializer defines 

how a message is filtered by the filter. 

Filterinitializer The filterinitializer is comprised of at least one filterelement. Each filterelement determines 

if it accepts or rejects a message that passes through the filter. If a message is accepted by 

the filterelement, the message is accepted by the filter and its accept action will be carried 

out. If a message is rejected by a filterelement, the next filterelement (in declaration order, 

from left to right) will be consulted to see if that filterelement can accept the message. If no 

filterelement can accept the message, the message is rejected by the filter. In this case, its 

reject action will be carried out. 

filterInitializer ::= 

{ filterElement ( , filterElement )* } 


63

64 

Filterelement A filterelement determines if it accepts or rejects a message that passes through the filter. 

There are two forms: an inclusionelement and an exclusionelement. 

The inclusionelement accepts a message if one of the conditions in the conditionset 

evaluates to true and the message matches one of the patterns in the messagepatternset. 

The exclusionelement, on the other hand, accepts a message if one of the conditions in the 

conditionset evaluates to true and the message does not match any of the patterns in the 

messagepatternset. 

EXAMPLE 9-2 mySync : Wait = {m1, {c1, c2}=>b.*, true~>{b.*, m2}}; 

This example shows a wait filter which initializer has two inclusionElements and one 

exclusionElement. This filter would accept a message with selector m1 always, a message 

with a selector in the signature of b (see page 68) if either c1 or c2 is true, and a message 

with a selector that is not m2 and is not in the signature of b. 

filterElement ::= 

inclusionElement | exclusionElement 

inclusionElement ::= 

messagePattern | conditionSet => messagePatternSet 

exclusionElement ::= 

conditionSet ~> messagePatternSet 

Condition A condition referred to in a filterinitializer is has to be declared in the interface of the class. 

It can either be a reused condition or a condition implemented by the class itself. The 

condition true is also possible which evaluates always to true. 

conditionSet ::= 

condition | { condition ( , condition )* } 

condition ::= 

true | conditionName 

Messagepattern A messagepattern is used to match the selector or the target or both of the message. The 

matchingpattern and signaturepattern are the two forms possible. 

In the matchingpattern [a.b]c.d, the message must match with the matchingpart a.b, and if 

it does, the substitutionpart c.d will be returned as the result of the match. With the 

signaturepattern c.d, the message matches if the selector of the message is c and is 

included in the signature of d. 

messagePatternSet ::= 

messagePattern 

| { messagePattern ( , messagePattern )* } 

messagePattern ::= 

matchingPattern 

| signaturePattern 

matchingPattern ::= 

[ matchingPart ] substitutionPart 

matchingPart ::= 

messageSelector 

| objectName . messageSelector 

| *. messageSelector 

| self . messageSelector 

Chapter 9: Filters

substitutionPart ::= 

signaturePattern 

signaturePattern ::= 


| objectName . messageSelector 

| *. messageSelector 

| inner . messageSelector 

| self . messageSelector 

messageSelector ::= 

selector | * 

9.3.3 Rewrite rules for filterelements 

Some parts of the filterelements can be omitted —for instance, the conditionset in an 

inclusionelement— while others have multiple parts, like the conditionset. By rewriting 

them using the following rules, one can derive equivalent filterinitializer which contains 

inclusionelements that have a single condition and a single messagepattern, and 

exclusionelements that have a single condition and either a single or a set of 

messagepatterns. 

The rewrite rules for filterelements are listed in the following table. The first rule shows 

that the default target is the wildcard. A missing condition in a filterelement implies the 

true condition (rule 2). Rules 3 to 6 show that (set of) messagepattern(s) is distributed over 

the elements of a set of conditions. In the last rule, a single condition is distributed over the 

elements of a set of messagepatterns. 

TABLE 9-1 Rewrite rules for filterelements 

Filterelement Filterelement after rewrite 

1 sel *.sel 

2 mp true=>mp 

3 {c1 , c2 , ..., cn }=>mp c1 =>mp, ..., cn =>mp 

4 {c1 , c2 , ..., cn }=>{mp1 , ..., mpp } c1 =>{mp1 , ..., mpp }, ..., cn =>{mp1 , ..., mpp } 

5 {c1 , c2 , ..., cn }~>mp c1 ~>mp..., cn ~>mp 

6 {c1 , c2 , ..., cn }~>{mp1 , ..., mpp } c1 ~>{mp1 , ..., mpp }, ..., cn ~>{mp1 , ..., mpp } 

7 c=>{mp1 , mp2 , ..., mpp } c=>mp1 , c=>mp2 , ..., c=>mpp Note that there exists no rule that distributes a set of conditions over a set of 

messagepatterns. The filterelement {c 1 , c 2 , ..., c n }=>{mp 1 , ..., mp p } is therefore not 

equivalent to {c 1 , c 2 , ..., c n }=>mp 1 , ..., {c 1 , c 2 , ..., c n }=>mp p . Neither is the filterelement 

{c 1 , c 2 , ..., c n }~>{mp 1 , ..., mp p } equivalent to {c 1 , c 2 , ..., c n }~>mp 1 , ..., {c 1 , c 2 , ..., 

c n }~>mp p . 

EXAMPLE 9-3 The following four filterdeclarations are equivalent to each other by using the rules 1, 4 

and 7, respectively. 

defSync1 : Wait = { {free, recursive}=>{m3, inner.*}, true~>inner.*}; 

defSync2 : Wait = { {free, recursive}=>{*.m3, inner.*}, true~>inner.*}; 

defSync3 : Wait = { free=>{*.m3, inner.*}, recursive=>{*.m3, inner.*}, true~>inner.*}; 

defSync4 : Wait = { free=>*.m3, free=>inner.*, recursive=>*.m3, recursive=>inner.*, 

true~>inner.*}; 

But they are not equivalent to 

defSync5 : Wait = { {free, recursive}=>*.m3, {free, recursive}=>inner.*, true~>inner.*}; 


65

66 

9.4 Filtering a message 

This section describes the filtering of a message in detail. The filtering process of a 

message is made up of the steps shown below. The filterelement accept test of steps 4 to 8 

have been combined in table 9-2 for an inclusionelement and in table 9-3 for an 

exclusionelement. The signature of an object which is referred to in step 5b is defined in 

section 9.5. 

1. filtering through the group of filters. 

The message is offered to each filter in the group in turn, starting with the first, to filter 

it. If the filter did not sift it out, it will be offered to the next filter. If the last filter in the 

group has not filtered it out, an error will be raised: ‘Input filters didn’t filter out message 

M’ or ‘Output filters didn’t filter out message M’ if the message “fell through” all the 

input filters or output filters, respectively. 

A message will have been sifted out if either (a) an error occurred (error filter), or (b) 

the message received a reply. The latter is the case if the message eventually lead to the 

the invocation of a method (dispatch filter), or during the reification of the message, a 

reply was supplied for it (meta filter) 

Only one message is allowed to pass through the filtergroup at a time. If a message 

would like to pass the filtergroup while another is already being filtered by it, the 

message waits until the other message has left the group; 

2. filtering by a filter. 

If a filter is offered a message to filter, it must decide to accept or to reject the message. 

This is called the filter accept test of the message. If the filter rejects the message, its 

reject action is carried out. Otherwise the filter accepts the message and its accept 

action is carried out. 

What the accept and reject actions actually involve, depends on the filter handler. They 

will be described in the section 9.6. 

If the filter accepts the message, a new target object and a new selector becomes 

available, which some filters ignore (wait filter), some substitute them in the message 

(error, dispatch and send filter) and others use it as the receiver and selector of a new 

message (meta filter); 

3. the filter accept test. 

The message is offered to each filterelement of the its initializer in turn, starting with 

the left-most, to test if the filterelement accepts it. If it does so, the filter will accept the 

message, otherwise the message offered to the next-right filterelement. If none of the 

filterelements in the filterinitializer accepts the message, the filter rejects the message. 

4. the filterelement accept test. 

There are two kinds of filterelements: the inclusionelement C=>M and the 

exclusionelement C~>M or C~>{M1 , ... ,Mn }, in which C is a condition and M, M1 , ... 

,Mn are messagepatterns. 

a) The inclusion filterelement C=>M accepts a message if the condition C evaluates to 

true and the message matches messagepattern M. 

b) The exclusion filterelement C~>M accepts a message if the condition C evaluates to 

true and the message does not match messagepattern M. 

c) The exclusion filterelement C~>{M1 , ... ,Mn } accepts a message if the condition C 

evaluates to true and the message does not match any of the messagepatterns M1 , ... 

,Mn . 

5. messagepattern matching. 

There are two kinds of messagepatterns: the matchingpattern [mt.ms]st.ss and the 

signaturepattern mt.ms, in which mt is the matching target, ms the matching selector, 

st the substitution target and ss the substitution selector. 

a) A message matches the matchingpattern [mt.ms]st.ss if the receiver rcv of the 

message matches with the target mt, and if the selector sel of the message matches with 

the matching selector ms. 

Chapter 9: Filters

No target and selector 

returned by an 

exclusionelement 

b) A message matches the signaturepattern mt.ms if the message matches with the 

signature of target mt, and the selector sel of the message matches with the selector 

ms. 

6. matching the receiver rcv of the message with targetobject mt. 

If mt is the wildcard then the receiver rcv matches, otherwise the rcv matches with mt if 

and only if the rcv is the same object as mt refers to. 

7. matching the selector sel of the message with selector ms. 

If ms is the wildcard then the message matches, otherwise the message matches if and 

only if its selector sel is ms. 

8. matching with the signature of mt. 

If mt is the wildcard then the message matches, otherwise the message matches if and 

only if the signature of the object to which mt refers includes the selector sel. 

The table below lists the accept conditions (steps 4a, 5-8) for all possible inclusion 

filterelements. 

TABLE 9-2 Inclusionelement accept condition for a message m 

filterelement 

accept condition 

target 

return 

ed 

select 

orretu 

rned 

Table 9-3 below lists the accept conditions (steps 4b, 4c, 5-8) for the most of possible 

exclusion filterelements. In this table, •.• denotes either c.d, c.*, *.d or *.*. The left column 

shows filterelements C~>M with a single message pattern M, while the right column shows 

a filterelement C~>{M 1 ,M 2 , ...} with a set of message patterns M 1 , M 2 , .... 

Note that an exclusionelement does not return a target or selector if the message matches 

it. 


filterelement 


target 

return 

ed 

C=>[a.b]c.d C ∧ m.rcv = a ∧ m.sel = b c d C=>[b] d C ∧ m.sel = b - d 

C=>[a.b] c.* C ∧ m.rcv = a ∧ m.sel = b c - C=>[b] *.* C ∧ m.sel = b - - 

C=>[a.b] *.d C ∧ m.rcv = a ∧ m.sel = b - d C=>[b] * C ∧ m.sel = b - - 

C=>[a.b] d C ∧ m.rcv = a ∧ m.sel = b - d C=>[*.*] c.d C c d 

C=>[a.b] *.* C ∧ m.rcv = a ∧ m.sel = b - - C=>[*.*] c.* C c - 

C=>[a.b] * C ∧ m.rcv = a ∧ m.sel = b - - C=>[*.*] *.d C - d 

C=>[a.*] c.d C ∧ m.rcv = a c d C=>[*.*] d C - d 

C=>[a.*] c.* C ∧ m.rcv = a c - C=>[*.*] *.* C - - 

C=>[a.*] *.d C ∧ m.rcv = a - d C=>[*.*] * C - - 

C=>[a.*] d C ∧ m.rcv = a - d C=>[*] c.d C c d 

C=>[a.*] *.* C ∧ m.rcv = a - - C=>[*] c.* C c - 

C=>[a.*] * C ∧ m.rcv = a - - C=>[*] *.d C - d 

C=>[*.b] c.d C ∧ m.sel = b c d C=>[*] d C - d 

C=>[*.b] c.* C ∧ m.sel = b c - C=>[*] *.* C - - 

C=>[*.b] *.d C ∧ m.sel = b - d C=>[*] * C - - 

C=>[*.b] d C ∧ m.sel = b - d C=>c.d C ∧ m.sel = d ∧ d ∈ sig(c) c d 

C=>[*.b] *.* C ∧ m.sel = b - - C=>c.* C ∧ m.sel ∈ sig(c) c - 

C=>[*.b] * C ∧ m.sel = b - - C=>*.d C ∧ m.sel = d - d 

C=>[b] c.d C ∧ m.sel = b c d C=>d C ∧ m.sel = d - d 

C=>[b] c.* C ∧ m.sel = b c - C=>*.* C - - 

C=>[b] *.d C ∧ m.sel = b - d C=>* C - - 

67 

select 

orretu 

rned

68 

Do not specify an 

exclusionelement 

containing the wildcard 

pattern *.* 

Note also, that if an exclusionelement contains the wildcard pattern *.*, a message will 

never be accepted by it. It is therefore useless to specify an exclusionelement containing 

such a wildcard pattern, like C~>[*.*]•.•, C~>*.*, C~>{..., [*.*]•.•, ...} or C~>{..., *.*, ...}. 

TABLE 9-3 Exclusionelement accept condition for a message m 

filterelement 


9.5 The signature of an object 

The signature of an object is the set of message selectors that the object would accept if all 

the conditions in the input filters, and in the input filters only, would be true. 

DEFINITION 9-1 The signature of an object 

a. The signature of inner is the set of selectors of the interface methods. 

b. The signature of a <strong>Sina</strong> object a set which includes 

1)the non-wildcard matchingselectors ms of the matchingpatterns 

[mt.ms]st.ss of the input filters which perform substitution on the 

message. 

2)the signatures of the objects mt in the signaturepatterns mt.ms of the 

input filters which perform substitution on the message. 

c. The signature of a Smalltalk object is the set of selectors of the methods defined by its 

class and superclasses. 

To be specific: the signature of a <strong>Sina</strong> object is a set that includes (1) the selectors of the 

interface methods, (2) the non-wildcard matching selectors of matchingpatterns of input 

Error filters, (3) the non-wildcard matching selectors of matchingpatterns of input Dispatch 

filters, and (4) the signatures of the objects in signaturepatterns in input Dispatch filters. 

As an example of the signature of an object, consider the class Mailbox below, in which 

anyone can store a letter and only ifYouAreAPostman you can retrieve letters from it and 

access the box itself. The signature of an instance of Mailbox consists of the selectors 

putLetter, getLetters (the interface methods), emptyBox (matching selectors of the Error 

filter) and all the selectors defined by the object box (signature of box in Dispatch filter). 

EXAMPLE 9-4 class Mailbox interface 

internals 

box : Letterbox; 

conditions 

ifYouAreAPostman; 

methods 

putLetter(aLetter : Letter) returns nil; 

getLetters returns Letters; 

inputfilters 

error : Error = { [emptyBox]getLetters, inner.*, box.*}; 

Chapter 9: Filters 

target 

return 

ed 

select 

orretu 

rned 

filterelement 


target 

return 

ed 

C~>[a.b]•.• C ∧ (m.rcv ≠ a ∨ m.sel ≠ b) - - C~>{ [a.b]•.•, C ∧ (m.rcv ≠ a ∨ m.sel ≠ b) - - 

C~>[a.*]•.• C ∧ m.rcv ≠ a - - [a.*]•.•, ∧ m.rcv ≠ a 

C~>[*.b]•.• C ∧ m.sel ≠ b - - [*.b]•.•, ∧ m.sel ≠ b 

C~>[*.*]•.• false - - [*.*]•.•, ∧ false 

C~>c.d C ∧ (m.sel ≠ d ∨ d ∉ sig(c)) - - c.d, ∧ (m.sel ≠ d ∨ d ∉ sig(c)) 

C~>c.* C ∧ m.sel ∉ sig(c) - - c.*, ∧ m.sel ∉ sig(c) 

C~>*.d C ∧ m.sel ≠ d - - *.d, ∧ m.sel ≠ d 

C~>*.* false - - *.*, ...} ∧ false ∧ ... 

select 

orretu 

rned

end; 

delegate : Dispatch = { ifYouAreAPostman => {inner.getLetters, box.*}, 

inner.putLetter}; 

9.6 Filterhandlers 

In this section we describe the various filterhandlers. The filterhandlers implemented in 

<strong>Sina</strong>/st version 3.00 include Dispatch, Error, Send, Wait and Meta. Table 9-4 summarizes 

the accept action (left) and reject action (right) of each filterhandler. We have indicated if 

the filter performs the substitution of a new target and selector on the filtered message or if 

it discards them. For each filtertype it is further marked whether it can be used as an input 

filter, as an output or both. 

TABLE 9-4 Filter handler accept action and reject action. 

Dispatch Substitutions on message Input 

The new target and new selector are substituted to the accepted message, if The message continues in the next 

they are defined; 

If the receiver of the message became is inner, the method with the same 

selector as the message will be invoked; 

Otherwise the message will be offered for filtering to the input filters of the 

receiver of the message. 

filter. 

Error Substitutions on message Input Output 

The new target and new selector are substituted in the accepted message, if Raises the error ‘Reject in ErrorFilter 


X::f of M’, where X is the class in which 

Then the message continues in the next filter. 

this error filter f is defined and M is a 

representation of the message. 

Send Substitutions on message Output 

The new target and new selector are substituted to the accepted message, if The message continues in the next 


If its owning object has no encapsulating object, or if the receiver of the 

message lies inside its encapsulating object, the message will be offered to 

the input filters of the receiver of the message. Otherwise the message is 

offered to the output filters of the encapsulating object. 

filter. 

Wait Substitutions discarded Input Output 

The message continues in the next filter. Note that no substitution are The message is blocked, i.e. execution 

carried out. 

of the calling thread is suspended until 

the condition on which the message 

blocked becomes true; 

Then the message continues in the next 

filter. 

Meta Used for message to ACT Input Output 

The execution of the calling thread is suspended; 

The message continues in the next 

The accepted message is reified and becomes an instance of the class 

<strong>Sina</strong>Message; 

A new thread is created which sends a message with the new selector and 

the reified message as argument to the new target. This message does not 

pass through the output filters of the owning object but is offered to the 

input filters of the new target directly; 

The sending thread remains suspended until the reified message is dereified 

—this is if it receives a send, reply, fire or continue message; 

If the, now active message has a reply —if the reified form was reactivated 

with a reply message— it will not carry on in the next filter but return the 

reply to the sender. Otherwise it will be filtered by the following filter. 

filter. 


69

70 

9.6.1 Dispatch filter 

A dispatch filter can be used for inheritance and delegation. By declaring a dispatch filter 

which dispatches to the appropriate internal or external we can accomplish inheritance and 

delegation, respectively. Though dispatching a message to an internal object can be seen as 

inheritance, and dispatching to an external object as delegation, there is no distinction 

between those two: a dispatch filter dispatches a message to another object. 

By specifying more target objects, we can accomplish multiple inheritance, cq. delegation. 

The left to right ordering in the filterinitializer resolves any name conflicts resulting from 

multiple inheritance. 

In [Bergmans94a] and [Bergmans94b] it is further shown how the dispatch filter can be 

used for dynamic inheritance and delegation. 

As an example of the dispatch filter, consider the class Manager below. The dispatch filter 

inheritAndDelegate specifies that this class inherits from class Employee and further 

delegates messages to the external DepartmentSecretary. If both the classes Employee 

and Secretary support the method name, then the name method of Employee would be 

invoked, because it is the first target in the dispatch filter. 

class Manager interface 

externals DepartmentSecretary : Secretary; 

internals empl : Employee; 

... 

inputfilters 

inheritAndDelegate : Dispatch = {employee.*, DepartmentSecretary.*}; 

end; 

9.6.2 Error filter 

An error filter can be applied for checking incoming messages, multiple views and 

preconditions. In the Stack class (example 2-1A) we have seen the use of an error filter for 

checking messages. The use of the error filter for multiple views and preconditions has 

been described in [Aksit92], [Bergmans94a] and [Bergmans94b]. 

9.6.3 Send filter 

A send filter can only be used as output filter for delivering a message to its receiver. If no 

output filters are declared for a class, a send filter is inserted automatically by the compiler. 

9.6.4 Wait filter 

A wait filter can be used for synchronizing messages. A message which is rejected by a 

wait filter is blocked until the message would be accepted by the wait filter. 

Synchronization constraints are specified as the conditions in the initializer of a wait filter. 

As an example, consider the class BoundedBuffer which allows you to store and retrieve 

objects using the put and get method, respectively. An object can be stored in the buffer if 

the buffer is not full, while an object can be retrieved from it if the buffer is not empty. 

These synchronization constraints are specified by the wait filter bufferSync: a put message 

will be blocked if the notFull condition evaluates to false. A get message will be blocked if 

the notEmpty condition evaluates to false. 

EXAMPLE 9-5 class BoundedBuffer(limit : SmallInteger) interface 

conditions 

notFull; 

notEmpty; 

methods 

put(object : Any) returns nil; 

get returns Any; 

Chapter 9: Filters

Consecutive wait filters 

evaluated as if they are a 

single wait filter 

inputfilters 



end; // BoundedBuffer interface 

The implementation of the BoundedBuffer (shown in example 8-1 B, page 58), establishes 

that after a get message the condition notFull becomes true thus releasing a blocked put 

message. A put message changes the condition notEmpty to true, thus releasing a blocked 

get message. 

There is one additional rule which applies to wait filters and to wait filters only. 

Subsequent wait filters in the filtergroup (input filters or output filters) are evaluated as if 

they were a single wait filter having conditions which are combined from every wait filter 

with an and. This has the effect that constraints by earlier wait filters are not forgotten. A 

message will not be blocked if all the conditions in these consecutive filters evaluate to 

true. If there is at least one condition which is false, it will be blocked. The message is 

allowed to resume if all the conditions of the consecutive wait filters are true. 

Consider for example the input filters of the class MemBuffer which allocates memory to 

store elements. 

class MemBuffer interface 

... 

inputfilters 

memorySync : Wait = {memAvail => put, true => get}; 



end; 

The two wait filters are evaluated as if they had been the single wait filter 

sync : Wait = {memAvail and notfull => put, true and notEmpty => get}; 

9.6.5 Meta filter 

A meta filter is used for reflection on object interactions. Chapter 10 will discuss this filter 

type and its application more elaborately. The background of the meta filter can be found 

in [Aksit93]. 

That concludes the discussion of the filters and the filtering of a message. 


71

72 

Chapter 9: Filters

Abstract 

Communication Type 

10 Message passing 

semantics 

This chapter describes what can happen if an object sends a message to another object. The 

first section explains the two steps of message execution: filtering and method invocation. 

Section 10.2 discusses how a message and its attributes can be accessed during its 

execution. 

In <strong>Sina</strong>/st, a message can execute concurrently with other messages. Concurrent executing 

messages are described by the notion called thread. This is the subject of section 10.3. 

During the filtering of a message, a meta filter can reify the message. Message reification 

allows an object to reflect on message communication between objects. Section 10.4 

describes the process of message reification. An object which is able to reflect on —to 

abstract— message communication is known by the term abstract communication type, or 

ACT [Aksit89][Aksit93]. An ACT object can use reflection on message communication 

for constraint checking and controlling object interactions. 

The last section in this chapter reveals how the attributes of a reified message can be 

accessed and changed. 

10.1 Sending a message 

An object can request a service from another object by sending a message to it. Message 

passing in the composition filters object model follows the request/reply model: after a 

client object has sent a message —the request— to a server object, the client object waits 

until it receives a return value for the message —the reply— from the server object. 

The server object is entirely responsible for servicing the request: it can decide to handle 

the request itself (by executing some method), to delegate the request to another object, or 

even to reject it. 

In the Composition Filters Object Model, and thus also in <strong>Sina</strong>/st, the execution of the 

message involves two steps: 

• first, the message is filtered by filters. 

If the message leaves the object boundary of the sending object1 , the message will pass 

through the output filters of the sending object. Then, the message passes through the 

input filters of the server object. This object can decide (by the use of a dispatch filter) 


73

74 

to delegate the message to another object where it is filtered by the input filters of that 

object. 

• eventually, a method is invoked. 

The method is invoked if there is a dispatch filter which dispatches the message to 

inner. 

Those two steps are depicted in the diagram of figure 10-1. Similar message execution 

diagrams are used in the rest of this chapter. 

FIGURE 10-1 Execution of a message 

Request 

m1 

In such a message execution diagram, time increases towards the bottom. The start of the 

message execution, i.e. the issue of a message request, is indicated by a left pointing 

triangle . The message passes through the filters, shown by grey rectangles . In the 

figure above, we have indicated four filters: two wait filters (W) and two dispatch filters 

(D). The last filter invokes a method2 , m1 in this case, which is represented by the larger, 

white rectangle. The message execution ends when the invoked method returns an object 

(return x): this reply on the message has been denoted by a right pointing triangle . 

Active message We will call a message which is being executed, an active message. We can refer to an 

active message by the pseudo variable message. We explain more on this in the following 

section. 

Thread After the execution of a message has ended, the following message is executed in a similar 

way: it is filtered and it invokes a method. The invocation of the method, the white 

rectangle in the figure above, consists of a sequence of message executions on its own. If 

we magnify the white rectangle, we could see several message executions one after 

another, each of them consisting of filtering and method invocation again 3 . A sequence of 

such message executions is called a thread. The thread will be the topic of section 10.3. 

1. This is the case if the message is sent to an external of the sending object, or to the pseudo variables self, 

server or sender. A message to an internal, an instance variable, a class parameter, a method parameter or 

local variable, or to the pseudo variables message or inner, does not pass the output filters, but enters the 

input filters of the server object directly. 

2. This is a dispatch filter. A dispatch filter invokes a method m1 if its filterinitializer contains a filter element 

like inner.* or inner.m1. 

3. Where would this end, you might ask. There are some methods that do not send other messages: they 

implement primitive operations such as the addition of two numbers. 

Chapter 10: Message passing semantics 

W 

D 

W 

D 

return x 

Filtering 

Method Invocation 

Thread Reply

10.2 The pseudo variable message and class ActiveMessage 

In <strong>Sina</strong>/st, the pseudo variable message represents the active message which is an instance 

of the class ActiveMessage. Inside a method, message refers to the message that lead to 

the invocation of that method. Since condition evaluation is part of the message filtering 

process, the pseudo variable message inside a condition refers to the message that is 

currently being filtered. 

TABLE 10-1 Accessing the attributes of message. 

message.selector Returns a String which is the selector of the message. 

message.numArgs Returns a SmallInteger, indicating the number of arguments 

of the message. 

message.args Returns an Array containing the arguments. 

message.argsAt(n) Returns the nth argument. 

message.sender Returns the sender of the message. In a method, this object is 

also available through the pseudo variable sender. 

message.server Returns the server of the message. In a method, this object is 

also available through the pseudo variable server. 

message.receiver Returns the receiver of the message. 

message.isRecursive Returns true if the message is sent to self, server, or sender 

By sending the appropriate messages to the pseudo variable message, we can access the 

attributes of an active message. The attributes of a message include: 

• its selector; 

• its arguments; 

• the sender: the object which has sent the message; 

• the server: the object which has received the message first; 

• and its receiver: the object which has received the message at this moment. Initially, 

this attribute is the same as the server, but it becomes another object if a dispatch filter 

dispatches the message to that object. 

Recursive message An active message is defined as recursive if the message is sent to the pseudo variable self, 

server or sender. This is used by the default synchronization wait filter (page 41) to allow 

such messages to pass. 

The attributes of an active message can be retrieved, but they cannot be changed. The 

messages that can be sent to an instance of class ActiveMessage have been listed in 

appendix A.2, page 148. In table 10-1 however, we have indicated the messages often used 

to access the active message. 

10.3 Concurrency with threads 

A thread is a sequence of message executions. In <strong>Sina</strong>/st, any number of threads can be 

created and exist at the same time. In this way, messages (and methods) can execute 

concurrently. Note that more than one thread can be active —executing concurrently— 

inside the same object: there are two or more methods which have been invoked and which 

are executing. If this is not desired, the object must have defined mutual exclusion with the 

aid of an input wait filter 4 . 

4. The <strong>Sina</strong>/st compiler inserts by default for every class an input wait filter that realizes mutual exclusion (see 

section 6.1.3, page 41). The programmer can override this, and define a more complex synchronization 

scheme for the class or no synchronization at all. 


75

76 

Creating concurrency There are two occasions in which a new thread is created and started: 

• upon the invocation of an early return method (see section 7.6, page 50, for the 

difference between a normal and an early return method), 

• when a message is sent to an ACT, upon the reification of a message by a meta filter. 

A thread ends when the last message of that thread has been executed: it is the last 

message of either an early return method or of the ACT method. Note that if such a method 

contains an infinite loop, the thread will never finish. 

In diagrams, the start of a new thread is represented by the downward pointing triangle 

( ). The end of a thread is depicted by an upward pointing triangle ( ). 

The left diagram of figure 10-2 shows that a normal (non-early return) method is executed 

in the same thread: the message a.m1 is filtered and the method m1 is invoked. After 

method m1 has returned an object (return x), the next message (b.m2) is filtered and 

method m2 is invoked. 

The middle diagram shows the execution of an early return method m3. The message a.m3 

is filtered as usual. After the last filter, a dispatch filter, a new thread is created for the 

execution of method m3: The original thread is blocked until method m3 returns an object 

x. The message now has a reply and the blocked thread (the dashed line ) resumes by 

executing the next message, b.m4. After the method has returned a reply, the rest of m3 

(the messages following the return) is executed concurrently with the original thread, and 

thus with message b.m4. The new thread ends when the last message in the early return 

method m3 has been executed. 

FIGURE 10-2 Single thread (left) and new concurrent threads (middle and right). 

normal early return 

message 

method method reification 

a.m1 a.m3 a.m5 

m1 

D D 

A new thread is also be created upon the reification of a message by a meta filter (the right 

most diagram in figure 10-2). Message reification and dereification is explained in the next 

section. For now, we can see that the message act.mAct executes in the new thread 

concurrently with method m5 in the original thread. 


M 

act.mAct 

return x return x 

msg.continue 

b.m2 b.m4 

m2 

D 

Original Thread 

New Thread 

D 

m3 

m4 m5 

b.m6 

m6 

D 

return x 

D 

mAct 

D 

return y

10.4 Message reification and dereification 

Message reification is the process of converting an active message into a first-class object, 

a so called reified message. The opposite process is called dereification and converts a 

reified message back into an active message. Reification suspends the execution of a 

message, while dereification reactivates it. A reified message is an instance of the class 

<strong>Sina</strong>Message and, as we have seen in section 10.2, an active message is an instance of 

class ActiveMessage. 

The reification process takes place in a meta filter: if a meta filter accepts a message, it will 

reify the message. Then, the meta filters offers the reified message to an abstract 

communication type (ACT) object [Aksit93]. The ACT object is an arbitrary internal or 

external object, that is, it is an instance of some <strong>Sina</strong>/st class. 

A reified message will be reactivated if it receives one of the dereification messages 

continue, reply or send. The ACT object is responsible for sending one of these messages 

to the reified message (figure 10-3). 

FIGURE 10-3 Reification and dereification of a message. 

10.4.1 Message reification 

Reification of messages is realized in <strong>Sina</strong>/st by a meta filter. This is the only location 

where active messages can be reified. If an active message is accepted by a meta filter, it 

will be reified —become an instance of class <strong>Sina</strong>Message— and used as the single 

argument of a new message. The new message and its receiver (an ACT object) are 

specified as the substitution part of a filterelement in the filterinitializer of that meta filter. 

A new thread is created and then this message is sent to the ACT. The thread of the 

original, but now reified message is blocked until the ACT dereifies the message. 

We illustrate this with an example. Consider, for instance, the meta filter divcheck of the 

class NumericProcessor below. This class provides the standard arithmetic operations, 

such as addition, subtraction, multiplication and division. Division by zero for the divide 

and modulo operations is checked by the internal object divisionCheck. This object is an 

instance of class DivisionACT which we encounter later when we describe dereification. 

EXAMPLE 10-1 A class NumericProcessor interface 

internals divisionCheck : DivisionACT; 

methods 

add(n1, n2 : Number) returns Number; 

subtract(n1, n2 : Number) returns Number; 

multiply(n1, n2 : Number) returns Number; 

divide(n1, n2 : Number) returns Number; 

modulo(n1, n2 : Number) returns Number; 

inputfilters 

divcheck : Meta = { [divide]divisionCheck.divBy0, 

[modulo]divisionCheck.divBy0 }; 

calculate : Dispatch = { inner.* }; 

end; // NumericProcessor interface 

class NumericProcessor implementation 

methods 

add(n1, n2 : Number) begin return n1 + n2 end; 

subtract(n1, n2 : Number) begin return n1 - n2 end; 


ActiveMessage 

reification dereification 

meta filter ACT 

<strong>Sina</strong>Message 

• continue 

• reply 

• send 

77

78 

multiply(n1, n2 : Number) begin return n1 * n2 end; 

divide(n1, n2 : Number) begin return n1 / n2 end; 

modulo(n1, n2 : Number) begin return n1 mod n2 end; 

end; // NumericProcessor implementation 

The filter initializer of the meta filter divcheck has two filterelements which specify that 

only message with the selector divide and modulo is accepted and, consequently, reified. 

The substitutionpart of both elements define that, as a result, the message divBy0 is sent to 

the internal divisionCheck. 

EXAMPLE 10-1 B main 

temps 

aNumProc : NumericProcessor; 

result : Number; 

begin 

result := aNumProc.divide(3.0,2.0); 

result := aNumProc.divide(4.0,0.0); 

result := aNumProc.add(5.0, 6.0); 

end 

Figure 10-4 shows what happens upon the reification of the first divide message of the 

main method of example 10-1 B. The message which has 3.0 and 2.0 as arguments, is sent 

to the object aNumProc, an instance of class NumericProcessor. This active message is 

shown as aNumProc.divide( 3.0 , 2.0 ) in the diagram below. 

FIGURE 10-4 Reification of a message 

aNumProc.divide( 3.0 , 2.0 ) 

NumericProcessor::divide(n1,n2) 

1.5 

First, the message is filtered by aNumProc’s input filter divcheck. This meta filter accepts it 

and converts it to the reified message object aNumProc.divide( 3.0 , 2.0 ) , an instance of class 

<strong>Sina</strong>Message. This message object is the single argument of the message 

divisionCheck.divBy0( ) , which is executed in a newly created thread. The original thread 

is blocked until the reified message is dereified. The divisionCheck.divBy0( ) message is 

sent to the divisionCheck object and is filtered by its input filters as normal. As a result, 

DivisionACT’s method divBy0 is invoked which dereifies its argument msg, the message 

object aNumProc.divide( 3.0 , 2.0 ) . It turns into the active message aNumProc.divide( 3.0 , 2.0 ) 

again which then continues in NumericProcessor’s next filter, the dispatch filter calculate. 

This filter likewise accepts the message and after that, NumericProcessor’s method divide 

is invoked. This method eventually returns the Float object 1.5 as result of the message. 

10.4.2 Message dereification 

Reactivating a reified message —an instance of class <strong>Sina</strong>Message— is accomplished by 

sending an appropriate dereification message to it. There are three of such dereification 

messages which are all defined by the class <strong>Sina</strong>Message (see also section 10.5): 

• continue, which causes the reified message to be reactivated: it continues its normal 

course, that is, it is filtered by the filters following the reifying meta filter and 

eventually invoke a method which returns a value; 


divcheck 

calculate 

return n1/n2 


divisionCheck.divBy0( ) 

DivisionACT::divBy0(msg ) 

check

• reply(aReplyObject), which causes the message to become active again, and then 

provides aReplyObject as the return value of the message, just as if a method had been 

invoked that returned aReplyObject. In this case, the active message is not filtered by 

the filters following the reifying meta filter and no method is invoked; 

• send, which causes the message to be reactivated, like the continue message, except if 

the message has received a return value5 , the active message becomes reified again. 

Unlike continue, the dereification message send makes it possible to access the return 

value of the active message. 

After a send, the reified message must be reactivated again, either with a reply which 

can supply a different return value for the message, or with continue which does not 

change the return value of the message. 

EXAMPLE 10-1 C class DivisionACT interface 

comment 

’This class is an ACT that checks division operations of an instance 

of class NumericProcessor’; 

methods 

divBy0(msg : <strong>Sina</strong>Message) returns nil; 

inputfilters 

check : Dispatch = { inner.* }; 

end; // DivisionACT interface 

Dereification with 

continue 

class DivisionACT implementation 

methods 

divBy0(msg : <strong>Sina</strong>Message) 

temps NAN : Number basicNew; 

begin 

if msg.numArgs = 2 

then 

if msg.argsAt(2) = 0 

then msg.reply(NAN); return 

end 

end; 

msg.continue; return 

end; 

end; // DivisionACT implementation 

We continue with the NumericProcessor example to show the use of these dereification 

messages. Division by zero for its divide and modulo operations was checked by an 

instance of class DivisionACT (example 10-1 C). This class is provides the divBy0 method 

which is invoked after a divide or modulo message has been reified by NumericProcessor’s 

divcheck meta filter. This reified message is then passed as the argument msg to the divBy0 

method. Note that in the divBy0 method the pseudo variable message refers to the message 

divisionCheck.divBy0( ) sent by the meta filter, whereas the argument msg refers to the 

reified message. 

Now, let us follow the message aNumProc.divide( 3.0 , 2.0 ) from example 10-1 B inside the 

class DivisionACT. It has been reified to aNumProc.divide( 3.0 , 2.0 ) 

and now is the argument 

msg of the divBy0 method. This method checks if msg has two arguments and, if so, 

whether its second argument is zero. In this case, the second argument is 2.0 and therefore 

the divBy0 method dereifies the message by sending the continue message to it. As we can 

see in figure 10-5, it continues in the dispatch filter and invokes the divide method which 

calculates the result. After the divBy0 method has dereified the message, it executes the 

return statement. This ends the method and also the thread in the DivisionACT. However, 

the method could have done more operations between the message dereification and the 

5. The return value is normally supplied if a method has been invoked which then returns some object, but it 

could also have been provided by another reification followed by a dereifying reply message. 


79

80 

end of the method. Those actions would have been carried out concurrently with the 

dereified message. 

FIGURE 10-5 Dereification of a message with continue 


reply 



The divBy0 method also uses the message reply to dereify a message. If the second 

argument of the reified message is zero, DivisionACT has detected division by zero and will 

supply the Number object NAN —Not A Number— as reply of the message, instead of 

having the result calculated by NumericProcessor’s divide or modulo operation. The 

following figure shows the route of the second divide message of example 10-1 which has 

4.0 and 0.0 as arguments. Like the first message, the aNumProc.divide( 4.0 , 0.0 ) message is 

reified by the divisioncheck meta filter and becomes the argument msg of the divBy0 

method. Since the second argument of msg now is zero, the method supplies NAN as reply 

for the reified message aNumProc.divide( 4.0 , 0.0 ) . The execution of the now dereified 

message has finished because it has a received a return value: it has not been filtered by the 

NumericProcessor’s dispatch filter calculate and no method has been invoked. 

Subsequently, the add message (the third message of example 10-1 B) is executed. This 

message is not reified (it is rejected by the meta filter, since its selector is neither divide nor 

modulo), but invokes NumericProcessor’s add method at once. 

FIGURE 10-6 Dereification of a message with reply 


NAN 

aNumProc.add( 5.0 , 6.0 ) 

NumericProcessor::add(n1,n2) 

11.0 

1.5 

divcheck 

The third way of reactivating a reified message was by sending it a send message. We 

illustrate this dereification message with the class LoggingProcessor which offers the same 

functionality as the NumericProcessor class from example 10-1, but additionally logs 

every message it receives. Example 10-2 A shows the interface and implementation of this 

class. The logging of messages is taken care of by the internal logger which is an instance 

of class LogACT. This class is able to store messages and also provides the functionality to 

display them is. The meta filter log reifies every message and then present it to logger. The 

internal np provides the behavior of class NumericProcessor. With the dispatch filter disp 

its behavior is inherited as well as the behavior of class LogACT. Note that the 

implementation of class LoggingProcessor is empty because this class does not define 


divcheck 

calculate 

divcheck 

calculate 

return n1/n2 

return n1+n2 







check 

check 

msg.continue 

msg.reply(NAN)

functionality itself but only composes behavior from the classes NumericProcessor and 

LogACT. 

EXAMPLE 10-2 A class LoggingProcessor interface 

internals 

np : NumericProcessor; 

logger : LogACT; 

inputfilters 

log : Meta = {[*.*]logger.log}; 

disp : Dispatch = {np.*, logger.*}; 

end; // LoggingProcessor interface 

class LoggingProcessor implementation 

end; // LoggingProcessor implementation 

Example 10-2 B presents the class LogACT. This class logs messages by storing each 

reified message together with its return value in the instance variable loggedMessages. 

Every entry in this OrderedCollection is a two-element Array: the first element contains the 

message and the second element holds the return value of the message. The method 

showLog displays the logged messages. The log method stores its argument msg (a reified 

message) in a new entry. It then dereifies this message with send and waits until send 

returns the return value of the message. This return object is stored in the entry as well. At 

this point, the message again is reified and therefore has to be restarted with continue in 

order to return the return object to the sender of the message. Finally, the log method adds 

the entry to the loggedMessages. Both methods have been made available at the interface 

by the dispatch filter disp. 

EXAMPLE 10-2 B class LogACT interface 

methods 

log(msg : <strong>Sina</strong>Message) returns nil; 

showLog returns nil; 

inputfilters 


end; // LogACT interface 

EXAMPLE 10-2 C main 

temps 

class LogACT implementation 

instvars loggedMessages : OrderedCollection; 

methods 

log(msg : <strong>Sina</strong>Message) 

temps entry : Array(2); 

begin 

entry.at:put:(1,msg); 

entry.at:put:(2,msg.send); 

msg.continue; 

loggedMessages.add:(entry) 

end; 

showLog 

temps i : SmallInteger; entry: Array(2); 

begin 

for i := 1 to loggedMessages.size 

begin 

entry := loggedMessages.at:(i); 

self.print(entry.at:(1)); 

self.print(’ returned ’); 

self.printLine(entry.at:(2)) 

end; 

end 

end; // LogACT implementation 


81

82 


send 

aLogProc : LoggingProcessor; 


begin 

result := aLogProc.divide(3.0,2.0); 

result := aLogProc.divide(4.0,0.0); 

end 

We now illustrate the dereification message send with example 10-2 C. The trace of the 

messages in this main method is shown in figure 10-7. The first message 

aLogProc.divide( 3.0 , 2.0 ) is reified by LoggingProcessor’s meta filter log. The logger object 

gets control over the presently reified message aLogProc.divide( 3.0 , 2.0 ) and dereifies it 

with send. The thread in the logger blocks until the message receives a return value. The 

message continues in LoggingProcessor’s disp filter which dispatches it to the 

NumericProcessor instance np. There, the meta filter divcheck reifies the message a second 

time and offers it to the DivisionACT instance. Since the second argument of the message is 

not zero, the divisionCheck object decides to dereify it with continue. The message then 

continues in np’s dispatch filter calculate. This invokes the divide method which returns the 

Float instance 1.5 as result of the message. Because the message aLogProc.divide( 3.0 , 2.0 ) 

now has a return value, control is transferred back to the logger object which resumes its 

execution by returning the reply of that message, the object 1.5, as the result of the 

message send. The logger object stores this reply object and then dereifies the message 

aLogProc.divide( 3.0 , 2.0 ) with continue. At this point, the message returns with the Float 

object 1.5 in main and has finished its execution. 

FIGURE 10-7 Dereification of a message with send 

aLogProc.divide( 3.0 , 2.0 ) 


1.5 

1.5 


NAN 

NAN 

The second message of example 10-2 C, the message aLogProc.divide( 4.0 , 0.0 ) 

, follows up 

to the divisionCheck object the same course as the previous. This object however, 

discovers a division by zero condition and supplies the NAN object as result for the 

message. Since the message now has a return value, further filtering is canceled and 

control is transferred back to the logger object. This object resumes its execution, stores 


aLogProc.divide( 3.0 , 2.0) 

log 

logger.log( ) 

disp 

LogACT::log(msg ) 

disp 

divcheck 

calculate 

return n1/n2 

log 

disp 

divcheck 

logger.log( ) 


msg.send 



1.5 

msg.continue 

disp 

msg.send 


NAN 



msg.continue 


check 

msg.continue 


check 

msg.reply(NAN)

the reply object NAN and then dereifies the message aLogProc.divide( 4.0 , 0.0 ) 

with 

continue. The messages subsequently finishes in main by returning NAN. 

10.4.3 Multiple reifications 

During the filtering of a message, the message can be reified several times if it is accepted 

by different meta filters. In the previous section we have already encountered this: the two 

messages of example 10-2 were reified by LoggingProcessor’s log filter and then by 

NumericProcessor’s divcheck filter. 

ACTs that dereified a message with continue or reply do not regain control over the 

message when it receives a reply. With the dereification message send however, the ACT 

gains control over the reified message and its reply value as soon as the message receives a 

reply. This reply is either a result of a method invocation or supplied by another ACT with 

the dereification message reply. 

It is possible that several ACTs are waiting for the reply on a message because they all 

dereified the message with send. When the message receives a reply, the ACTs will gain 

control over the message in the reverse order in which they were invoked by respective 

meta filters. As soon as the message receives a reply, the ACT which was invoked last is 

the first to gain control over the message and its reply value. This ACT must dereify the 

message with continue or reply. Subsequently, the last but one ACT gains control over the 

message and its reply. This ACT then dereifies the message, and so on, until first ACT 

dereifies the message. 

The following example shows the effect of this. The class DemonProcessor extends the 

behavior of class LoggingProcessor by altering the return value of a message. The class 

DemonACT is responsible for this modification. The change method adds one to the result 

of a message only if this result is a Number. Otherwise, the result of the message is not 

changed (example 10-3 A). 

EXAMPLE 10-3 A class DemonACT interface 

externals 

Number : Class; 

methods 

change(msg : <strong>Sina</strong>Message) returns nil; 

inputfilters 

changeIt : Dispatch = {inner.*}; 

end; // DemonACT interface 

class DemonACT implementation 

methods 

change(msg : <strong>Sina</strong>Message) 

temps result : Any; 

begin 

result := msg.send; 

if result.class.inheritsFrom:(Number) 

then msg.reply(result+1) 

else msg.continue 

end 

end; 

end; // DemonACT implementation 

The class DemonProcessor composes the behavior of the class LoggingProcessor and the 

class DemonACT. A message sent to a DemonProcessor instance is logged with its correct 

result by the LoggingProcessor instance lp. If the result of the message is NAN, it is left 

unchanged, but if the result is a true number, the DemonACT instance demon adds one to it 

(example 10-3 B). 

EXAMPLE 10-3 B class DemonProcessor interface 


83

84 

internals 

demon : DemonACT; 

lp : LoggingProcessor; 

inputfilters 

demon : Meta = {[*.*]demon.change}; 

doit : Dispatch = {lp.*}; 

end; // DemonACT interface 

class DemonProcessor implementation 

end; // DemonProcessor implementation 

EXAMPLE 10-3 C main 

temps 

aDemProc : DemonProcessor; 


begin 

result := aDemProc.add(3.0,2.0) 

end; // main 

FIGURE 10-8 Multiple reifications 

aDemProc.add( 3.0 , 2.0 ) 

NumericProcessor::add(n1,n2) 

5.0 

6.0 

Figure 10-8 shows the flow of the message of example 10-3 C. The message 


is accepted by DemonProcessor’s first filter, the meta filter demon. 

The message is reified and offered to the DemonACT instance demon. This object sends 

the message which continues through aDemProc’s dispatch filter doit. This filter 

dispatches it to the LoggingProcessor instance lp. The meta filter log of this object reifies 

the message a second time and offers it to the LogACT instance logger. The logger object 

dereifies the message with send causing it to continue in dispatch filter disp, the meta filter 

divcheck (which does not reify the message) and the dispatch filter calculate. Then, 

NumericProcessor’s add method is invoked which returns the Float object 5.0 as result of 

the message. Since the message now has a reply, the control is transferred back to the 

logger object which was the last to send the message. The logger object logs the message 

and its return value 5.0 and reactivates the message with continue. The control will now be 



demon 

demon.change( ) 

disp 

DemonACT::change(msg ) 

doit 

log 

disp 

divcheck 

calculate 

return n1+n2 

msg.send 

5.0 

logger.log( ) 


msg.reply(result+1) 


disp 

msg.send 

5.0 

msg.continue

transferred back to the demon object because it was the previous object which sent the 

message (with send). This object changes the reply of the message to 6.0. As there are no 

other ACTs which have sent (send) the message, this result for the message is eventually 

returned in main. 

If an ACT sends one of the dereification message continue, reply or send to a message 

which it already had dereified with continue or reply, this is semantically incorrect 6 . This is 

because the ACT gives up the control on the message after it has sent continue or reply to 

it. With the dereification message send, the ACT gains control on the message once it 

receives a reply. After a send, the message must be dereified once more with continue or 

reply. A send followed by a send however, is also incorrect. In the current version of <strong>Sina</strong>/ 

st, version 3.00, sending one of the dereification messages continue, reply or send after a 

continue or reply has no effect. Neither has sending a send after a send. 

10.4.4 Writing ACT methods 

In this section we give some hints and tips on writing methods which handle reified 

messages. We call a method which handles a reified message an ACT method. An ACT 

object can be an instance of any class which can, apart from one or more ACT methods, 

have other methods as well. 

• an ACT method must have one and only one argument, declared as an instance of class 

<strong>Sina</strong>Message. This argument refers to the reified message; 

• the pseudo variable message in an ACT method refers to the message which was sent 

by the meta filter, while the argument of the method refers to the reified message; 

• it is important that message is dereified before ACT method finishes, because the 

message would otherwise remain reified forever. Thus, a message must be dereified 

with continue, reply or send, and after a send the message must be dereified a second 

time with continue or reply; 

• it is not necessary to do an early return in an ACT method, but 

• there is a possibility of deadlock if a message is dereified with send. If the thus 

dereified message does not return a value (for instance, through an infinite loop), the 

send in the ACT will wait on the return from the message forever. Further assume, that 

the ACT has protected its data with mutual exclusion by a wait filter (for instance, the 

defSync filter which is inserted by the compiler automatically). Since there is still a 

method active (viz. the ACT method), new messages to the ACT is blocked forever by 

the this wait filter. 

There is a solution for this. You can use an early return in the ACT method in order to 

‘free’ the ACT, but beware of protecting the data of the ACT that could be accessed 

after the early return. This could be solved by accessing the data of the ACT through 

self-calls. 

We could redesign the class from LogACT from example 10-2 B to prevent the deadlock 

situation from happening. The result has been presented in example 10-4. The log method 

now performs an early return and, after it has received the result of the reified message, it 

sends to itself the message logMessageAndReply. The corresponding method creates an 

entry for the message and its reply and stores this. 

EXAMPLE 10-4 class LogACT interface 

methods 

log(msg : <strong>Sina</strong>Message) returns nil; 

logMessageAndReply(msg : <strong>Sina</strong>Message; result : Any) returns nil; 

showLog returns nil; 

inputfilters 


6. To be more precise: it is semantically incorrect if in the same ACT thread, a message which was dereified 

with continue or reply, is dereified a second time. 


85

86 

end; // LogACT interface 

class LogACT implementation 

instvars loggedMessages : OrderedCollection; 

methods 

log(msg : <strong>Sina</strong>Message) 

temps result : Any; 

begin 

return; // early return 


msg.continue; 

self.logMessageAndReply(msg, result) 

end; 

logMessageAndReply(msg : <strong>Sina</strong>Message; result : Any) 

begin 

temps entry : Array with:with:(msg,result); 

begin 

loggedMessages.add:(entry) 

end; 

showLog // ... as in example 10-2 B 

end; // LogACT implementation 

10.5 The class <strong>Sina</strong>Message 

The class <strong>Sina</strong>Message describes a reified message, i.e. a first-class representation of a 

message. As we have seen in section 10.4.1, a meta filter creates an instance of this class if 

it reifies an active message. This reified message is called a suspended message, because it 

represents a message of which the execution has been suspended. Dereifying a suspended 

message reactivates the message. 

We can also create an instance of class <strong>Sina</strong>Message by declaring a variable of this class, 

or by copying another reified message. The reified message created in this way has not 

been active before and we call such a message an idle message. Dereifying an idle 

message activates the message for the first time. This means that the message actually is 

sent: it is filtered and eventually invokes a method. During filtering, some meta filter could 

reify the message again and suspend its execution. 

The attributes of a reified message are the same as those of an active message 

(section 10.2). They include its selector, arguments, sender, server and receiver. The 

attributes of an active message can only be retrieved, but if the message is reified, they can 

be modified too. The class <strong>Sina</strong>Message (appendix A.3, page 149) provides, in addition to 

the attributes accessing methods of class ActiveMessage (appendix A.2, page 148), also 

methods for changing, dereification and copying. They have been listed in the following 

table. 

TABLE 10-2 Accessing the reified message aMsg. 

aMsg.selector Returns a the selector of aMsg. 

aMsg.numArgs Returns the number of arguments of aMsg. 

aMsg.args Returns an Array containing the arguments. 

aMsg.argsAt(n) Returns the nth argument. 

aMsg.sender Returns the sender of aMsg. 

aMsg.server Returns the server of aMsg. 

aMsg.receiver Returns the receiver of aMsg. 

aMsg.setSelector(newSelector) Replace the selector by the String newSelector. 

Returns nil. 

aMsg.setArgs(argArray) Replace the argument by the Array object argArray. 

Returns nil. 

Chapter 10: Message passing semantics

TABLE 10-2 Accessing the reified message aMsg. 

aMsg.argsAtPut(n, newArg) Replace the nth argument by the object newArg. 

Returns nil. 

aMsg.setSender(newObj) Replace the sender by the object newObject. Returns 

nil. 

aMsg.setServer(newObj) Replace the server by the object newObject. Returns 

nil. 

aMsg.setReceiver(newObj) Replace the receiver by the object newObject. Returns 

nil. 

aMsg.copy Returns a copy of aMsg which has the same selector, 

server, receiver and arguments, but its sender is 

undefined (nil). 

aMsg.continue Dereify aMsg: it is activated for the first time if aMsg 

is an idle message, or reactivated if it is a suspended 

message. Returns nil. 

aMsg.fire Same as aMsg.continue: it (re)activates aMsg. 

aMsg.reply(anObject) Dereify aMsg and supply anObj as return value for the 

message. Returns nil. 

aMsg.send Dereify aMsg and wait until the message receives a 

reply. Returns this reply object. 

aMsg.sendContinue Same as aMsg.send; aMsg.continue 

If we send the dereification message send to a reified message, send will wait until the 

message receives a reply. The two other dereification messages continue and reply do not 

wait for a reply on the message. In <strong>Sina</strong>/st version 3.00 however, dereification of an idle 

message with continue does wait for the reply. 

Copying a reified message creates an new instance of class <strong>Sina</strong>Message which has the 

same selector, arguments, server and receiver as its origin, but its sender is undefined (nil). 

This instance is an idle message which can be made active by sending one of the 

dereification messages to it. 

A variable which has been declared as an instance of class <strong>Sina</strong>Message has all its 

attributes undefined (nil). Before dereifying —actually sending— this idle message, at 

least the selector, the arguments and its server must be assigned. The following example 

shows the usage of a <strong>Sina</strong>Message variable to create and send a message equivalent to 

3.0.divide(2.0). 

EXAMPLE 10-5 main 

temps 

msg : <strong>Sina</strong>Message; 

args : Array(1); 


begin 

// The following statements give the same answer as 

// result := 3.0.divide(2.0); 

msg.setSelector(’divide’); 

msg.setServer(3.0); 

args.at:put:(1,2.0); 

msg.setArgs(args); 


end 


87

88 

Chapter 10: Message passing semantics

PART 


iii Implementation of the <strong>Sina</strong>⁄st 

language 


11 Implementation 

Approach 

The previous part of this thesis, “Definition of the <strong>Sina</strong>⁄st language ”, described the syntax 

and semantics of the <strong>Sina</strong>⁄st language. In this part we describe the <strong>Sina</strong>⁄st implementation 

which includes a programming environment consisting of a user interface, a compiler and 

a kernel. As <strong>Sina</strong>⁄st incorporates the composition filters object model, the implementation 

can be used to demonstrate the advantages of this model over the conventional objectoriented 

model. The <strong>Sina</strong>⁄st implementation further can be used to verify several projects 

which use the composition filters object model to describe their design ([Tekinerdogan94], 

[Algra94], [Vuijst94], and [Marcelloni95]). 

The object-oriented language Smalltalk [Goldberg83], and the Objectworks\Smalltalk 

development environment [ParcPlace92] have been used to implement the <strong>Sina</strong>⁄st 

language. This decision was made because Smalltalk allows rapid prototype development, 

it has a user friendly programming environment, and it comes with an extensive class 

library. Smalltalk further offers computational reflection [Maes87] [Ferber89] which 

means that it is possible to access the structure of each object (especially its methods) and 

the way it handles messages. For the implementation this is very useful, for instance to 

invoke a certain method directly. Finally, Smalltalk provides us with the basic entities 

(processes, semaphores, etc.) to implement concurrency and synchronization. 

This chapter describes the outline of the implementation. Section 11.1 identifies the 

implementation problems, while section 11.2 describes the implementation approach. The 

last section gives an overview of the implementation. 

11.1 Problem statement 

In the previous part of this thesis (part II, “Definition of the <strong>Sina</strong>⁄st language ”), we have 

described the <strong>Sina</strong>⁄st language, its syntax, and semantics. <strong>Sina</strong>⁄st has many features 

common to other object-oriented languages. It provides classes and objects, encapsulation, 

and inheritance and delegation. Polymorphic message passing is the basic mechanism to 

express executions in <strong>Sina</strong>⁄st . 

However, there are major differences with programming languages which adopt the 

conventional object-oriented model. The composition filters object model incorporated by 

<strong>Sina</strong>⁄st offers some advantageous features which require a different approach to its 

implementation. The source of these differences lies in the message passing semantics of 

the composition filters object model. 


91

92 

Message passing in the composition filters object model, as many object-oriented 

languages, follows the request/reply model: after a client object has sent a message —the 

request— to a server object, the client must wait until it receives a return value —the 

reply— from the server object. The message is a request from the client to carry out one of 

the operations provided by the server. The server decides whether it can execute the 

request, and which operation (method) corresponds to the message. Alternatively, the 

server can delegate the request to another object. This decision process is generally known 

as method lookup. If an appropriate method has been found, it is invoked and its result 

returned to the client object. 

In class based object-oriented languages, such as Smalltalk and C++ [Ellis90], the method 

lookup process considers the inheritance hierarchy to search for a method corresponding to 

the received message. First, the it checks if the class of the server object has defined such a 

method. If this is not the case, its superclass will be consulted, etcetera, until an 

appropriate method has been found. Similarly, the delegation structure is searched for a 

matching method in delegation based languages, such as SELF [Ungar87]. 

Filters In the composition filters object model adopted by <strong>Sina</strong>⁄st , the method lookup process is 

carried out by filters. If a client object sends a message to a server object, it will be filtered 

by several filters before eventually a method is invoked. A filter can delay a message (wait 

filter), abort a message (error filter), reify and then offer a message to a designated object 

(meta filter), or offer the message to another object for further filtering or method 

invocation (dispatch filter). Based on the message (typically its selector), and on 

conditions specified in the filter, the filter either carries out its predefined action on the 

message, or offers it to the next filter. Conditions provide information on the context of the 

message (typically its sender), and state of its receiver. By using filters, the concepts of 

inheritance, delegation, synchronization, and reflection on message communication can be 

realized. 

Reflection on messages There are two aspects of this filtering process which make the message passing semantics 

different from that of conventional object-oriented languages. Firstly, during the filtering 

of a message, several objects must reflect on the message. This means that they manipulate 

the message and access its attributes (selector, arguments, etc.). At system level, a filter 

and its associated conditions access the attributes of a message in order to decide to accept 

or reject it. On application level, arbitrary objects (abstract communication types) may 

manipulate a reified message by changing its attributes or dereifying it. 

Dynamic filtering 

process 

Secondly, the filtering process is of a very dynamic nature, as conditions, reflecting the 

context of the message and state of its receiver, are used by filters to decide whether to 

accept or reject a message. The context of the message can differ from message to 

message, while the state of an object can change from one moment to another. This makes 

it possible that a message which is accepted at one moment by a filter, is rejected by it at 

another moment, or vice versa. With this dynamicity, the composition filters object model 

realizes dynamic inheritance and delegation (dispatch filter), synchronization (wait filter), 

and multiple views (error filter), which are concepts of dynamic nature. 

The implementation of <strong>Sina</strong>⁄st must take these two aspects into account. Further, the 

implementation also must consider two other important features of the composition filters 

object model, concurrency and synchronization. 

Concurrency In the composition filters object model, several activities can be executed concurrently. In 

<strong>Sina</strong>⁄st these activities are called threads, which are in fact sequences of message sends. A 

new thread is created upon the invocation of an early return method, or when a message is 

reified by a meta filter and offered to an ACT object (see chapter 10). The implementation 

must realize these concurrent threads. 

Synchronization Wait filters can be used by a composition filters object to synchronize concurrent threads. 

A wait filter delays a message until designated conditions have been met. This means that 

the thread of the message is blocked, and that the conditions must be monitored to see if 

Chapter 11: Implementation Approach

<strong>Sina</strong>⁄st language 

elements 

Programming 

environment 

the message is allowed to continue. The implementation must realize this by using lower 

level constructs available in the implementation environment. 

The “Definition of the <strong>Sina</strong>⁄st language ” (part II) shows that the primary language elements 

of <strong>Sina</strong>⁄st are classes, objects, messages, filters, conditions, methods, and messages. A 

class abstracts and groups objects according to their common behavior. An object 

encapsulates other objects (internals and instance variables), and provides methods which 

can be carried out in response to messages. The filters of an object, together with 

conditions, determine how it responds to messages. The implementation must realize these 

elements and preserve the semantics among them. 

For the automatic translation of <strong>Sina</strong>⁄st to Smalltalk, the implementation must provide a 

compiler which compiles <strong>Sina</strong>⁄st source code to executable code. The compiler is part of 

the <strong>Sina</strong>⁄st programming environment which is further comprised of a user interface, and a 

kernel. The user interface allows us to edit, compile and execute <strong>Sina</strong>⁄st applications. The 

kernel provides run-time support, and a set of predefined classes. The extensive class 

library of Smalltalk can be used in a <strong>Sina</strong>⁄st application. 

As we have chosen Smalltalk as the implementation language and environment, we must 

map the <strong>Sina</strong>⁄st semantics and language elements onto Smalltalk. Smalltalk provides the 

basic means to accomplish this: it is an object-oriented language with classes, objects and 

methods, offers computational reflection 1 , and comes with the classes to realize 

synchronization and concurrency. Due to Smalltalk’s different message passing semantics, 

implementing <strong>Sina</strong>⁄st is not less trivial however. 

Summarizing, the implementation of the <strong>Sina</strong>⁄st language must address the following 

aspects: 

• mapping of <strong>Sina</strong>⁄st language elements and semantics on Smalltalk; 

• representation of filters and the filtering process; 

• reflection on messages; 

• dynamic nature of the filtering process; 

• concurrency with threads; 

• synchronization with the wait filter; 

• programming environment, including a compiler, user interface and run-time kernel. 

11.2 Approach 

In the following chapters of this thesis we describe how the implementation of <strong>Sina</strong>⁄st can 

be realized. First, we define the execution model which describes run-time aspects of 

<strong>Sina</strong>⁄st . It addresses the message passing semantics, and concurrency and synchronization. 

The design includes the representation of messages, the filtering process, the 

representation of filters, how methods are invoked, and message reification and 

dereification. The execution model is described in the following chapter. 

Chapter 13 defines the translation model. This describes the mapping of <strong>Sina</strong>⁄st language 

elements to Smalltalk entities. Basically it shows how a <strong>Sina</strong>⁄st object with externals, 

internals, instance variables, filters, conditions, and methods, is represented in Smalltalk. 

This static model is used by the compiler for the automatic translation of <strong>Sina</strong>⁄st source 

code in executable Smalltalk code. 

Finally, chapter 14 details the programming environment. It describes the compiler, which 

uses the translation model of the previous chapter, the user interface, and the kernel. 

1. As described in the introduction of this chapter, this means that it is possible to access the structure of each 

object and the way it handles messages. 


93

94 

Graphical notation in 

forthcoming chapters 

Although performance and memory space are important for the practical use of 

programming languages, in this thesis we do not focus on efficiency but on ways how to 

implement one another. That does not mean we forget it completely: we will address the 

efficiency of some elements in the implementation, and, where possible, give hints on how 

to improve it. 

In the forthcoming chapters, we use a notation similar to OMT [Rumbaugh91] to denote 

structural relations in object diagrams. Figure 11-1 explains the elements that can be 

encountered in such diagrams. 

FIGURE 11-1 Legend for object diagrams 

Class 

Name 

Library Class 

Multiplicity of associations 

exactly one 

optional (zero or one) 

one or more 

11.3 Overview of the implementation 

The implementation provides a compiler which translates a user defined <strong>Sina</strong>⁄st object (a 

composition filters object) to a Smalltalk object (figure 11-2). The compiler employs the 

excution model and the translation model that are described in the following chapters. The 

translated Smalltalk object inherits from the class Abstract<strong>Sina</strong>Object which 

provides common behavior for all compiled <strong>Sina</strong>⁄st objects. The translated Smalltalk 

object is further composed of objects representing its filters, object manager, methods, etc. 

These objects are also provided as kernel classes. 

FIGURE 11-2 Overview of the implementation 

Class with 

specified attributes 

and operations 

Name 

attributes 

operations 

¤ class operations 

Chapter 11: Implementation Approach 

n 

m-n 

kernel objects 

Compiler 

Inheritance Aggregation 

SuperClass 

SubClass 

many (zero or more) 

exactly n 

m to n 

Abstract<strong>Sina</strong>Object 

user defined 

<strong>Sina</strong>/st object 

Execution Translation 

translated 

Smalltalk 

object 

Model Model 

Whole 

Part

12 Execution Model 

This chapter describes the execution model for <strong>Sina</strong>⁄st . The execution model describes 

how different entities behave at execution time (run-time). Messages are the basic entities 

involved in the execution of a <strong>Sina</strong>⁄st application. When an object (the sender) sends a 

message to some receiver object, the message is filtered by several filters and, in general, 

invokes a method. The method executes and returns a reply object to the sender. As 

described in chapter 10, during the filtering process, a message can be reified by a meta 

filter, or delayed (synchronized) by a wait filter. 

Figure 12-1 shows an interaction diagram of the message execution. Similar diagrams will 

be used in this chapter to describe the implementation. It displays the interaction between 

various (Smalltalk) objects involved in (<strong>Sina</strong>⁄st ) message execution. In such a diagram, 

time increases towards the bottom. The thick line on the left represents the message thread 

which only indicates if it is suspended (dashed line), or not (solid line). A horizontal solid 

arrow indicates a request (Smalltalk message send) from the originator to the destination 

object. The label of this arrow represents the request (method name). An open arrow 

denotes the return from the request. If appropriate, the label of this arrow shows the object 

returned. 

FIGURE 12-1 Interaction diagram of message sending and filtering, and method invocation 

message 

thread sender message filter 

receiver 

method 

sending 

We start this chapter by giving an overview of message execution. Then, we describe the 

implementation by following a message from the moment its is sent (section 12.2), when it 

is filtered (section 12.3) by several filter handlers (section 12.4), to the moment of method 

invocation (section 12.5). Section 12.6 describes the reification and dereification of 

messages, while section 12.7 explains the synchronization of messages. Finally, 

section 12.8 details how Smalltalk objects can understand <strong>Sina</strong>⁄st messages. 


filtering 

reply object 

invocation 

95

96 

12.1 Overview of message execution 

During message execution, filters and conditions must reflect on active messages (system 

level reflection), while abstract communication type objects must reflect on reified 

messages (application level reflection). Therefore, we must design an implementation 

which allows this. 

Message We cannot use the message passing semantics of Smalltalk, because it does not allow to 

reflect on messages easily. We therefore use a Smalltalk object to represent a <strong>Sina</strong>⁄st 

message. The following section describes this. 

Object A <strong>Sina</strong>⁄st object can be mapped to a Smalltalk object. For client objects, this object is a 

black box whose only task is to respond to a received message and return a reply object. 

The receiver encapsulates its internal structure and how it handles the received message. A 

<strong>Sina</strong>⁄st object —a composition filters object— reacts to a received message by passing it 

through its input filters. The mapping of a composition filters object to a Smalltalk object 

takes the same black box approach, as is shown by figure 12-1. 

In order to respond to (<strong>Sina</strong>⁄st ) messages, the object needs only two entry points which are 

inputMessage: and signatureIncludes:. The third entry point 

outputMessage: is private to the object. The first is used by client objects to direct a 

message to, while the second is used to check whether the object supports a message 

(signature matching). 

FIGURE 12-2 Entry points of a composition filters object in Smalltalk 

message 

The entry point called outputMessage: is the gate to the output filters and is 

represented in the translated object by a corresponding method. It is only used by the 

object itself when it sends a message that has to pass the output filters. The entry point 

inputMessage: is the gate to the input filters and also corresponds to a method. Every 

filter in the input filter group or output filter group has an entry point called filter: 

which is used to filter a message. A message passing through a filter group is offered to 

each filter through this entry point. A filter (dispatch filter) may decide that the message 

must be offered to another object (internal or external), which means that it is presented to 

the inputMessage: entry point of that object. Alternatively, a method of the object is 

invoked if the message is dispatched to inner. 

Thread A thread is a sequence of actions (messages) which can execute concurrently with other 

threads. A thread is mapped to a Smalltalk Process. A new Process can be created by 

forking a Smalltalk block closure. This is a sequence of statements between brackets []. 

A Smalltalk Process is a non-preemptive process, which means that it occupies 

Smalltalk’s (virtual) Processor until the process explicitly gives it up. Another process 

must wait until the running process is terminated, becomes suspended, or takes itself of the 

processor. Because in <strong>Sina</strong>⁄st new threads (processes) are created often, we have designed 

a preemptive process scheduler which gives each process frequently a little amount of time 

to run on the Processor. The preemptive process scheduler is part of the <strong>Sina</strong>⁄st kernel and 

will be described in chapter 14. 

Chapter 12: Execution Model 

filter: 

inputMessage: 

signatureIncludes: 

outputMessage:

12.2 Representation of an active message 

An active message represents a message that is executing. This means that it is being 

filtered, or that it has invoked a method. The attributes of an active message include: 

• its selector: determines which operation is requested; 

• its arguments: an array of zero or more objects; 

• its sender: the object that has sent the message; 

• its server: the object to which the message was sent by the sender, i.e. it is the first 

receiver; 

• its receiver: the object that is currently the receiver of the message, i.e. which is 

currently filtering the message. 

FIGURE 12-3 Active message 

selector 

args 

MessageSend 

receiver 

Message 

If an object sends a message, it must be offered either to the output filters of this sender 

object, or to the input filters of the server object. This depends on whether the server object 

is encapsulated by the sender object, or not. In the first case, the message does not have to 

“cross the encapsulation boundary of the sender object”, and can be offered to the input 

filters of the server directly. These kind of messages are messages sent to a constant, to an 

internal or instance variable of an object, or to a local variable of a method. A message that 

is sent to an external of an object must first pass the output filters of the sender object 1 . The 

choice between those two cannot always be made at compile time. Consider for example 

the message expression 

x.foo.bar 

in which the message bar is sent to the result object of the message foo, which is sent to the 

object x. At compile time, it is known whether x is an external or not, and the choice to 

offer the message foo to input or output filters can be made. However, for the result of this 

message, a so called intermediate object, this is not known, and this decision for message 

bar must be deferred to run-time. However, in this version of <strong>Sina</strong>⁄st , version 3.00, this is 

not implemented yet. Messages to intermediate objects will not pass the output filters of 

the sender, but go straight to the input filters of the object. 

A decision which always can be made statically is whether a message is recursive or not. A 

recursive message is defined as a message to self, server, or sender (chapter 10). 

Ideally, <strong>Sina</strong>⁄st message sending should be carried out by Smalltalk message sending. 

However, this is not possible, since the virtual machine of Smalltalk takes control of it 

once the message has been sent: it performs method lookup in the class hierarchy and 

invokes a corresponding method. Because filters (and later other objects) must be able to 

reflect on messages, we use a first-class representation of the message. Smalltalk already 

1. A send filter in the output filter group ensures that the message is filtered by output filters of all the 

encapsulating objects, starting from filters of the sender to those of the object which encapsulates the target 

of the message. After this, the message is offered to the input filters of the target of the message. 


ActiveMessage 

sender 

server 

replyBlock 

from:to:deliver:arg:* 

from:to:send:arg:* 

replyValue: 

isRecursive 

¤ from:to:deliver:arg:* 

¤ from:to:send:arg:* 

Recursive- 

ActiveMessage 

isRecursive 

97

98 

provides two classes, Message and MessageSend, to represent such a message 2 . They 

have selector, arguments and receiver as attributes. The class 

RecursiveActiveMessage, representing a recursive message, is made a subclass of 

class ActiveMessage which is a subclass of MessageSend (figure 12-3). The 

RecursiveActiveMessage differs from class ActiveMessage only by overriding 

the isRecursive method. In the class ActiveMessage it returns false, while in its 

subclass it returns true. 

FIGURE 12-4 Interaction diagram of message sending 

Sending an active 

message 

Figure 12-4 shows the interaction diagram of message sending. There is a difference 

between messages which have to pass the output filters of the sender first, and messages 

which are offered to the input filters of the server directly. For this, class 

ActiveMessage provides two sets of instance methods. In both groups, methods are 

available for different number of (<strong>Sina</strong>⁄st ) arguments: a separate method for active 

messages with zero to four arguments, and a common method for active messages with 

more than four arguments. Each of these methods returns the object which is the result of 

the active message. The group with the selectors from:to:deliver:arg:* offers the 

message directly to the input filters of the server ( 1 ), while the from:to:send:arg:* 

method group offers the message to the output filters of the sender object ( 5 ). 

The methods in the two groups are very similar. Let us consider the following 

ActiveMessage>>from:to:send:arg:arg: method as an example for the 

methods in both groups. It is the send method for an active message which has two 

arguments, and which must pass the output filters of the sender. 

EXAMPLE 12-1A ActiveMessage>>from: sendr to: target send: selec arg: arg1 

arg: arg2 

sender := sendr. 

server := target. 

receiver := target. 

selector := selec. 

args := Array with: sender with: server with: arg1 

with: arg2. 

replyBlock := [:value|^value]. 

6 

sender outputMessage: self. 

^nil 

The pseudo variables 

sender, server and self 

message 

thread 

sender 

¤from:to:deliver: 

The sender of the message is the object that has received the message first. In <strong>Sina</strong>⁄st this 

object is referred to by the pseudo variable server. The pseudo variable self refers to the 

2. In Smalltalk a message is represented by a first-class object whenever the method lookup fails. This message 

object is passed as an argument to the doesNotUnderstand: message which is sent subsequently to the 

original receiver of the message. 


1 

5 

ActiveMessage output filters server input filters 

from:to:deliver: 

reply 4 3 

¤from:to:send: 

from:to:send: 

6 outputMessage: 

filtering 

2 

inputMessage: 

replyValue:reply 

inputMessage: 

filtering 

invocation 

reply 

method

object that currently received the method. The pseudo variable self can be mapped to the 

Smalltalk’s pseudo variable self. The pseudo variable server is mapped to a variable 

called server which is passed to the invoked method (see below). The first argument of 

the method above therefore is always be server. The second argument of the method, 

the target of the message, is as it appears in <strong>Sina</strong>⁄st source code: it can be an constant 

object, an external, internal, instance variable of an object, a local variable of a method, or 

the result of another active message. 

One thing to be noted the message send method of in example 12-1A is that the sender and 

server of the message are passed as arguments to this method, and stored in the active 

message. The question arises whether this is always needed, or that they could be retrieved 

from the context of the message. Ideally, the sender and server should only be stored if 

they are needed, i.e. if they are referred to in a method, or accessed by an ACT object. 

However, this cannot be determined at compile-time, as for instance, a message might be 

reified and offered to an ACT object which accesses the sender of the message at one time, 

while an identical message bypasses the ACT at another time. Therefore, they are always 

captured. Since Smalltalk does not have a direct equivalent of sender and server, we 

retrieve them when they are known, at the moment of the message send. It would be 

possible to retrieve them by using Smalltalk’s pseudo variable thisContext. This 

variable refers to context of the currently activated (Smalltalk) method through which the 

stack of activated methods can be accessed. However, this requires a complicated travel 

through the stack of contexts, because the stack not only consists of compiled <strong>Sina</strong>⁄st 

methods but also methods involved in the message filtering process. 

Another thing we can see in the message sending method of example 12-1A is that both the 

sender and the server are stored two times: once in the respective attributes, and then again 

in the array of arguments. The latter we have chosen because both the server and the 

sender are passed as parameter to the corresponding method. To invoke the method, the 

sender, server, and <strong>Sina</strong>⁄st arguments are packed in one array and passed as the Smalltalk 

arguments to the method (see section 12.5). By creating an array containing all these 

objects at this moment instead of adding them upon method invocation to an array 

containing only the <strong>Sina</strong>⁄st arguments, we avoid the copying and creation of a new array 

instance. By storing the sender and server also in separate attributes, these can be accessed 

faster when they are retrieved. The methods that change the attributes (sender: and 

server:) will both update the attribute and the corresponding entry in the args array. If 

performance studies would show that most applications do not access the sender or server 

attributes of an active message, the attributes sender and server could be omitted, and 

be stored in the args array only. 

Returning a value The attribute replyBlock of an ActiveMessage is initialized in the message sending 

method with a block closure (the statements between the brackets []). When this block is 

executed, it returns its argument (value) as result of the from:to:send:arg:* 

method. This effectively returns value as reply object of the active message. The block 

closure is executed by the ActiveMessage>>replyValue: method, which is called 

if there is a reply available for the message, such as when an invoked method returns an 

object (marked with 3 in figure 12-4), or a reply is supplied by an ACT. By using the 

block closure, we can bypass the returns of several (Smalltalk) methods which were 

invoked during the filtering process of the message. These invoked methods form a stack 

of activated contexts3 . Instead of breaking this stack down one by one by returning from 

each of these invoked methods normally, it is broken down to the context of the 

from:to:send:arg:* method immediately when the replyBlock is executed 

(marked with 4 

in figure 12-4). 

The replyBlock attribute is further used by message reification/dereification, in which 

case it is replaced by another block closure which intercepts the reply of the message once 

it becomes available (see section 12.6). The replyBlock can be seen as a return address 

3. The context stack holds the state of execution. The invocation of a method adds a new context to the top of 

the stack, while one is removed when a method finishes. 


99

100 

Offering an active 

message to the filters 

as it would appear in an activation record during the execution of imperative languages. A 

return address is the address where the execution continues when the procedure has 

finished. The returnBlock block closure is similar: the execution continues after the 

call of the from:to:send:arg:* method. 

After the replyBlock has been initialized, the message must be offered to the input or 

output filters (in figure 12-4 marked with 2 and 6 

). For this, a translated <strong>Sina</strong>⁄st object 

has two methods inputMessage: and outputMessage: which pass their argument, 

an ActiveMessage instance, to its input filters and output filters, respectively. 

The last line of the method of example 12-1A (^nil) is placed as a safeguard. It should 

never be executed, however, because a return from an active message is implemented by 

the calling the replyValue: method which executes the replyBlock block closure. 

Selector of a message The selector of an active message is an instance of the Smalltalk class Symbol which is 

an efficient implementation of a string. The selector is a sequence of alphanumeric 

characters equivalent to its appearance in the <strong>Sina</strong>⁄st source code. It is equivalent to the 

selectors which are used by the filters in the filtering process. It would have been 

convenient if we could have used the same selector as the Smalltalk selector of the method 

to be invoked eventually. Such a selector contains as much sub-keywords as there are 

arguments in the method (see for instance the selector of the method of example 12-1A). 

This would require the number of arguments to be known at compile-time which is not 

always the case. The chosen selector representation also allows easy comparison of the 

selector of the message during the filtering process, and simple replacement of a selector. 

Creating and sending an 

active message 

As we have argued in the beginning of this section, every message is represented by a firstclass 

object. This means that every message which appears in the source code must be 

created and then sent. Similar to the two groups of instance methods, the class 

ActiveMessage provides two groups of class methods, from:to:deliver:arg:* 

and from:to:send:arg:* that correspond to the aforementioned two groups of 

instance methods. These methods first create an ActiveMessage instance. They 

subsequently send it, by calling the corresponding instance method, and return the object 

replied by the message. Example 12-1 B shows the class method corresponding to 

example 12-1A. 

EXAMPLE 12-1 B ActiveMessage class>>from: sendr to: target send: selec arg: 

arg1 arg: arg2 

^self basicNew 

from: sendr 

to: target 

send: selec 

arg: arg1 

arg: arg2 

We will now give an example of how <strong>Sina</strong>⁄st messages are converted to Smalltalk. 

Consider the following message expression: 

EXAMPLE 12-2 A Tarzan.age.less(40); // Tarzan.age < 40 

The message age is sent to the object Tarzan. Then, the message less is sent to the object 

resulting from the first message. Assuming that Tarzan is an internal (meaning that the 

message then does not have to pass the output filters), this is translated to Smalltalk as: 

EXAMPLE 12-2 B ActiveMessage 

from: self 

to: (ActiveMessage 

from: self 

to: Tarzan 

Chapter 12: Execution Model

deliver: #age) 

deliver: #less 

arg: 40. 

As we see, the target of the less message is the result of the first message, the age 

message. The compiler correctly generates Smalltalk code for more complex situations, 

for instance if the arguments are also message expressions. 

12.3 Filtering a message 

The filtering of a message is carried out by individual filters, which are organized in 

groups of input filters and output filters. In this section we first describe the filtering of a 

message by a group of filters, and subsequently by each individual filter. 

12.3.1 Message handling by a filter group 

The filtering of a message in a group of filters is mutual exclusive, which means that if 

there is a message being filtered by the filter group, messages that want to enter the group 

to be filtered must wait until the currently evaluating message leaves the group. This 

ensures that not more than one message gets accepted when they access a condition. 

Messages must pass the filter group in the order in which they arrive. 

A message can leave the filter group for good, or only temporarily. The former is the case 

if the message is offered to another object (possibly inner) by a dispatch or send filter, or if 

the message is aborted by an error filter. The message can temporarily leave the group 

when its is delayed by a wait filter, or reified by a meta filter. Once the message is restarted 

or dereified, it must continue through the rest of the filters by reentering the filter group. 

However, if at this moment another message already occupies the group, the message must 

wait until the group is free. Because a reentering message was already evaluating in the 

filter group, it arrived before messages which are waiting to enter the filter group for the 

first time. To guarantee the ordering of the messages, these reentering messages have 

priority over those which want to enter group for the first time. 

This could be implemented by two queues Q1 and Q2 which store messages that want to 

enter the filter group for the first time, and messages that want to reenter the group, 

respectively. If a message that wants to enter a filter group for the first time finds that there 

is no message being filtered by the group, it can enter the group immediately. Otherwise it 

has to wait in Q1. If a message that wants to reenter the group (because the conditions in a 

wait filter were met, or it was dereified) finds the group unoccupied, it can enter 

immediately, otherwise it must wait in Q2. 

When a message leaves a group (either temporarily or definitely), it must trigger a 

following message to enter the group. It must first check if the queue Q2 contains 

messages, since these reentering message have priority over the messages of queue Q1. 

Since this would require the checking two queues, we have combined them into a single 

queue. The class MessageQueue implements a single message queue with a priority 

part. Messages are always taken from the head of the queue. In the priority part (at the 

front of the queue) messages are added that want to reenter the filter group. Messages that 

want to enter for the first time are added to the tail of the queue. If the priority part is 


101

102 

empty, i.e. if there are no messages that want to reenter the filter group, messages are 

automatically taken from the second part of the queue. 

FIGURE 12-5 Messages entering a filter group 

priority part 

MessageQueue 

Figure 12-5 shows a MessageQueue (a) and an example of the working of it (b-h). 

Message 2 must wait in the message queue because message 1 is occupying the group (b). 

When message 1 has left the filter group, message 2 enters the filter group, while messages 

3 and 4, which arrived in the mean time, must wait (c). Then, because message 2 is 

blocked by the first filter, it temporarily leaves the group, and as a result message 3 enters 

the group (d). Message 3 continues in the next filter, and due to some other event, message 

2 is restarted again, and must wait in priority part of the queue as it tries to renter the group 

(e). When message 3 leaves the input filter group (temporarily in this case), message 2 

enters the group and continues with the second filter (f). Then, message 2 is blocked for a 

second time, leaves the filter group, and triggers message 4 to enter it. After this, message 

3 is again restarted and entered in the priority part of the queue (g). While message 4 

continues in the following filter, message 2 is restarted again and entered in the priority 

part of the queue. 

Now let us have a closer look on how the input filter group and output filter group are 

represented in a compiled user defined object. As we have said earlier, every user defined 

object inherits from the class Abstract<strong>Sina</strong>Object which provides operations 

common to all translated <strong>Sina</strong>⁄st objects. We do not explicitly model the input or output 

filters group as a separate object, but since every user defined object has its own separate 

set of filters, they are represented as instance variables (part of) the user defined object (see 

figure 12-6). 

FIGURE 12-6 Object diagram of message filtering 

filter: 

Each of the two filter groups has a message queue to store messages hold messages as 

described above. Since they are always there, they are part of Abstract<strong>Sina</strong>Object. 

This class also provides methods to enter a group of filters for the first time 


4 

4 

2 3 

4 2 

1 2 3 

5 

4 

3 2 

filter group 

2 

3 2 

(a) (b) (c) (d) (e) (f) (g) (h) 

Filter 


enterInput: 

enterInputAgain: 

leaveInput 

enterOutput: 

enterOuputAgain: 

leaveOutput 

UserDefinedObject 

inputMessage: 

outputMessage: 

filters→ 

6 

5 

3 

4 

2 

MessageQueue 

ActiveMessage 

semaphore 

wait 

signal 

stores↓ 

6 

5 

2 

3 

4

(enterInput: and enterOutput:), to reenter the group (enterInputAgain: 

and enterOutputAgain:), or to leave the group (leaveInput and 

leaveOutput). The first four methods take an active message as an argument. They 

block the message as described above. The leaveInput and leaveOutput methods 

of Abstract<strong>Sina</strong>Object must trigger the next message to enter the filter group by 

signalling the first message, if any, in the input or output filters queue. 

To block an active message, the class ActiveMessage has a semaphore attribute 

which is an instance of class Semaphore. The two methods wait and signal block 

and restart the message, respectively. A semaphore works like this: if it has not received a 

signal when it receives a wait, the thread (process) that sent this wait is suspended 

until a signal is received. Suspending the thread thus blocks the active message. Note 

that blocking an active message always happens within the active message thread itself, 

but its release is carried out by another thread. The semaphore of ActiveMessage, and 

associated methods are also used to block a message for synchronization by a wait filter, 

and during its reification by a meta filter. 

The user defined object has the methods inputMessage: and outputMessage: 

which are the ports to the input and output filter group. They are called when an active 

message must be filtered by the input filters or output filters of the object. Their task is to 

pass the argument message through each filter in the group. Every user defined object has 

its own specific set of filters which are appear as instance variables of the user defined 

object. Because these methods depend on these filters, they are generated by the compiler. 

EXAMPLE 12-3 UserDefinedObject>>inputMessage: anActiveMessage 

self enterInput: anActiveMessage. 

(inputf1 filter: anActiveMessage) ifFalse: [ 



... ifFalse: [ 

self leaveInput. 

Filter inputFiltersErrorSignal raise] ...]]] 

The general structure of the inputMessage: method is shown in example 12-3, with 

the outputMessage: method being very similar to that. The message mutual 

exclusively enters the input filters group with the enterInput: method. Then, the 

message is offered to each of the input filters in turn by calling the filter: method of 

the respective filters. As we will see in the next section, this method returns false if the 

message must be processed by the following filter. The message has left the filter group 

definitely if the filter: method returns true. In this case, the filter has called the 

leaveInput method to free the filter group 4 . If the message has passed all the filters 

without being “filtered out”, a corresponding error is raised, after it has freed the group. If 

a message leaves the group temporarily, the corresponding filter (a meta or wait filter) 

frees the group by calling the leaveInput method. The filter subsequently blocks the 

message and processes it for its own purposes. After the message is released, the message 

reenters the group by calling the enterInputAgain: method. This places the message 

in the priority part of the input filters queue. 

12.3.2 Message handling by a filter 

Now the message arrives at the level of an individual filter. When a filter filters a message, 

the filter has to decide whether to accept or to reject the message. If the message is 

accepted by the filter, the accept action of the filter must be carried out. In the opposite 

case, if the message is rejected, the reject action of the filter must be carried out. The 

decision whether to accept or reject a message is called the accept test and has been 

described in chapter 9. The accept test is common to each filter handler, while the accept 

4. The filter has an instance variable, called object, so that it knows of which object it is a filter of, and where 

to send the leaveInput message to. 


103

104 

and reject actions differ for each type of filter handler. In this section we focus on the 

accept test, while the next section describes the specific actions of the various filter 

handlers. 

The accept test The accept test decides if a filter has to accept or to reject a message. The filter initializer 

of a filter (the part between the curly braces in the filter declaration) defines which 

messages it accepts. Other messages are rejected. In the definition of the accept test 

(section 9.4, page 66), the message is checked against every filter element in the filter 

initializer from left to right, until one accepts it. For a filter element to accept a message: 

• the condition must evaluate to true (condition evaluation); 

• the selector of the message must match with one specified in the filter element (selector 

matching); 

• either, the target of the message must match with the target of the matching part μ, for 

a message pattern [μ]σ that consists both of a matching part μ and a substitution part σ, 

and that is not the pattern of an exclusion element (receiver matching); 

• or, the message must be included in the signature of the target of σ, for a message 

pattern σ that consists only of a substitution part, or a message pattern [μ]σ in an 

exclusion element —of which the matching part μ is ignored (signature matching). 

If the filter element accepts a message, a new target object and selector is returned. They 

are used by the filter as the target and selector of an ACT message (meta filter), or as 

replacement for those of the message (dispatch, send, and error filter) (yielding a 

substitution target and selector). 

It is clear that selector matching and receiver matching are the cheapest operations in the 

accept test, as they require only the comparison of two selectors (strings), or object 

pointers. Signature matching also requires the comparison of selectors, but is less cheap 

(see section 12.3.3). The most expensive operation is condition evaluation, which requires 

the invocation of a condition. To implement the accept test efficiently, it should evaluate 

conditions only when necessary, that is, when the selector of the message matches the 

selector in the filter element. However, the filter initializer does not specify which 

conditions have to be evaluated for one particular message selector separately. This is 

because the same selector can appear in several filter elements. In order to see if a message 

that has been blocked by a wait filter can be unblocked, it would also be very convenient to 

reevaluate only those conditions that are relevant for the blocked message. 

FIGURE 12-7 Object diagram of Filters 

We propose to implement a filter as a selector dictionary, which specifies for every 

message selector which conditions and matchings must be evaluated in order to accept the 

message. This dictionary is a table of the conditions/matchings, indexed by the selector. 

Note that only the selectors explicitly mentioned in the filter initializer should have a 

separate entry, because conditions/matchings have been specified for them. Other 


Dictionary 

SelectorDictionary 

Filter 

filter: 

conditionValue:tarColl:selColl: 

BlockClosure

selectors, for which the same conditions/matchings must be evaluated, can be mapped to 

the same entry. The accept test for a message consists of retrieving the conditions for the 

selector of the message, and evaluating them. The accept test collects a new target and 

selector which are passed to the accept or reject action of the filter accordingly. For the 

conversion of a filter initializer to a selector-condition dictionary we have designed an 

algorithm which is described in appendix D. The algorithm extracts for each selector the 

conditions to be evaluated, the receiver or signature match to be performed, and the target 

or selector to be returned. 

Figure 12-7 shows the classes involved. A SelectorDictionary is a selector indexed 

hash table which has, in addition to its superclass Dictionary, a default entry that is 

returned if a selector entry is requested for which a separate entry is not available. This is 

used to map the selectors not explicitly mentioned in the filter initializer. In the subclass 

Filter an entry for a selector is a code section —a block closure— which specifies all 

the conditions, receiver and signature matchings to be evaluated for a that specific selector, 

and additionally, the target and selector to yield. The class Filter is the superclass for 

each filter handler class. They will be described in the following section. 

Now let us have a closer look at an entry of a filter. Such an entry is a block closure 

containing a boolean expression which is composed of the conditions and matchings to be 

evaluated for a single selector. Since the boolean expression depends on the conditions and 

matching functions in the filter initializer, it is generated by the conversion algorithm in the 

compiler. The message to be tested is passed as a parameter to the block which returns a 

boolean indicating whether it must be accepted or not. Conditions receive this active 

message as a parameter when they are evaluated, thus making the pseudo variable 

message accessible inside conditions. The block closure also must yield a new target or 

selector when the message must be accepted. For this, the block has two additional 

parameters (block closures, again) which are used to set a new target or selector. To see 

how a typical block closure would look like, consider the following filter initializer. 

EXAMPLE 12-4 A { full=>super1.*, [retrieve]inner.get, empty=>inner.get }; 

In this filter initializer, two selectors have been explicitly mentioned (retrieve, get), and the 

conversion algorithm accordingly generates three block closures (two for the explicit 

selectors, and a default for all other selectors). These are shown below. 

EXAMPLE 12-4 B #retrieve-> 

[:msg :tarBlk :selBlk| 

((object full: msg) and: [super1 signatureIncludes: #retrieve]) 

ifTrue: [tarBlk value: super1. true] 

ifFalse: [tarBlk value: inner. selBlk value: #get. true] 

] 

#get-> 


((object full: msg) and: [super1 signatureIncludes: #get]) 


ifFalse: [ 

(object empty: msg) 

ifTrue: [tarBlk value: inner. selBlk value: #get. true] 

ifFalse: [false]] 

] 

DEFAULT-> 


((object full: msg) and: [super1 signatureIncludes: msg selector]) 


ifFalse: [false] 

] 

The class Filter provides the method conditionValue:tarColl:selColl: to 

evaluate the conditions/matchings for a message. It retrieves from itself the block closure 

corresponding to the selector of the message, evaluates it, and collects a new target and 


105

106 

selector. The filter: method is now very simple (example 12-5). It collects a new 

target and selector while it evaluates the conditions, and then accordingly executes the 

accept or reject action. It returns true to indicate that the message has left the filter group 

definitely, and false if the message needs to be filtered by the following filter. For 

efficiency reasons the filter: method is overridden in the various filter handler 

subclasses. For each filter handler, its specific accept and reject actions are inlined in the 

ifTrue:ifFalse: statement. 

EXAMPLE 12-5 Filter>>filter: anActiveMessage 

|newTarget newSelector| 

(self 

conditionValue: anActiveMessage 

tarColl: [:t | newTarget := t] 

selColl: [:s | newSelector := s]) 

ifTrue: [^self 

accept: anActiveMessage 

target: newTarget 

selector: newSelector] 

ifFalse: [^self 

reject: anActiveMessage 

target: newTarget 

selector: newSelector] 

Discussion We can conclude that the major work of the filter accept test is done by the conditions/ 

matchings block closures. The number of condition blocks depends on the number of 

selectors explicitly mentioned in the filter initializer. In most filters this number does not 

exceed 5 to 7. When a filter filters a message, only a single condition block closure has to 

be evaluated. We have not timed the evaluation of a block closure, but as a block is similar 

to a method, this is comparable to method invocation time. We could try and compare this 

with an alternative implementation in which the code of each separate condition block is 

combined with a case statement in the conditionValue:tarColl:selColl: 

method. This alternative has a disadvantage: the conditions on which a message blocks in 

a wait filter are no longer available separately. 

12.3.3 The signature of an object and signature matching 

The signature of an object defines the operations (i.e. messages) it supports. The signature 

of an object consists of its own operations (the interface methods) and the operations of the 

objects to which it delegates (the target objects in dispatch filters). The latter is defined 

(recursively) by the signatures of the respective target objects. Although conditions can 

affect to which object a message is delegated, and thus at some moment the owning object 

might support the operations of some target object, the signature includes all possible 

operations irrespective of the conditions. This may lead in choosing the false object to 

dispatch a message to, for which a solution is proposed below. 

Signature matching must check if an active message is included in the signature of a 

designated object. If this is the case, and provided that the conditions evaluated to true, the 

message can be accepted. In the case of a dispatch filter, this means that the message is 

dispatched to this object. Signature matching therefore is the key to inheritance and reuse 

in the composition filters object model. 

In this section we first justify the definition of an signature of an object, and subsequently 

describe how signature matching is implemented. 

Signature of an object The definition 9-1 of the signature of an object (page 68) specifies a simple signature, 

because it only considers the selectors of methods. A full signature would also account for 

the number of method parameters, their types, and the type of the object returned by the 

method [Wirfs-Brock90]. Since we do not address type checking in this thesis, the given 

definition proves to be sufficient. 


The signature of an object specifies the operations this object supports, and it basically 

includes the selectors of its interface methods, and, recursively, the operations supported 

by its internals and externals. However, not always all the externals and internals 

contribute to the signature. If an object does not use an internal/external to dispatch 

messages to (but uses it as an ACT instead), the object does not support its operations, and 

therefore this internal/external does not add to the signature of the object. Additionally, the 

signature of an object includes the selectors that are substituted in a message by some 

input filter. To understand this, consider a class which defines an interface method get and 

has the following two input filters 

EXAMPLE 12-6 A subst : Error = { [retrieve]get, *}; 

disp : Dispatch = { inner.get }; 

It is obvious that this class also supports retrieve messages, as the error filter replaces the 

selector of such a message by get, upon which the get method is invoked. Therefore, the 

signature also includes the selectors that are substituted the message by an input filter. 

Note that only an (input) error or dispatch filter do a substitution of the message selector, 

and that output filters do not contribute to the signature of an object. 

One thing we cannot detect, or only with great effort, is if an ACT affects the signature of 

an object. The definition of the signature of an object disregards this possibility. However, 

this may not always be correct, and has the consequence that an object is not chosen to 

dispatch a message to, although it supports the operation. For instance, the signature of the 

object of example 12-6 A does not include retrieve, but still supports retrieve messages if 

the substitution of the retrieve selector was carried out by an ACT instead of the error filter. 

That is, if the error filter had been replaced by the meta filter 

EXAMPLE 12-6 B subst : Meta = { [*]anACT.modifyMessage }; 

in which the modifyMessage method of anACT, apart from possible other things, replaces 

a retrieve selector by get. It requires semantic analysis of (the methods of) an ACT to 

detect this. 

Because the signature of an object is based on the operations it supports (directly or 

indirectly), irrespective of the conditions, this object can inadvertently be chosen as the 

target to dispatch a message to. This can happen if a message is in the signature of the 

object, but conditions prevent the message to be dispatched to inner, or to its internals or 

externals. If this object is chosen to dispatch the message, the message is likely to pass all 

the filters in the filter group and then causes an error exception. 

The similar situation can appear if a message is delayed by a wait or meta filter of an 

object. Suppose its conditions initially would allow a message to be executed, but during 

the delay they change in such a way that the message cannot be dispatched any more: the 

message is likely to cause an error exception. While the first is caused by the signature 

definition not being fine grained enough (i.e. it should consider the conditions), the latter is 

caused by the application because the state of the object changed. In the latter case the 

application should take precautions to prevent this, while the first must be solved by the 

implementation, by refining the definition of the signature of an object in order that it 

considers conditions as well. 

Signature matching The signature matching has been implemented in the following way. Every user defined 

object has a method called signatureIncludes: which takes the selector of the 

message to be checked as parameter. It first checks if it is supported by its private 

signature, that is, if the selector is the selector of an interface method, or a selector 

substituted by an input filter. If not, the signatures of the objects to which the object 

delegates are recursively checked. This method must be generated by the compiler. 


107

108 

This implementation ensures that any changes in the signature of an object is noticed, for 

instance if an internal object is replaced by another object (behavior injection). However, 

it has a computational overhead, as every time the signature needs to be calculated. This 

could be reduced by storing the operations which an object indirectly supports (i.e. the 

signatures of the objects to which it delegates) at instance creation time. Instead of sending 

the signatureIncludes: message to the object to be checked, this so called 

signature cache can be consulted to see if it includes the (selector of the) message. 

This signature caching technique requires additional effort to keep the cache consistent 

when the signature of an object changes (e.g. due to behavior injection). This is because 

the signature of a object (recursively) depends on the signatures of the object to which it 

dispatches. These dependencies can be expressed by a dependency tree. A change in the 

signature of an object requires all the objects towards the root of the dependency tree need 

to be notified to update their signature cache accordingly. 

12.4 Filter handler classes 

Every subclass of class Filter implements a specific filter handler. Figure 12-8 shows 

the filter handler hierarchy. If a message is rejected by a dispatch filter, send filter or meta 

filter, or accepted by a wait filter or error filter, the message must be filtered by the 

following filter. This means that the message does not leave the filter group. In the 

opposite cases, the message either leaves the filter group temporarily or definitely. As 

described in section 12.3.1, the filter signifies this by calling the leaveInput or 

leaveOutput method of the owning object, depending on whether it resides in the input 

or output filter group. To avoid case testing in the accept or reject action for this, we have 

introduced two separate subclasses for most filter handlers. The DispatchFilter and 

SendFilter have a single subclass because they can only appear as input filter or output 

filter, respectively. The problem of excessive class declarations (see section 1.1, page 3) is 

not so severe, because two classes are needed for each filter handler at most. 

FIGURE 12-8 The filter handler hierarchy 

DispatchFilter 

InputDispatchFilter 

SendFilter 

OutputSendFilter 

As we have mentioned in the previous section, a filter filters a message by performing the 

accept test (evaluating the conditions, and collecting a new target and selector), and 

subsequently carrying out its accept or reject action, as appropriate. In the coming sections 

we describe these actions for each filter handler class in more detail. Note that if a message 

is accepted or rejected, the message leaves the filter group definitely, or only temporarily. 

In order to prevent deadlock, it must yield the group to the next active message (by 

leaveInput or leaveOutput), before further action is taken upon it. 

12.4.1 Dispatch filter 

When a message is accepted by a dispatch filter, it leaves the (input) filter group definitely. 

A new selector replaces the selector of the accepted message. If the new target is inner, a 

corresponding method of the owner will be invoked. The way how a method is invoked is 


Filter 

ErrorFilter 

InputErrorFilter InputMetaFilter InputWaitFilter 

OutputErrorFilter 

MetaFilter WaitFilter 

OutputMetaFilter 

OutputWaitFilter

described in section 12.5. Otherwise the message is offered to the input filters of the new 

target object. The message is directed to the input filters of this object by calling its 

inputMessage: method. 

12.4.2 Error filter 

A message which is accepted by an error filter is allowed to continue in the next filter. The 

new target or selector replace the receiver and selector of the accepted message, 

respectively. A rejected message leaves the filter group definitely and is aborted by raising 

the error filter error signal. 

12.4.3 Send filter 

When a send filter accepts a message, the message leaves the (output) filter group 

definitely. The new target or selector replace the receiver and selector of the accepted 

message. If the encapsulating object of the owner of the filter 5 does not encapsulate the 

target of the accepted message (i.e. if the target lies outside the encapsulating object of the 

owner), the message is directed to the output filters of the encapsulating object with the 

outputMessage: method. Otherwise it is directed to the input filters of target of the 

message with the aid of the inputMessage: method. 

12.4.4 Meta filter 

When a message is accepted by a meta filter, it leaves the filter group temporarily to be 

reified and offered to an ACT object. The new target and selector, and the reified active 

message are the receiver, selector and argument of a new active message for the ACT. 

Section 12.6 focuses on this. After the accepted message has been dereified, it must 

continue in the following filter, except if the ACT supplied a reply for it, in which case the 

message does not have to enter the group again. As described in section 12.3.1, the active 

message reenters the filter group by sending enterInputAgain: or 

enterOutputAgain: to the owner of the filter. However, we do not have to account 

for messages which have been supplied a reply, because if this happens, the replyBlock 

block closure of ActiveMessage has been executed to shortcut the filtering process 

(see section 12.2) 

12.4.5 Wait filter 

A message that is accepted by a wait filter is allowed to continue in the next filter. A new 

target object and selector are discarded by this filter. A rejected message must be delayed, 

and therefore only temporarily leaves the filter group. The block closure containing the 

conditions on which the message was rejected (see section 12.3.2) is retrieved and is used 

to delay the message. This is described in section 12.7. After the message is allowed to 

continue, it reenters the filter group by sending enterInputAgain: or 

enterOutputAgain: to the owner of the filter. 

12.5 Method invocation 

The active message has finally arrived at a method which must be invoked. As we have 

seen in chapter 7 (section 7.6, page 50), there are two types of method, methods that return 

early and normal methods. With an early returning method it is possible to create 

concurrency. In the next chapter (section 13.3, page 121) we describe how to detect 

whether a method returns early or not. Since the object manager keeps track of how many, 

and which methods are active, this information must be passed to the object manager upon 

the invocation and the finishing of a method. 

A <strong>Sina</strong>⁄st method xyz(arg1, arg2, …, argn) is translated to a Smalltalk method which looks 

like this: 

5. An object knows its encapsulating object. For this, class Abstract<strong>Sina</strong>Object has an instance variable, 

called encapsulatingObject, to maintain this link 


109

110 

EXAMPLE 12-7 A xyz: sender with: server with: arg1 with: arg2 … with: argn 

| temps | 

creation of temps 

body 

Instances of the local variables of a method (declared in the temps section) are created 

before the body is executed. The parameters of the translated method correspond to the 

arguments as they are stored in an ActiveMessage instance (see section 12.2). The first 

two parameters, sender and server are always passed to the method. Thus, if the 

<strong>Sina</strong>⁄st method does not have any parameters, the header of the translated Smalltalk 

method is xyz: sender with: server. 

To invoke this translated <strong>Sina</strong>⁄st method, Smalltalk provides an operation 

perform:withArguments: which has the selector of the method to be invoked and 

an array of arguments as parameters 6 . The arguments are available as array in the 

ActiveMessage, but the selector #xyz:with:with:with:…with: is not. Only a 

<strong>Sina</strong> equivalent selector is stored in the ActiveMessage (the symbol #xyz in this 

case), which means that we must map the <strong>Sina</strong> selector to the Smalltalk selector. Every 

compiled <strong>Sina</strong>⁄st class therefore has a hash table which takes care of this mapping. The 

hash table is an instance of the Smalltalk class Dictionary and appears as the class 

variable <strong>Sina</strong>SmalltalkSelectorMap in the compiled class. 

The Smalltalk selector depends on the number of arguments of the <strong>Sina</strong>⁄st method. We 

could have stored the Smalltalk selector in the ActiveMessage because the number of 

arguments is known at the moment of send. However, during the filtering of the message 

its selector must be compared several times with selectors specified in the filter initializer 7 . 

But the number of arguments is not known when the filter is declared, and consequently a 

Smalltalk selector cannot be used by the filter. To avoid complicated selector comparison 

during the filtering, the short <strong>Sina</strong> selector is stored in the ActiveMessage, and used by 

filters. This <strong>Sina</strong> selector is also useful when the selector or the number of arguments of a 

message is changed by an ACT: the number of arguments does not have to be considered 

when these changes are applied to the message. 

Active method counters In <strong>Sina</strong>⁄st , the object manager of an object keeps track of how many, and which methods of 

the object are active, that is, the methods which have been invoked and which have not 

finished their execution. A normal returning method finishes execution when it returns an 

object. An early returning method, on the other hand, continues after it has returned an 

object, until the last statement in the body has been executed. For this, the class 

ObjectManager represents the object manager of an object, and provides the methods 

startedMethod: and finishedMethod:. These methods both take a (<strong>Sina</strong>) 

selector as an argument to indicate the method that starts or ends. Upon the invocation of a 

<strong>Sina</strong>⁄st method, the former is called. Signalling the end of a method depends on whether 

the method returns early or not. The next section discusses this. 

The invocation of the method is carried out in the accept action of a dispatch filter. This 

filter decided that the accepted active message must be delegated to inner. This is shown 

below: the accept action converts the <strong>Sina</strong> selector in the active message to the Smalltalk 

selector of the method to be invoked, and signals the object manager that it starts a 

method. It subsequently invokes the method, and passes the object returned from this 

method back to the active message, by calling its replyValue: method (see 

section 12.2). 

EXAMPLE 12-7 B DispatchFilter>>accept: activeMessage 

|sinaSel smalltalkSel| 

6. The perform:withArguments: method achieves (Smalltalk) message sending, as if a message with 

the involved selector and arguments had been sent to the receiver of the perform:with-Arguments: 

message. Normal (Smalltalk) method lookup and invocation takes place. 

7. Actually, an entry of the selector-dictionary is retrieved, see section 12.3.2. 


sinaSel := activeMessage selector. 

smalltalkSel := object sinaSmalltalkSelectorMap at: sel. 

object manager startedMethod: sel. 

activeMessage replyValue: 

(object 

perform: smalltalkSel 

withArguments: activeMessage arguments) 

12.5.1 Normal and early returning methods 

There are two types of methods, methods that return early and normal methods. The next 

chapter (section 13.3, page 121) describes how to detect whether a method returns early or 

not. When a method finishes, the object manager of its owner must be signalled in order to 

update its active method counters. A normal method finishes executing when it returns an 

object to its caller. An early returning method continues executing after it has returned an 

object to the caller, and it does this concurrently with the caller. This means that a new 

thread must be created upon the invocation of such a method. We now describe how both 

types of methods are translated to Smalltalk. 

FIGURE 12-9 Interaction diagram of the invocation of a normal method 

message 

thread 

sender 

reply 

Normal return Translation of a normal returning method is straightforward, as example 12-7 C shows. 

Note that the reply expression is evaluated before the object manager decrements the 

active counter. Figure 12-9 shows the interaction diagram of the method invocation. 

EXAMPLE 12-7 C xyz: sender with: server with: arg1 with: arg2 … with: argn 

| temps | 



^manager finishedMethod: #xyz reply: expression. 

Early return Definition 7-2 prescribes a method to be an early returning method if there is a flow in 

which the return is followed by one or more statements. There are several flows possible in 

a method, because the method body can contain statements which do a branch (conditional 

if-then-else statement and loop statements). If we allow only one exit (return) from a 

method, it would be sufficient for an early returning method to create only a new thread for 

the statements following the exit. Since a method can have several flows and equally 

multiple exits, it would require to create new threads for the statements following a return 

in all possible flows. This is a problem because flows are difficult to calculate. For 

example, the statements following a conditional statement must be executed after the 

statements in either branch. The solution is to create a new thread for the whole method 

body of an early returning method, as shows in example 12-7 D. 

EXAMPLE 12-7 D xyz: sender with: server with: arg1 with: arg2 … with: argn 

| temps reply hasReply | 


hasReply := Semaphore new. 

manager newThreadFor: 


ActiveMessage DispatchFilter receiver ObjectManager 


filter: 

startedMethod: 

perform:withArgs: 

reply 

finishedMethod:reply: 

reply 

111

112 

[ statements preceeding a return 

reply := expression. hasReply signal. 

statements following a return 

manager finishedMethodThread: #xyz. 

]. 

hasReply wait. 

^reply 

The creation of a new thread is delegated to the object manager. The method (actually the 

invoking thread) must wait until a reply becomes available from one of the return 

statements in the body thread. The translated method additionally has a semaphore and a 

shared variable to synchronize the invoking and the body thread. Only at the end of body 

thread, the object manager is signalized that the method and its thread have finished (see 

figure 12-10). 

FIGURE 12-10 Interaction diagram of the invocation of an early return method 

ActiveMessage DispatchFilter receiver ObjectManager 

message 

sender 

thread 

hasReply 

new 

thread 

reply 

12.6 Message reification and dereification 

Message passing semantics of <strong>Sina</strong>⁄st has been described in chapter 10. When an object 

(sender) sends a message, the message will be filtered and, in most cases, invoke a method 

which returns an object to the sender. The execution path of this active message can be 

divided in what we call a forward travel and a backward travel. During the forward travel 

the message is being filtered in order to invoke and execute a method. This method yields 

an object which is returned to the sender during the backward travel. A meta filter can 

suspend the active message when it is filtered, i.e. during its forward travel. The message 

is reified and offered to an ACT. After the ACT has processed the message, the ACT 

dereifies it, which in general causes the message to travel further forward. The ACT can 

choose to suspend the execution again when the message is travelling backward, i.e. when 

it is returning a reply object to the sender. This allows the ACT to obtain the reply of the 

message and even change it. The ACT dereifies it a second time which causes the message 

to travel further backward with the original reply or indeed another. 

In <strong>Sina</strong>⁄st , the class ActiveMessage represents an active message, that is, a message which 

is either being filtered, or executing a method. The class <strong>Sina</strong>Message represents a reified 

message, that is, a message which is not executing. This can mean that it has not been 

active before, or that its was active but its execution (temporarily) has been suspended. 

The latter is the case if an active message was reified by a meta filter. In the former case, 

the <strong>Sina</strong>Message instance is created because it was declared as an instance of that class. 

The class <strong>Sina</strong>Message provides three methods to (re)activate, i.e. to dereify it. They are: 

• continue (synonym for fire), which causes the message to follow it normal course, 

either further forward or backward; 



filter: 


perform:withArgs: 

reply 

wait 

signal 

reply 

newThreadFor: 

finishedMethodThread:

• reply, which supplies a reply object for the message. It terminates further forward 

execution of the message and starts the backward travel of the message, or when it 

already was on its return trip, sends it further back. 

• send, which causes the message to continue on its forward travel, and to intercept it 

when it is on its way back. 

A reified message, a <strong>Sina</strong>Message instance, can pass through a number of stages while it 

is reified. This is shown by the state diagram of figure 12-11. A reified message starts 

either as being ACTIVE or IDLE. The latter indicates that is has not been active before, i.e. 

that it is a newly created <strong>Sina</strong>Message instance. The state ACTIVE means that the reified 

message was active before it was reified by a meta filter. If an ACTIVE reified message 

receives a send request, its state changes to HASREPLY (after it is temporarily dereified to 

obtain a reply object). This indicates that a reply is available. If it subsequently receives a 

continue request, this reply object is returned to the sender of the message. If instead it 

receives a reply request, the argument object of this request is returned to the sender. In 

both cases, the state changes from HASREPLY to REPLIED. This state is also reached if an 

ACTIVE reified message was supplied a reply object with reply at once. An ACTIVE reified 

message obtains the state UNREPLIED after it was dereified with continue. This state 

indicates that the message has not yet received a reply. If an IDLE reified message receives a 

send request, it is activated for the first time, and executes until it returns a reply. Its state 

therefore becomes REPLIED. 

FIGURE 12-11 State diagram of a <strong>Sina</strong>Message 

ACTIVE 

send 

HASREPLY 

Other dereification requests in various states are not allowed. They are not shown in 

figure 12-11. For example, it is incorrect to send a reply request to a message in the state 

REPLIED. The final states UNREPLIED and REPLIED are the states in which the message 

becomes dereified and active again. In these states, it is not allowed to change the 

attributes of a message (sender, server, receiver, selector and arguments), although it is 

permitted to retrieve them. 

FIGURE 12-12 Object diagram of a reified message 

state 

reply 

continue 

reply 

continue 

reply 


continue 

reply: 

send 

waitForDereify 

¤ reifiedFrom: 

UNREPLIED 

REPLIED 

Implementation The <strong>Sina</strong>⁄st classes ActiveMessage and <strong>Sina</strong>Message have direct Smalltalk counterparts in 

the implementation (see the object diagram of figure 12-12). In section 12.2 we already 

encountered class ActiveMessage. This class further provides the method reify in 

order reify itself, i.e. to create an instance of <strong>Sina</strong>Message. The class method 

reifiedFrom: of <strong>Sina</strong>Message accomplishes the instance creation by encapsulating 

the active message. The attributes state and reply are used to hold its state (as 

described above) and the reply object from a reply or send dereification request. The class 

<strong>Sina</strong>Message additionally provides the dereification methods continue, reply: 

and send, and the method waitForDereify which blocks its active message 

component until it is dereified. For this, the semaphore attribute of class 


send 

wait 

signal 

reify 

IDLE 

ActiveMessage 

semaphore 

113 

LEGEND 

START STATE 

FINAL STATE

114 

ActiveMessage is used which was also employed to block it if it enters an occupied 

filter group. 

The implementation of the dereification method send is straightforward for an IDLE reified 

message: its active message component is presented to the input filters of its server 

(inputMessage:). The other to dereification methods are not applicable to an IDLE 

message. 

Reification and dereification of active messages is explained now. Figure 12-13 shows 

how a meta filter reifies an accepted active message. It creates an ACTIVE <strong>Sina</strong>Message 

by sending reify to the active message. The meta filter then requests the object manager 

of the receiver to create a new thread in which the ACT message is sent, having the reified 

message as argument. This new thread is needed because the ACT is allowed to continue 

concurrently with the message after the ACT has dereified it. Then the reified message is 

asked to wait until it is dereified (waitForDereify). This blocks the message thread. 

FIGURE 12-13 Interaction diagram of message reification and dereification 

message 

thread 

receiver 

(manager) MetaFilter ActiveMessage <strong>Sina</strong>Message ACT 

At some point in time, the ACT dereifies the message by sending one of the three 

dereification messages to the reified message. All the three ways of dereification 

accomplish this by signalling the active message. As a result, the message thread continues 

at the waitForDereify method. Depending on whether the message was supplied a 

reply while it was reified (state REPLIED/UNREPLIED), either the waitForDereify 

method finishes (marked with 1 ), or the active message replyValue: method is called 

(marked with 2 ). The former causes the message to be filtered by the next filter, while the 

latter transfers the execution back to the point where the message was sent (as described in 

section 12.2). We now look at the three dereification methods in more detail. 

FIGURE 12-14 Interaction diagram of dereification with continue 


continue 

message 

thread 

receiver 

newThreadFor: [...] 

The interaction diagram of figure 12-14 shows the effect of dereification with continue. 

The top of the diagram displays the point where the message was blocked. If the 


1 

reify 

reifiedFrom: 

reifiedMessage a <strong>Sina</strong>Message 

waitForDereify 

2 

wait 

signal 

ACTIVE 

replyValue: reply 

dereification 

Filter ActiveMessage <strong>Sina</strong>Message ACT 

wait 

REPLIED/UNREPLIED 

signal 

1 

4 

continue 

ACT 

thread 

ACT 

thread

continue request takes place immediately after the message became reified, i.e. if it is 

on its forward travel and its state is ACTIVE, it changes the state to UNREPLIED. If the 

continue request followed a send request (i.e. if it was on its backward travel and its 

state was HASREPLY) the state of the message becomes REPLIED. Subsequently, the active 

message is signalled which restarts the message thread. The message then either continues 

forward in order to be filtered by the next filter (figure 12-13, marked with 1 ), or 

continues its backward travel. This is marked with 4 in figure 12-13, and is described 

below at dereification with send in more detail. 

FIGURE 12-15 Interaction diagram of dereification with reply: 


reply: 

message 

thread 

Dereification with reply is shown in the interaction diagram of figure 12-15. The argument 

object of the reply request is stored in the reply attribute of class <strong>Sina</strong>Message. The 

state of the message changes to REPLIED, and the active message is signalled. If the 

message was travelling forward, this is aborted, and it is sent backward instead ( 2 , 

corresponding to figure 12-13). Otherwise it continues its backward journey ( 4 ). 

FIGURE 12-16 Interaction diagram of dereification with send 

message 

thread 

receiver 

Filter 

replyValue: x 

Dereification with send After a message has been dereified with send, it must be intercepted when a reply of the 

message becomes available, i.e. during its backward travel. This is realized by replacing 

the replyBlock block closure of the active message (see section 12.2) with one which 

transfers the control back to the ACT. When a reply becomes available, this block closure 

is executed instead. After the ACT dereifies the message a second time, the message 

continues its backward travel by executing the original reply block. 


Filter ActiveMessage <strong>Sina</strong>Message ACT 

wait 

REPLIED(x) 

signal 

replyValue: reply 

2 

ActiveMessage <strong>Sina</strong>Message ACT 

wait 

getReplyBlk 

oldReplyBlk 

setReplyBlk: [...] 

3 

signal 

HASREPLY(x) 

wait 

signal 

4 

send 

wait 

signal 

reply 

dereification 

4 

reply: x 

hasReply 

115 

ACT 

thread 

ACT 

thread

116 

As shown by the interaction diagram for send (figure 12-16), the old reply block is 

preserved and replaced by the new one. Then, it signals the message to continue its 

forward travel, and blocks the ACT on the semaphore hasReply which causes to for the 

reply. In the mean time, the message is filtered by several other filters, invokes a method 

and returns a reply object (replyValue: x). This causes the new reply block to be 

executed ( 3 ). It stores the reply object in the reply attribute of <strong>Sina</strong>Message, 

changes the state to HASREPLY, and signals the ACT that a reply is available. Subsequently, 

the message blocks itself to wait until it is dereified again. The reply object is returned to 

the ACT as result of the send request. The ACT processes this object and after while 

sends a second dereification request. This continue or reply: request signals the 

message to proceed, as described above. The message then continues at 4 where it 

executes the original reply block, thus travelling further backward with the original reply 

object or a new reply object which was supplied by the reply: request. 

12.7 Synchronization 

Synchronization in <strong>Sina</strong>⁄st is realized by the wait filter. If a wait filter rejects a message, it 

must be blocked. As the conditions on which it blocked reflect a state of an object, these 

conditions must be monitored to observe a state change which would allow the message to 

continue. This means that they must be reevaluated repeatedly. The object manager of an 

object is responsible for all of this. 

Object manager The object manager is represented by the class ObjectManager (see figure 12-17). 

Because every <strong>Sina</strong>⁄st object has an object manager, it is a made an instance variable of the 

class Abstract<strong>Sina</strong>Object. The object manager stores blocked messages in two 

queues (MessageQueue): one for messages that are blocked by an input wait filter 

(message requests), and one for those blocked by an output wait filter (message 

invocations). The number of blocked messages in each of these queues can be requested 

by a <strong>Sina</strong>⁄st application. The attributes blockedReq and blockedInv preserve these 

numbers, which thus avoids counting the message queues. 

Stored together with each message entry in the queues are the conditions on which the 

message blocked. These conditions are available as a block closure (see section 12.3.1). 

These conditions have to be reevaluated when appropriate. If a wait filter rejects a 

message, it sends the blockedReq:on: c.q. blockedInv:on: request to the 

receiver of the message. This object delegates it to its object manager. 

As we have described in section 12.5, the object manager provides methods to keep track 

of the number of activated (unfinished) methods, and the threads which are created upon 

the invocation of early return methods. The object manager is informed when a method is 

invoked (startedMethod:), when it finishes (finishedMethod:reply:), and 

when a new thread must be created (newThreadFor:) or destroyed 

(finishedMethodThread:). The attribute active holds the total number of 

activated methods, while activeForMethod gives this for each of the methods of the 

owner. 

FIGURE 12-17 Object diagram of the object manager 


blockedReq:on: 

blockedInv:on: 



ObjectManager 

active 

activeForMethod 

blockedReq 

blockedInv 

threads 


blockedInv:on: 


finishedMethod:reply: 

newThreadFor: 

finishedMethodThread: 

2 

MessageQueue

Starting and finishing a method, and blocking a message causes changes in the state of the 

object. The object manager therefore reevaluates the conditions of the blocked messages at 

these moments. In both queues, only the first message to evaluate its conditions to true is 

removed from its queue and restarted. The private method updated of class 

ObjectManager carries out this reevaluation. 

Synchronization This leads to the interaction diagram of figure 12-18 which shows the synchronization of a 

message rejected by an input wait filter. The diagram is identical for messages that are 

blocked by output wait filters, except that blockedReq:on: is replaced by 

blockedInv:on:. The rejected message and its blocking conditions are placed in the 

queue. Because the state was changed (blockedReq was incremented), the conditions of 

blocked messages must be reevaluated. Subsequently, the active message thread is 

blocked. Another thread that caused a state change reevaluates the conditions and detects 

that they now evaluate to true. The blocked message is removed from the queue and 

signalled to resume. This causes the message to be filtered by the filter following the wait 

filter. 

FIGURE 12-18 Interaction diagram of message synchronization 

message 

thread 

InputWaitFilter 


There is one limitation to the implementation described above. Reevaluation at the start or 

end of a method, or upon blocking of a message is sufficient to detect changes in the state 

of the object manager (part of the state of its owning object), but not always changes in the 

total state of the object. If the state of an object changes without a change in the state of the 

object manager, reevaluation will not take place, whilst there might be blocked messages 

that could be restarted. This can happen if no messages are blocked and no method starts 

or ends, but there is at least one method active causing these changes. To illustrate this, 

consider example 12-8. Assume that method m2 is the single active method. This method 

constantly changes the state s1, and as it is in an infinite loop it does not finish. If the 

object further does not receive any messages (which possibly could be blocked by the wait 

filter f and cause a reevaluation), then messages that are blocked on condition c reflecting 

state s are not restarted, even though they should. 

EXAMPLE 12-8 class XYZ interface 

inputfilters 

f : Wait = { c ~> m1 }; 

... 

end; 

class XYZ implementation 

conditions 

c begin return s end 

methods 

m1 ... 

m2 begin 

while true 

begin 


receiver ActiveMessage ObjectManager MessageQueue 


wait 

updated 

updated 

signal 

addLast: 

remove: 

117 

other 

thread

118 

end 

s := false; for i := 1 to 1000000 begin end; 

s := true; for i := 1 to 1000000 begin end; 

end 

end 

[Bergmans94] describes an algorithm which can solve this problem. The algorithm 

identifies the locations where relevant state changes take place, which are the points where 

the conditions (of the blocked messages) need to be reevaluated. Another solution would 

be to let the object manager evaluate the blocked messages at a regular basis (a timeinterval), 

irrespective of state changes in the object or its object manager. This leads a 

computational overhead, especially if the state of an object does not change frequently. 

As the algorithm of [Bergmans94] is intended to reduce the frequency of condition 

evaluation and minimizes the computational costs involved in the evaluation, it can be 

used also to improve the implementation of condition reevaluation described in this 

section. The algorithm finds the locations where state changes occur, and additionally 

minimizes the amount of condition evaluation code. 

12.8 <strong>Sina</strong>⁄st messages to Smalltalk objects 

As Smalltalk comes with an extensive class library, we also want to use them in a <strong>Sina</strong>⁄st 

application. For this it is necessary that each Smalltalk object knows how to respond to a 

<strong>Sina</strong>⁄st message. As described in section 12.1, only the entry points (methods) 

inputMessage: and signatureIncludes: are needed for this. 

Therefore, we add these methods to the class Object, the superclass of all Smalltalk 

classes 8 . The inputMessage: method converts the message selector to a Smalltalk 

selector and executes the corresponding method. The class instance variable 

smalltalkSelectorDictionary of class ActiveMessage holds a number of 

<strong>Sina</strong> selectors that require a special mapping. These are selectors which must be mapped to 

binary Smalltalk selectors (add to +, times to *, etc.). The signatureIncludes: 

method merely checks if the object has a method with a Smalltalk selector corresponding 

to the one of the active message. 

This concludes the description of the execution model. The following chapter details how 

a <strong>Sina</strong>⁄st object is mapped to Smalltalk. 

8. Adding methods to an existing class in general considered bad practice, but we do it for performance 

reasons. Message dispatch (in the dispatch filter) otherwise requires a test to see if the target is a Smalltalk 

object, and if so, convert the <strong>Sina</strong> message to a Smalltalk message and send this to the Smalltalk object. 


13 Translation Model 

In the previous chapter we described the execution model which showed how messages 

follow their course from sender, through filters, and eventually to the method of the 

receiver. In this chapter we describe the translation model, which defines how each <strong>Sina</strong>⁄st 

object is translated to Smalltalk. We start by describing the object model of the 

implementation (section 13.1). Then we focus on a number of subjects which need 

additional attention. Section 13.2 shows how <strong>Sina</strong>⁄st instances are created, while the next 

section describes how we can detect whether a method is an early or a normal returning 

method. The final section summarizes the mapping from <strong>Sina</strong>⁄st to Smalltalk and describes 

what the <strong>Sina</strong>⁄st compiler has to generate when it compiles a <strong>Sina</strong>⁄st class. 

13.1 General object model 

The object model of figure 13-1 shows the structural relations between the various classes 

of the implementation. Every user defined <strong>Sina</strong>⁄st object has been mapped to a 

corresponding Smalltalk class UserDefinedObject which inherits from the class 

Abstract<strong>Sina</strong>Object. This class provides common behavior for all translated <strong>Sina</strong>⁄st 

objects. As we have seen in the previous chapter (section 12.3 and 12.7), it embodies the 

ObjectManager and two MessageQueues for messages entering the input or output 

filter groups. The ObjectManager additionally has two MessageQueues which holds 

messages blocked by wait filters. Every UserDefinedObject has its own set of 

methods and conditions. These are mapped to Smalltalk methods which are represented by 

the class CompiledMethod. Additionally, a UserDefinedObject has its own set of 

input filters and output filters. They are represented by the filter handler class hierarchy 

(section 12.3 and 12.4). A UserDefinedObject may aggregate any number of 

internals and instance variables, and can refer to any number of externals. 

Apart from the UserDefinedObject class, the classes ObjectManager, 

<strong>Sina</strong>Object, <strong>Sina</strong>Message, ActiveMessage, and RecursiveActive- 

Message are <strong>Sina</strong> classes. This means that they are defined by <strong>Sina</strong>⁄st (see appendix A, 

‘<strong>Sina</strong> Class Interfaces’) and behave like composition filters objects. However, they do not 

inherit from the class Abstract<strong>Sina</strong>Object, because they do not require filters for 

their implementation. In order to handle active messages, they have an inputMessage: 

method whose task is to ‘filter’ the message and invoke an appropriate method (like in a 

user defined object, see example 12-3, page 103). For this, it retrieves from the class 

variable <strong>Sina</strong>SmalltalkSelectorMap the Smalltalk selector of the method to be 

invoked that corresponds to the selector of the active message (similar to method 


119

120 

filter 

group 

blocked 

messages 

DispatchFilter 

invocation, section 12.5, page 109). These classes also provide the method 

signatureIncludes: for signature matching. 

FIGURE 13-1 Object Model of the Implementation 

2 2 

ObjectManager 

MessageQueue 

LEGEND 

method 

CompiledMethod 

InputDispatchFilter 

Library Class 

LinkedList 

external 

OutputSendFilter 


condition 

CompiledMethod 

Object 

The class <strong>Sina</strong>Object provides default behavior (from the application viewpoint) 

which includes printing on a text window. This text window is represented by the class 

ObjectWindow, which will not be opened (‘popped-up’) until text is written to it. 

13.2 Instance creation 

During the creation of an instance of a class, the existence of its externals is verified, the 

internals and instance variables are created, and the initial method is executed provided 

there is one. The class parameters are initialized with the argument objects supplied by the 

creator. The creating object is the object which encapsulates it, that is, the object of which 

Chapter 13: Translation Model 

internal 

instvar 

Filter 

<strong>Sina</strong>Object 

ObjectWindow 

Dictionary 

SelectorDictionary 


Message 

MessageSend 

ActiveMessage 

Recursive- 

ActiveMessage 

SendFilter ErrorFilter 

MetaFilter 

WaitFilter 

<strong>Sina</strong> Class 


InputErrorFilter InputMetaFilter InputWaitFilter 

OutputErrorFilter 

OutputMetaFilter 

OutputWaitFilter

the new instance is an internal, instance variable, or local variable. Only if the instance is 

created in the main method, i.e. if it is a global object, the encapsulating object is the nil 

object. 

FIGURE 13-2 Object & interaction diagram for instance creation 


encapsulating 

object UserDefinedObject Abstract<strong>Sina</strong>Object 

¤newIn:with:* 

encapsulatingObject 

initializeIn:with:* 

initializeInstanceIn: 

initializeInstanceIn: 



initializeInputFilters 

initializeOutputFilters 

verifyExistenceExternals 

constructInstanceObjects 

¤ newIn:with:* 

Figure 13-2 shows the object diagram and interaction diagram of the instance creation 

process. The creating object sends to the class a newIn:with:* request with itself as 

encapsulating object, and zero or more class parameter objects as arguments. This creates 

a new instance to which it sends the initializeIn:with:* request. This method 

gives the class parameters variables its values. Subsequently, the 

initializeInstanceIn: method runs by initializing the filters, verifying the 

existence of externals, creating instances of internals and instance variables, and invoking 

the initial method. Note that filter initialization consists of filling the 

SelectorDictionary with block closures. This is done at instance level because the 

block closures must refer to entities (internals, conditions) within the context of the 

instance. 

13.3 Detecting if a method returns normal or early 

At compile-time it can be detected whether a method is an early return or a normal 

method. Definition 7-2, page 51, shows that a method returns early if there is a flow in 

which a return statement is followed by other statements. This could easily be detected if 

there is only one flow in the method, that is, if the statements in the body would always be 

executed one after another. However, for making decisions (if-then-else) and repetitive 

executions (loops), we must allow conditional jumps to appear in a method. Depending on 

the condition of the jump its possible either to take the jump and move the execution to 

another statement in the method, or just execute the statements following the jump. A 

conditional jump thus spawns two new flows. 

Finding all the flows in a method is impossible because their number can be infinite 

(caused by loops). Instead, we resolve the return kind of the method by scanning the 

statement sequence in the method body, and update this as every statement is processed. 

We keep the state of the statements processed so far, and determine the new state which is 

based on the current state and the return kind of the processed statement. Apart from 

determining the return kind of a method, we also want to verify the two control flow 

requirements (definition 7-3, page 51) which demand that every flow must contain one, 

and only one, return. 

A method body consists of a sequence of statements. A statement can be a return statement 

(return expression), a conditional statement (if-then-else), a loop statement (for and 

while), an assignment or a message expression: 


new instance 





initial 

121

122 

method-body ::= statement-seq 

{statement-seq.returnkind}. 

statement-seq::= statement-seq statement 

{f seq (statement-seq.returnkind,statement.returnkind)} 

| 

{NORETURN}. 

statement ::= return 

{RETURN} 

| conditional 

{conditional.returnkind} 

| loop 

{loop.returnkind} 

| assignment 

{NORETURN} 

| message-expression 

{NORETURN}. 

conditional ::= if condition then statement-seq else statement-seq end 

{f cond (statement-seq then.returnkind, statement-seq else.returnkind)}. 

loop ::= loop-header begin statement-seq end 

{f loop (statement-seq.returnkind)}. 

In the syntax above, we have indicated the return kind of each statement between curly 

braces {}. For example, the return kind of a method-body (which determines the return kind 

of the method) is the return kind of its statement-seq. The return kind of the statementseq, 

conditional and loop depend on the statement-sequence(s) they enclose. This is 

expressed by the functions f seq , f cond , and f loop which are defined below. Note that the 

return kind of a statement-seq is based on the return kinds of the last statement and the 

previous statements (a statement-seq without the last statement). This corresponds to 

scanning process: the return kind of the processed statements is updated with the return 

kind of the last statement. 

The return kind of a statement can be NORETURN, RETURN, EARLY, UNBALANCED, or 

BALANCED. The return kind NORETURN means that the statement does not do a return, as for 

example the assignment and message-expression. A statement has the return kind RETURN 

if it does a non-early return, but if it does, its return kind is EARLY. A statement is 

UNBALANCED if there are several flows possible in the statement of which at least one does 

not do a return. An example of this is the conditional statement in which only one branch 

performs a return. The state becomes BALANCED if there is a RETURNing statement following 

it. A BALANCED statement may not be followed by others statements, because then it would 

be an early returning statement in which there is a flow with two returns. To see this, 

consider again the conditional statement with one returning branch. The flow which 

follows the returning branch would encounter the second return in the statements 

following the conditional statement while this is not allowed. . 

TABLE 13-1 The function f cond (statement-seq then .returnkind,statement-seq else .returnkind). 

then NORETURN UNBALANCED BALANCED RETURN EARLY 

NORETURN NORETURN UNBALANCED UNBALANCED UNBALANCED ERROR 

UNBALANCED UNBALANCED UNBALANCED UNBALANCED UNBALANCED ERROR 

BALANCED UNBALANCED UNBALANCED BALANCED BALANCED ERROR 

RETURN UNBALANCED UNBALANCED BALANCED RETURN EARLY 

EARLY ERROR ERROR ERROR EARLY EARLY 

Table 13-1 defines the function f cond which depends on the return kinds of the then and else 

branches. If one branch does a RETURN, and the other does NORETURN then the conditional 

statement becomes UNBALANCED, because there is one flow possible in which there is no 

Chapter 13: Translation Model 

else

eturn. For the same reason, the conditional statement becomes UNBALANCED too if one 

branch does a RETURN and the other is UNBALANCED, one is BALANCED and the other does 

NORETURN or is UNBALANCED, or one is UNBALANCED and the other does NORETURN. If one 

branch does a RETURN while the other is BALANCED, the conditional statement is also 

BALANCED because it is unbalanced until the last statement in both branches. Other entries 

should speak for themselves 

Table 13-2 defines the function f loop which gives the return kind of a loop statement (for or 

while). The body of a loop can be executed zero or more times, depending on the 

constraints of the loop. The loop statement becomes UNBALANCED if the body does a 

RETURN, or if the body is BALANCED or UNBALANCED. This is because in these cases there is a 

flow without a return if the body is executed zero times. If the body returns EARLY, it gives 

an ERROR because this is not allowed (see definition 7-5, page 52). Note that the function 

f loop can be modified if the loop body is executed at least once (e.g. a repeat-until loop), or 

if we can derive this from the constraints of the loop. 

TABLE 13-2 The function f loop (statement-seq body.returnkind). 

body floop NORETURN NORETURN 

UNBALANCED UNBALANCED 

BALANCED UNBALANCED 

RETURN UNBALANCED 

EARLY ERROR 

The function f seq indicates that the return kind of a statement sequence depends on the 

return kind of the statements so far and that of the current statement. Initially, there is 

NORETURN. We could have defined f seq by a table, but the state diagram of figure 13-3 

shows it more clearly. A state is drawn as a rounded rectangle and has a label X which 

indicates the return kind of the statement sequence up to the last processed statement is X. 

States are connected by arrows, called edges which have labels indicating the return kind 

of the next statement. An Y-labeled edge leaves state labeled X and ends at the state labeled 

f seq (X,Y), the new state of the statement sequence. 

FIGURE 13-3 Flow state changes for a statement sequence f seq 

NORETURN 

LEGEND 

START STATE 

EARLY 

NORETURN 

The initial state of a statement sequence is NORETURN. As long as the next statement has 

NORETURN, it remains in this state. If the statement does a RETURN, the statement sequence 

has a RETURN. If in this state there is a statement which does NORETURN, the we have 

detected an EARLY return, which is ok if there are more NORETURN statements. However, if 

the statement sequence in the EARLY or RETURN state is followed by a statement in which 


UNBALANCED 

NORETURN UNBALANCED 

RETURN BALANCED 

NORETURN 

EARLY RETURN BALANCED 

UNBALANCED 

BALANCED 

RETURN 

EARLY 

Y 

X fseq (X,Y) 

UNBALANCED 

BALANCED 

RETURN 

EARLY 

ERROR 

EARLY 

UNBALANCED 

NORETURN 

RETURN 

BALANCED 

NORETURN 

UNBALANCED 

BALANCED 

RETURN 

EARLY 

123

124 

there is a return (UNBALANCED, BALANCED, RETURN, EARLY), this leads to the error state, 

because there is a second return in the same flow. The statement sequence state changes 

from NORETURN to UNBALANCED if there is an UNBALANCED statement, for instance a 

conditional statement in which only one branch does a return. The state then remains 

UNBALANCED if the next statements do NORETURN, or are UNBALANCED. The state changes 

from UNBALANCED to BALANCED if the statement always returns normally (RETURN or 

BALANCED). 

A method is an early return method if the return kind of the statement- sequence of its 

body is EARLY, that is, if its final state was EARLY. It is a normal method if the final state is 

RETURN or BALANCED. Any other state are not allowed and will lead to a compile time error 

message, because in these states indicate that there is a flow without a return (NORETURN, 

UNBALANCED), or with more than one (ERROR). Note that all the states except ERROR are 

accept states for a statement-sequence since the sequence can be part of another statement. 

13.4 Mapping <strong>Sina</strong> to Smalltalk 

Table 13-3 defines the mapping of the various <strong>Sina</strong>⁄st entities to Smalltalk. As mentioned 

before, a user defined class UDO is translated to a subclass of Abstract<strong>Sina</strong>Object 

which has the same name UDO. To avoid entities which map to Smalltalk instance 

variables receiving the same name as instance variables in the Abstract<strong>Sina</strong>Object 

class, their names are prefixed with f (for filters), or x (for variables). At this moment, 

externals can only be global objects and therefore they are mapped Smalltalk globals. The 

names of methods and conditions are as described in section 12.5. 

TABLE 13-3 Mapping of <strong>Sina</strong> entities onto Smalltalk entities. 

<strong>Sina</strong> Smalltalk 

class UDO class UDO, subclass of Abstract<strong>Sina</strong>Object 

instance of class UDO instance of class UDO 

class parameter w of UDO instance variable xw of UDO 

external X of UDO global variable X 

internal y of UDO instance variable xy of UDO 

instance variable z of UDO instance variable xz of UDO 

filter group - 

filter f of UDO instance variable ff of UDO, an instance of a class 

from the filter handler hierarchy 

method m of UDO method m:with:with:* of UDO 

condition c of UDO method c: of UDO 

local variable of method m temporary variable of method m 

object manager of UDO instance variable manager of Abstract<strong>Sina</strong>- 

Object, an instance of class ObjectManager 

main method unbound method 

active message instance of class ActiveMessage 

recursive message instance of class RecursiveActiveMessage 

reified message instance of class <strong>Sina</strong>Message 

inner self 

self self 

server • attribute of class ActiveMessage 

• passed as parameter to method 

Chapter 13: Translation Model

TABLE 13-3 Mapping of <strong>Sina</strong> entities onto Smalltalk entities. 

<strong>Sina</strong> Smalltalk 

sender • attribute of class ActiveMessage 

• passed as parameter to method 

message • in a condition: passed as parameter 

• in a method: implicitly available as selector and 

parameters of the method. 

The main method is translated to an unbound method 1 . An unbound method does not 

belong to a Smalltalk class: it is not stored in the method dictionary of a class. An unbound 

method, say mu, can be executed by sending the message nil performMethod: mu. 

The pseudo variables inner and self are mapped to Smalltalk’s pseudo variable self. 

Messages to inner invoke the corresponding method directly without passing filters. This 

can be realized in Smalltalk by sending the corresponding (Smalltalk) message to self. 

This invokes the designated method. 

The pseudo variables sender and server are not represented directly but stored in an 

ActiveMessage, or passed as parameter to an invoked method. The pseudo variable 

message is either represented directly (i.e. as ActiveMessage instance) as the 

parameter of a condition, or implicitly inside a method as the selector and arguments of 

this method 

We end this chapter by summarizing the attributes and methods which need to be 

generated by the compiler (see the next chapter) when it compiles a class. They are 

represented by the object diagram of figure 13-4 and the Smalltalk code below. 

FIGURE 13-4 Object diagram of a user defined object 


Abstract<strong>Sina</strong>Object subclass: #UserDefinedObject 

instanceVariableNames: ‘filters classparams 

internals instvars’ 

classVariableNames: ‘<strong>Sina</strong>SmalltalkSelectorMap’ 

poolDictionaries: ‘’ 

category: ‘’ 

UserDefinedObject methodsFor: ‘initial method’ 

initial 

UserDefinedObject methodsFor: ‘interface methods’ 

mi: sender with: server with: arg1 … with: argn 

1. The Smalltalk user interface also uses an unbound method to execute a group of statements which are 

selected by the user for execution (do it), printing (print it) or inspection (inspect). 



class parameters 

internals 

instance variables 

filters 

¤ <strong>Sina</strong>SmalltalkSelectorMap 






inputMessage: 

outputMessage: 

signatureIncludes: 

methods 

conditions 

¤ newIn:with:* 

125

126 

UserDefinedObject methodsFor: ‘private methods’ 

mp: sender with: server with: arg1 … with: argn 

UserDefinedObject methodsFor: ‘conditions’ 

c: activeMessage 

UserDefinedObject methodsFor: ‘private-message handling’ 

inputMessage: activeMessage 

outputMessage: activeMessage 

UserDefinedObject methodsFor: ‘private-signature matching’ 

signatureIncludes: aSelector 

UserDefinedObject methodsFor: ‘private-initialization’ 

initializeIn: encapsObj with: carg1 … with: cargn 





UserDefinedObject class 

instanceVariableNames: ‘’ 

UserDefinedObject class methodsFor: ‘instance creation’ 

newIn: encapsObj with: carg1 … with: cargn 

Chapter 13: Translation Model

14 Programming 

environment 

The <strong>Sina</strong>⁄st language implementation includes a programming environment. It is 

composed of a user interface, a compiler, and a kernel. The user interface allows the user 

to write, save, compile, and execute <strong>Sina</strong>⁄st applications. The compiler compiles source 

code into object code (Smalltalk). The kernel provides run-time support. In this chapter we 

describe these components. 

14.1 Compiler 

The compiler translates <strong>Sina</strong>⁄st source code to Smalltalk object code, in the way described 

in section 13.4, page 124. It is also responsible to report messages resulting from the 

compilation process. These compilation messages include error, warning, and information 

messages. While a compilation error causes the compiler not to generate Smalltalk code, 

the warnings and information messages are merely reported to the user. 

Figure 14-1 shows the structure of the compiler. The compiler is represented by the class 

<strong>Sina</strong>Compiler, which provides two methods to compile <strong>Sina</strong>⁄st source code. The 

method compile: takes a string containing the source code as an argument, compiles it, 

reports syntax errors and compilation messages, and if there are no errors, generates code 

for it. The method compileAndRun: additionally executes the main method, provided 

that the source code contained this method. Both methods return an instance of class 

<strong>Sina</strong>ProgramNodeHolder which holds the result of the compilation process (a parse 

tree). Normally, the compiler is invoked from the user interface (see next section) which is 

used to report compilation messages to. However, the <strong>Sina</strong>Compiler can also be used 

stand-alone, in which case Smalltalk’s System Transcript is used to report 

messages on. 

The <strong>Sina</strong>Compiler is a three pass compiler. The first pass parses the source and builds 

a parse tree for it. A parse tree is an internal representation of the source program which is 

used in following phases. During the first phase, the syntax of the source program is 

checked. The location of a syntax error is shown in the source code window of the user 

interface, or, if the compiler has been used stand-alone, in a separate window which is 

popped up. 

The second pass performs various semantic checks, such as verifying that a variable has 

been declared, and that a message can be understood by a receiver object. Errors, 


127

128 

warnings, and informatives from this phase are represented by the class 

CompilationMessage. They are stored in the <strong>Sina</strong>Builder. 

During the final pass, the compiler generates Smalltalk code for the source program. This 

happens only if the previous phases did not yield a syntax error (first pass), or a semantic 

error (second pass) 1 . Every <strong>Sina</strong> class that appears in the source code is translated to a 

separate Smalltalk class. The main method is compiled into an unbound Smalltalk method. 

The parser, an instance of class <strong>Sina</strong>Parser, is part of the compiler and is responsible 

for parsing the source code and building the parse tree. It is made up of a scanner and a tree 

builder. The scanner, an instance of the class <strong>Sina</strong>Scanner, breaks up the source code 

string into tokens. The tree builder, an instance of class <strong>Sina</strong>Builder, assists the parser 

in building the parse tree, and is responsible to collect compilation messages resulting 

from the second compilation phase. 

FIGURE 14-1 Object model of the compiler 

<strong>Sina</strong>Compiler 

compile: 

compileAndRun: 

CompilationMessage 

collects← 

We have used a tool called T-gen to create a scanner and a parser for the <strong>Sina</strong>⁄st language. 

T-gen (Translator Generator [Graver92a][Graver92b]) is a Smalltalk based tool for the 

automatic generation of scanners and parsers which handles all common grammars 

classified as LL(1), SLR(1), LALR(1) and LR(1). Using the <strong>Sina</strong>⁄st token specification 

(appendix C.1), T-gen generates the scanner class <strong>Sina</strong>Scanner as a subclass of the Tgen 

library class OptimizedScanner-WithOneTokenLookahead. From the 

<strong>Sina</strong>⁄st grammar specification (appendix C.2), T-gen generates the parser class 

<strong>Sina</strong>Parser as subclass of the library class OptimizedLR1Parser. 

The first two passes, the syntactic and the semantic phase, do not take place one after 

another, but they have been intermingled. Once a complete class has been read from the 

source and a parse tree has been constructed for it (first phase), the semantics of the class is 

checked by the second phase 2 . Then, the following class or main part is read and 

semantically checked, until the complete source has been processed in this way. After this, 

the final phase generates Smalltalk code for the complete program, provided that no errors 

have been encountered. 

During parsing of the source program —the first pass of the compilation process— the 

<strong>Sina</strong>Parser builds, with the aid of <strong>Sina</strong>Builder, a parse tree, holding the relevant 

information of the source program. The nodes of the parse tree are instances of classes 

which are not shown here. The result the compilation process is an instance of class 

<strong>Sina</strong>ProgramNodeHolder which holds the root of the parse tree, an instance of class 

<strong>Sina</strong>ProgramNode, and the semantic error messages. 

1. Warnings or informative messages from the second phase are no reason to skip code generation. 

2. What in fact takes place after the first pass has parsed the complete text of a class, is merging the information 

contained in the two parse tree nodes representing the class’ interface and implementation parts (an instance 

of class <strong>Sina</strong>InterfaceNode and <strong>Sina</strong>ImplementationNode respectively), into one node (a 

<strong>Sina</strong>ClassNode) and then discarding the two former nodes. 

Chapter 14: Programming environment 

AbstractSyntax- 

TreeBuilder 

<strong>Sina</strong>Builder 

OptimizedLR1Parser 

<strong>Sina</strong>Parser 

OptimizedScanner- 

WithOneToken- 

Lookahead 

<strong>Sina</strong>Scanner

14.2 User interface 

The user interface represented by the class Interactive<strong>Sina</strong>Compiler which is a 

subclass of the system class Model (see figure 14-2). The attribute source holds the 

source code that is edited by the user, while sourceFilename keeps the filename from 

which it was loaded. The source code is compiled by an instance of <strong>Sina</strong>Compiler, as 

described in the previous section. The attribute programNodeHolder holds the result 

of the compilation, which may contain a main method that is stored in the mainMethod 

attribute to be able to run it at a later moment. The category attribute determines the 

category in Smalltalk’s system dictionary in which a compiled class is stored. 

FIGURE 14-2 Object model of the user interface 

The Interactive<strong>Sina</strong>Compiler provides the class method open to create the user 

interface. It can be opened by sending the message open to the class, after which the 

window of figure 14-3 appears on the screen. The window has four subviews. They are: 

• the source code view, where the user can edit and compile source code; 

• the category view, that corresponds to the category attribute; 

• the transcript view, where the compiler reports what it is doing; 

• the compilation messages view, that displays errors, warnings and informative 

messages from the compilation process. 

The Interactive<strong>Sina</strong>Compiler provides more (private) methods which are not 

described here. 

FIGURE 14-3 The user interface window 

category 

transcript 

compilation 

messages 

Interactive<strong>Sina</strong>Compiler 

source 

sourceFilename 

programNodeHolder 

mainMethod 

category 

¤ open 

Model 

14.3 Kernel 

The kernel of the <strong>Sina</strong>⁄st development environment consists of several classes which are 

necessary to execute a <strong>Sina</strong>⁄st application. Most of these classes have been explained in 

previous chapters of this thesis. They are 

• Abstract<strong>Sina</strong>Object, ObjectManager, MessageQueue; 


<strong>Sina</strong>Compiler 

source 

code 

129

130 

Process scheduling 

in Smalltalk 

• ActiveMessage, RecursiveActiveMessage, <strong>Sina</strong>Message; 

• <strong>Sina</strong>Object, ObjectWindow; 

• SelectorDictionary, Filter, and the hierarchy of filter handler classes. 

In addition to these classes, the kernel provides a preemptive process scheduler which is 

described below. 

Smalltalk facilitates the control of multiple independent processes [Goldberg83] 

[ParcPlace92a], but only provides non-preemptive scheduling of processes, which may 

cause a single process to monopolize the processor. As <strong>Sina</strong>⁄st allows multiple concurrent 

threads (processes) and we want to prevent this from happening, we present a preemptive 

process scheduler. 

A process represents a sequence of actions that can be carried out independently of actions 

represented by other processes. A Smalltalk process, represented by the class Process, 

can be assigned a priority which allows to differentiate important tasks (e.g. keyboard 

input) from less significant ones (e.g. background printing). A new process can be created 

by sending the message fork to a block closure, a sequence of actions (messages) between 

brackets []. 

In <strong>Sina</strong>⁄st , a thread is a sequence of actions (messages) which can execute concurrently 

with other threads. A thread is mapped to a Smalltalk process. Every <strong>Sina</strong>⁄st thread is 

assigned the priority called userScheduling-Priority. This is the same level at 

which in Smalltalk normal user interactions take place. 

A Smalltalk process can be in any of the four different states, suspended, waiting, 

runnable, or running. A running process, as the name indicates, is running on Smalltalk’s 

(virtual) Processor. As Smalltalk has a single Processor, only one process can be 

running. In the following four occasions the Processor reschedules the running process 

to give another process a chance to run: 

• if the running process terminates, i.e. when it executes its last action. The process will 

cease to exist; 

• if a process with a higher priority becomes runnable. The process will reoccupy the 

Processor if the higher priority process releases it, and there are no other runnable 

processes with a higher priority; 

• if the running process becomes suspended. This can happen when the running 

Process receives a suspend message either from itself, or another process3 . When 

it receives a resume message, its state changes to runnable again. 

• if the running process blocks on a semaphore. This can happen when it sends a wait 

message to the semaphore (instance of class Semaphore) for which there are no 

outstanding signal messages4 . The state of the blocked process becomes waiting. If 

another process sends a signal message to the semaphore, the process becomes 

runnable. 

The Processor chooses which of the runnable processes is allowed to run next. The 

highest priority process takes precedence over other processes. Of the processes with equal 

priority, the process that was rescheduled by a higher priority process, if any, is served 

next. Otherwise, equal priority processes are scheduled in the order in which they became 

runnable. 

Smalltalk’s scheduling system is non-preemptive, which means that the running process 

will not be rescheduled until one of the four events above occurs. If they never happen, the 

3. With a higher priority, see previous point. 

4. A process is blocked if it sends a wait message to the semaphore which did not receive a signal message 

yet. As the semaphore can receive more signal messages, a process which sends a wait to it is not 

blocked as long as there are ‘outstanding’ signal messages. 

Chapter 14: Programming environment

Preemptive process 

scheduler 

process monopolizes the Processor and does not give other runnable processes (of the 

same priority) a chance to run. In order to prevent this, each process must be suspended 

regularly 5 . The Processor provides the method yield for this which must be 

explicitly placed inside the (code of the) process at proper places. It is hard to decide 

where to put it, and additionally there is still the possibility that one process runs longer 

than another. 

Because in <strong>Sina</strong>⁄st there can be several process (all with the same priority 

userSchedulingPriority) which all must get an equal chance to run, we have 

designed preemptive process scheduler which allows each process an equal amount of 

time (a time-slice) to run before it is rescheduled. 

Preemptive scheduling works by having a process (the rescheduling process) that 

preempts the running userSchedulingPriority process every time-slice seconds 

(currently 300 milliseconds). The rescheduling process therefore suspends it, and resumes 

it immediately afterwards, so that it is placed at the back of the list of runnable processes 

of the same priority. The first process in this list thereupon starts to run. The rescheduling 

process works at userInterruptPriority level, which is higher than the 

userSchedulingPriority. In order not to monopolize the Processor, the 

rescheduling process suspends itself for time-slice seconds after it has performed a 

reschedule. With this, every runnable process gets an equal chance to run. 

The preemptive process scheduler is represented by the two classes 

RoundRobinScheduler and SystemScheduler (see figure 14-4). The latter 

provides behavior to install only a single scheduler (the global object called 

<strong>Sina</strong>Scheduler) in the <strong>Sina</strong>⁄st development environment, while its superclass 

implements the preemptive process scheduling (and is thus reusable for other 

applications). The method stop (temporarily) prevents processes from being preempted 

(thus reverting to Smalltalk’s non-preemptive scheduling), while the method start 

resumes it. 

FIGURE 14-4 Preemptive process scheduler. 

start 

stop 

RoundRobin- 

Scheduler 

This concludes the description of the <strong>Sina</strong>⁄st implementation. 

5. And be resumed, so that it remains runnable. 


SystemScheduler 

¤ install 

¤ schedulerName 

131

132 

Chapter 14: Programming environment

PART 


iv Evaluation and Conclusions 


134

Inconsistencies in the 

filter syntax and 

semantics 

15 Evaluation 

This chapter evaluates the work presented in this thesis. The discussion in is divided in two 

parts, the <strong>Sina</strong>⁄st language, and its implementation. 

15.1 <strong>Sina</strong>⁄st language 

We evaluate the <strong>Sina</strong>⁄st language from a programmers viewpoint, and ask ourselves the 

question if <strong>Sina</strong>⁄st contains any inconsistencies that may cause confusion, and secondly, 

which constructs, c.q. functions could be added to <strong>Sina</strong>⁄st to improve the language. 

The semantics of a programming language should conceptually be clear and unambiguous 

to the programmer. It may be confusing if a certain language construct behaves differently 

in comparable situations, or if some functionality is not provided. We identify the 

following three inconsistencies in the filter semantics (also described in [vDijk95]): 

• The new target object and selector that may yield from the accept test (see section 9.4, 

page 66) are used for different purposes by different filter handlers (section 9.6, 

page 69) 

The dispatch filter uses the new target as the object where to dispatch the message to, 

and the new selector to replace that of the accepted message. Similarly, the send filter 

uses both of them to replace the receiver and the selector of the message. The error 

filter also uses them to replace the receiver and the selector of the accepted message, 

but unlike the former two filters, the accepted message continues in the following filter, 

as the error filter causes an error on a rejected message. The dispatch, send and error 

filter thus effectively perform substitution on the message 1 . 

The meta filter uses the new target and selector as the receiver and selector of the ACT 

message which has the accepted, but reified message as argument. The wait filter, on 

the other hand, discards the new target and selector. These filter do not modify the 

accepted message. 

• As shown by the previous, three filter handlers have, in addition to their basic 

functionality, also a substitution functionality; 

• It is not possible to declare a meta filter that reifies only message which are supported 

by a single internal or external, i.e. messages that are in the signature of the object, and 

offer them to another (ACT) object; 

1. The new target and selector are for this reason also called the substitution target and selector. 

Evaluation and Conclusions 

135

136 

Useful extensions to 

<strong>Sina</strong>⁄st 

This is because it is not possible to specify the target and selector of the ACT message 

separately from the message matching: a signature pattern z.* would match the 

messages supported by z but the meta filter would offer the ACT message also to z, 

while a matching pattern [z.*]act.m only matches messages whose receiver is z. 

To overcome these problems we propose the following solutions (more extensively 

described in [vDijk95]): 

• Redefine the semantics of the various filter handlers, so that only the basic 

functionality of the filter remains. For the dispatch, send and error filter this means 

removing the substitution functionality; 

• The substitution functionality can be assigned to a new filter type, the substitution 

filter; 

• Identify for each filter what they require to perform their accept or reject actions, and 

introduce a new filter specification syntax which allows this to be specified. 

The dispatch filter only requires to know the object where to dispatch an accepted 

message. The meta filter requires a target object and a selector for the ACT message. 

The substitution filter needs to have a new target and selector to replace those of the 

accepted message. The send filter and the wait filter do not need extra information. An 

error filter does not need any information either, but the error filter could be extended 

to take for example the exception to be raised; 

A new filter syntax which adopts these changes has been described in [vDijk95] which 

also discusses more elaborately the inconsistencies and proposed solutions. 

In addition to the changes just described, we present a few extensions to the language we 

feel could improve the <strong>Sina</strong>⁄st language: 

• The possibility to use block closures, similar to those in found in Smalltalk. A block 

closure is an object that represents a deferred sequence of actions. The sequence of 

actions a block closure describes takes place when it receives a message to evaluate 

itself. Block closures would make it less troublesome to apply Smalltalk’s library of 

Collection classes, as they use a block closure for their iteration. 

• An ACT can restart a reified message, by using one of the dereification messages 

continue (synonym for fire), reply or send, but it cannot abort a reified message and 

thus return an error to the sender of the message. 

• An exception handling mechanism would be useful to handle and respond to errors that 

occur at run-time. 

15.2 <strong>Sina</strong>⁄st implementation 

<strong>Sina</strong>⁄st has been implemented in Smalltalk according to part III of this thesis. We 

summarize the limitations of the implementation, the problems we have encountered and 

the bugs that are known at this moment. Finally, we compare the performance of the 

<strong>Sina</strong>⁄st implementation with Smalltalk. 

15.2.1 Limitations 

The <strong>Sina</strong>⁄st implementation has the following limitations: 

• It does not provide type checking. 

• Full scope rules have not been implemented. This means that the externals can only be 

global objects and not internals of an encapsulating object. 

• The real-time filter is not provided. 

• Data-base functionalities have not been implemented. Associative object access as 

described in [Aksit92] is thus not possible. 

Chapter 15: Evaluation

15.2.2 Encountered problems 

In part III, ‘Implementation of the <strong>Sina</strong>⁄st language’, we discovered a number of problems 

related to signature of an object. They are summarized here. 

• We cannot detect, or only with great effort, if an ACT affects the signature of an object. 

• Although a message can be included in the signature of an object, this does not mean 

that the object at one moment supports a certain message. This can happen if at that 

moment the conditions in the dispatch filters of the object have values which prevent 

the message from being dispatched. 

The cause is that the signature of an object is based on the operations it supports 

(directly or indirectly) irrespective of the values of the conditions. A solution to this 

problem requires a more accurate definition of the signature. The conditions should be 

considered when a dispatch filter has to decide to dispatch a message to a certain target 

object. With a careful design, this should not need unnecessary condition evaluations. 

Note that a similar situation can occur if a message is delayed by a wait or meta filter. 

However, this is caused by the application because the state of the object changed has 

changed in between. The application (i.e. programmer) should take precautions to 

prevent this. 

• The current signature definition does not consider the number of arguments and the 

type of arguments of a message. If type checking is implemented this should, be 

supported as well. 

15.2.3 Known bugs 

Synchronization of messages by the wait filter still causes problems. The object manager 

reevaluates the conditions of blocked messages to see if they can be restarted. Under 

certain conditions 2 , more than one message is restarted, although the application only 

allows one to be restarted. This can cause a chain of blocked messages that are restarted. 

The likely origin of this problem is the mutual exclusion of the reevaluation process. 

Although we implemented this in a way which does not allow more than one thread 

(process) to evaluate the conditions, we did not prevent another thread to change the 

conditions 3 while a reevaluation is in progress. The object manager may erroneously 

decide to restart the message. It requires further research on how to prevent this from 

happening. 

15.2.4 Performance comparison 

Although performance was not the focus of this thesis, we have made a comparison of the 

<strong>Sina</strong>⁄st implementation with Smalltalk in order to identify any bottlenecks in the execution. 

We compare the performance of <strong>Sina</strong>⁄st implementation with Smalltalk by measuring the 

execution times of a single message send. The message does not have any arguments and 

invokes a method that returns nil. We make a difference between the case in which a local 

method is invoked, and if a ‘superclass’ method is invoked. For Smalltalk, this means a 

method of the direct superclass of the receiving object, while for <strong>Sina</strong>⁄st the message is 

dispatched to an internal object representing the superclass. This shows us the overhead of 

message dispatch of <strong>Sina</strong>⁄st in comparison with Smalltalk’s method lookup (in the class 

hierarchy). 

Further, the receiving <strong>Sina</strong>⁄st object and its internal both have one filter, a dispatch filter, 

which does not have a condition. The message invoking the local method thus has to pass 

through one filter, and the message invoking the superclass method must pass two dispatch 

filters. 

2. Which we experienced when we tested the BoundedBuffer example, example 9-5 on page 70. 

3. Actually the state of an object, which is read by the conditions. 


137

138 

In Smalltalk, a message send is handled by Smalltalk’s virtual machine, but the <strong>Sina</strong>⁄st 

implementation creates a new object (an ActiveMessage instance) for each message 

which is sent. To compare this with a similar situation in Smalltalk, we additionally timed 

message sending in which each message is represented by a newly created object. Such a 

message is represented in Smalltalk by the class MessageSend. This message invokes 

the local method or the superclass method, in the same way as the plain Smalltalk message 

send. 

We have carried out the performance test on a Sun SPARCstation 10, and to avoid 

overhead of the preemptive process scheduler (section 14.3, page 129), it has been 

disabled. Table 15-1 presents the actual running times, for a single message send. The first 

column shows the results of a <strong>Sina</strong> message send, the middle column displays the plain 

Smalltalk message send, while the last column presents the Smalltalk message send 

represented by a newly created MessageSend object. The table shows that there is not a 

measurable difference between the invocation of a local and a superclass method, in both 

the Smalltalk versions. In the <strong>Sina</strong>⁄st implementation, however, dispatching the message to 

the internal representing the superclass costs an additional 0.26 milliseconds, which is 

about one third of a message send invoking the local method. 

TABLE 15-1 Raw running times for a single message send 

<strong>Sina</strong> (ms) Smalltalk (ms) 

Smalltalk with 

MessageSend 

(ms) 

Local message 0.74 0.00030 0.015 

Superclass message 1.0 0.00030 0.015 

The entries in the following table are the ratios of the running times of the benchmarks for 

a given pair of systems. The first column shows that the <strong>Sina</strong>⁄st implementation is 

considerably slower than plain Smalltalk. This is partially caused by the creation of a 

message object for each message that is sent, and partially due to the filtering process. The 

second column compares <strong>Sina</strong>⁄st with Smalltalk which creates a message object for a 

message send, similar to the <strong>Sina</strong>⁄st implementation. This shows that <strong>Sina</strong>⁄st is a factor 50 

to 60 slower, which is caused by the filtering process. The last column displays the effect 

of message object creation, as it compares plain Smalltalk with the version that does create 

a message object. If we elimininate the creation of a message object for each message 

send, then the performance can be improved with a factor 50. 

TABLE 15-2 Relative performance 

We are not surprised by the relative performance of <strong>Sina</strong>⁄st , as the message object creation 

is likely to cause a considerable overhead. Additionally, the filtering process has been 

implemented with the aid of various Smalltalk methods which all must be executed. We 

expect that the following points would improve the performance of <strong>Sina</strong>⁄st : 

• We should eliminate the creation of a message object each time a message is sent. This 

could be realized by implementing <strong>Sina</strong>⁄st in a stack-oriented way, comparable to many 

programming languages, including Smalltalk. 

In this stack-based implementation, the arguments of a message, its receiver, sender 

and selector are pushed onto an execution stack. Each filter thus would need to access 

the stack in order to decide to accept or reject the message. A method reads its 

arguments from the stack and pops them of the stack to replace it with the reply object 

if it finishes. 

Chapter 15: Evaluation 

<strong>Sina</strong> / Smalltalk 

Smalltalk w. 

MessageSend / 

<strong>Sina</strong> / Smalltalk w. MessageSend Smalltalk 

Local message 2.5 × 103 49 50 

Superclass message 3.3 × 10 3 66 50

• The filtering process causes an additional overhead and should be optimized to reduce 

this. We already applied an optimization, by considering for each filter which 

conditions need to be evaluated for each possible message that is filtered. 

We could optimize this further: instead of generating evaluation code for each filter 

separately, we should consider a filter group in total, and track down the possible 

path(s) a message follows through this group. The accept or reject action of each filter 

could be inlined in the constituting the filtering process for a single message. There is 

one difficulty with this approach: if a message passes a meta filter, we cannot be sure 

that the message is in the same state as before. An ACT could for example change the 

selector, after which the pathe of the message through the filters cannot be determined. 

• Additionally, the condition evaluation algorithm of [Bergmans94] can be applied to 

reduce the frequency of condition evaluation and minimizes the computational costs 

involved in the evaluation. 


139

140 

Chapter 15: Evaluation

16 Conclusions 

This chapter gives a brief overview of the work that has been presented in this thesis, the 

contributions we made, and future directions of research. 

16.1 Overview and contributions 

We follow the structure of this thesis and discuss the material in part II, ‘Definition of the 

<strong>Sina</strong>⁄st language’, and part III, ‘Implementation of the <strong>Sina</strong>⁄st language’. 

16.1.1 Definition of the <strong>Sina</strong>⁄st language 

In chapters 2 to 10 we have laid down the definition of the <strong>Sina</strong>⁄st language, by describing 

its syntax and semantics in an informal way. To illustrate the <strong>Sina</strong>⁄st language, we 

presented numerous examples. 

Smalltalk classes and objects can be used in <strong>Sina</strong>⁄st as if they are <strong>Sina</strong>⁄st classes c.q. 

objects. As <strong>Sina</strong>⁄st incorporates the composition filters object model, it can solve a number 

of software modelings problems described in chapter 1. 

Chapter 10 described message reification through a meta filter, which allows an 

application to reflect on the message communication between two objects. The meta filter 

reifies the message and offers it to an ACT object, which dereifies the message after it 

processed it. We introduced a new dereification method, called send, which allows the 

ACT to regain control over the message as soon as the reply object becomes available for 

it. The ACT thus obtains the reply of the message, and has even the possibility to replace it 

with another. With the two other dereification methods, continue (synonym for fire) and 

reply, the message follows its normal course, without the ACT taking control over the 

message or acquiring the reply of it. 

16.1.2 Implementation of the <strong>Sina</strong>⁄st language 

In chapters 11 to 14 we have shown how <strong>Sina</strong>⁄st can be implemented in Smalltalk. 

Chapter 12 described the execution model by following a message from the moment it is 

sent, through being filtered, to the moment of method invocation. 

We use a first-class representation for an active message which allows filters to access the 

attributes of the message easily when they filter the message. 


141

142 

If a filter filters a message it must decide whether to accept or to reject the message by 

evaluating the filter initializer. This message accept test, according to its definition, 

considers each filter element in turn by evaluating the conditions, matching the selector, 

etc. To avoid unnecessary evaluation of conditions in the filter initializer (i.e. if the selector 

of the message does not match the one in the filter element), we introduced an algorithm 

which extracts from the filter initializer the conditions to be evaluated for a selector, and 

for that selector only. 

A filter is accordingly represented as a selector dictionary which is a hash table that 

contains for each selector a code block embodying the conditions to be evaluated. The 

accept test consequently consists of retrieving the code block corresponding to the selector 

of the message and evaluating this code block. The code block is also used when a 

message is blocked by a wait filter. The code block is stored along with the message when 

it blocks. In order to see if the message can be restarted, it is reevaluated when a state 

change affecting the conditions occurs. 

The implemented signature matching scheme recognizes dynamic changes in the signature 

of an object. 

The implementation provides five types of filter handler: dispatch filter, error filter, send 

filter, wait filter, and meta filter. The accept and reject actions of these filter handlers are 

straightforward, and are implemented without difficulty. 

The object manager keeps track of the active methods of an object, which means that its 

state must be updated whenever a method is invoked or finishes. With method invocation 

we must make a distinction between normal and early returning methods. An early 

returning method creates a new concurrent thread which allows it to continue executing 

after it returned a reply object to the sender. We have mapped a <strong>Sina</strong>⁄st thread to a 

Smalltalk process. 

A new concurrent thread is also created when a meta filter accepts a message, reifies it, and 

offers it to an ACT object. A reified message provides three methods to dereify it, 

continue, reply and send. We have shown how these methods can be implemented. 

Synchronization in <strong>Sina</strong>⁄st is realized with a wait filter which blocks a message when it 

rejects it. The object manager is responsible to reevaluate the conditions on which the 

message blocked to see if it can be restarted. The object manager performs this 

reevaluation whenever its state changes, that is, when a method starts or finishes, or when 

a message blocks by a wait filter. This is not sufficient, since the state of the object 

manager is only a part of the total state of the owning object. A reevaluation should be 

done whenever a state changes. The algorithm described in [Bergmans94] can be used to 

find the locations where state changes occur. 

Chapter 12 ends by describing how Smalltalk classes and objects are able to handle <strong>Sina</strong>⁄st 

messages, thus making it possible to use Smalltalk’s class library to be used in a <strong>Sina</strong>⁄st 

application. 

In chapter 13 we defined how a <strong>Sina</strong>⁄st object can be translated to Smalltalk. This mapping 

is used by the compiler when it generates Smalltalk code from <strong>Sina</strong>⁄st source code. 

Additionally, we described how we can detect whether a method is a normal or an early 

returning method. 

Finally, chapter 14 outlines the <strong>Sina</strong>⁄st programming environment which we have 

implemented. The environment is composed of the user interface that allows the user to 

edit, compile and execute a <strong>Sina</strong>⁄st application, the compiler that translates <strong>Sina</strong>⁄st source 

code to Smalltalk according to the mapping defined in chapter 13, and a kernel for runtime 

support. The kernel contains the various classes necessary to execute a <strong>Sina</strong>⁄st 

application, and additionally, a preemptive process scheduler that prevents Smalltalk’s 

non-preemptive processes to monopolize the Smalltalk Processor. 

Chapter 16: Conclusions

16.2 Conclusions 

In this thesis we have presented the definition and an implementation of the <strong>Sina</strong>⁄st 

language. <strong>Sina</strong>⁄st has been implemented in Smalltalk and consists of a programming 

environment, which allows the user to edit, compile and execute a <strong>Sina</strong>⁄st application. 

The implementation provides the most interesting aspects of the composition filters object 

model. It provides the five major filters, which allows us to demonstrate the power of the 

composition filters object model. The filters included are the dispatch filter, the error filter, 

the send filter, the wait filter, and the meta filter. Further, the implementation provides 

concurrency and synchronization. 

The implementation, however, does not provide type checking, neither does it implement 

full scope rules. The real-time filter has been omitted and so are atomic transactions and 

database functionalities for associative object access. 

We have come up with a representation for messages and filters which allows an easy 

implementation of the filtering process. Filters are able to reflect on messages (system 

level reflection), and applications can use a meta filter to reflect on the communication 

between objects (application level reflection). We introduced a new dereification method 

which allows an ACT to regain control on a reified message when it obtains a reply. 

Finally, we have evaluated the <strong>Sina</strong>⁄st language and the composition filters object model. 

We have proposed a number of improvements to the <strong>Sina</strong>⁄st language in general, and to the 

syntax and semantics of composition filters. 

16.3 Future work 

<strong>Sina</strong>⁄st has not reached its final state. Although we have established the feasibility of the 

composition filters object model and the <strong>Sina</strong>⁄st implementation, much work remains. This 

work can be categorized in bug fixes, implementation refinements, language 

improvements, and implementation optimizations. 

Bugs and problems The implementation has the following bugs and problems that need to be fixed: 

Making the <strong>Sina</strong>⁄st 

implementation 

complete 

Improvements to the 

language 

• The synchronization bug, which causes under certain conditions blocked messages to 

be restarted while this is not allowed. 

• The signature matching problem, which can cause a message to be dispatched to an 

object (because it is in its signature), but this object is unable to dispatch it further 

because conditions of its filters prevent this. 

• Condition reevaluation not only when the state of the object manager changes, but 

when any state changes. 

A number of aspects of the <strong>Sina</strong> language were not addressed by this thesis. To provide a 

full implementation of <strong>Sina</strong>, it needs to be extended with: 

• Type checking, and additionally signature matching which considers type information. 

• Full scope rules which do not restrict external objects to be global objects only. 

• Atomic transactions and database functionalities for associative object access. 

• Real-time filter and real-time scheduling. 

The evaluation of the <strong>Sina</strong>⁄st language discovered the following extensions and 

improvements: 

• New filter syntax and semantics, including the substitution filter. 

• Extension of <strong>Sina</strong>⁄st with block closures. 

• An exception handling mechanism which allows to respond to run-time errors. 

• Message dereification which allows a message to be aborted. 


143

144 

Optimizations The performance of the implementation presented in this thesis can be enhanced by: 

• Caching the signature of an object. 

• Further optimizing the message filtering process. 

• A stack-based implementation, to eliminate the creation of a message object each time 

a message is sent. 

Of this list, optimizations, type checking, real-time aspects, atomic transactions and 

database functionalities are the most interesting topics for future research. 

Chapter 16: Conclusions

PART 

v Appendices 



146

APPENDIX 

A <strong>Sina</strong> Class Interfaces 

A.1 <strong>Sina</strong>Object 


class <strong>Sina</strong>Object interface 

comment 

‘This class implements default behaviour.’; 

methods 

//-----window access 

print(s : String) returns nil; 

// Print the argument on my window. When the window was not opened yet, 

// it will be opened. 

printLine(s: String) returns nil; 

// Print the argument on my window followed by a CR. When the window 

// was not opened yet, it will be opened. 

cr returns nil; 

// Print a newline character on my window. When the window was not 

// opened yet, it will be opened. 

tab returns nil; 

// Print a tab character on my window. When the window was not opened 

// yet, it will be opened. 

openWindow returns nil; 

// Open or reopen my window. 

//-----error generation 

error(errorString : String) returns nil; 

// Generate an error. 

// The argument will be displayed on my window. Then, the thread that 

// invoked this method will be aborted. 

//-----dialogs 

warn(warning : String) returns nil; 

// Display a warning message. 

// Opens a dialog window displaying the argument; this method finishes 

// when the user hits the ‘ok’ box or types cr in the window. 

request(prompt : String) returns String; 

// Request a String to be typed from the keyboard. 

// Opens a dialog window displaying the argument; the user then has to 

// enter a String until he types cr; this method then answers the String 

// entered by the user. 

//-----string conversion 

toString returns String; 

// Answer a String whose characters are a description of the server. 

//-----class membership 

class returns Class; 

// Answers the class of the server. 

//-----inspecting 

inspect returns server; 

// Create an Inspector window on the server in which the user can examine 

// the server’s variables. 

//-----testing 

On the Definition and Implementation of the <strong>Sina</strong>/st language 

147

148 

isNil returns Boolean; 

// Tests if the server is the nil object: since this is not the case, this 

// method always returns false. 

notNil returns Boolean; 

// Tests if the server is not the nil object: since this is not the case, this 

// method always returns true. 

//-----comparing 

equal(anObject : Any) returns Boolean; 

// Answer whether the server and the argument represent the same 

// object, that is, have the same value. 

unequal(anObject : Any) returns Boolean; 

// Answer whether the receiver and the argument do not represent 

// the same object. 

// This method implemented as 

// return server.equal(anObject).not 

same(anObject : Any) returns Boolean; 

// Answer true if the server and the argument, anObject, are the same 

// object (have the same object pointer) and false otherwise. 

different(anObject : Any) returns Boolean; 

// Answer true if the server and the argument, anObject, are not the 

// same object (have the same object pointer) and false otherwise. 


// return server.same(anObject).not 

inputfilters 

myBehavior : Dispatch = {inner.*} 

end; // interface of class <strong>Sina</strong>Object 

A.2 ActiveMessage 


class ActiveMessage interface 

comment 

‘This class represents an active message, that is, a message that is executing. 

Attributes of an active message include: 

- selector 

- arguments 

- sender 

- server 

- receiver’; 

methods 

//-----accessing attributes 

sender returns Any; 

// Answers my sender object. 

server returns Any; 

// Answers my server object . 

receiver returns Any; 

// Answers my receiver object. 

selector returns String; 

// Answers my selector. 

numArgs returns SmallInteger; 

// Answers the number of my arguments. 

args returns Array; 

// Answers an array containing my arguments. 

argsAt(n : SmallInteger) returns Any; 

// Answers my n’th argument. 

//-----testing 

isRecursive returns Boolean; 

// Answers whether this message is a recursive message, i.e. a message 

// sent to self, server or sender. 

argsOfAtEqual(sel : String; i : SmallInteger; anObject : Any) returns Boolean; 

// Answer true if my selector is ‘sel’ and my i’th argument is equal to 

// ‘anObject’. This method is implemented as: 

// return self.selector = sel and self.argsAt(i) = anObject 

Appendix A: <strong>Sina</strong> Class Interfaces

isNil returns Boolean; 

// Tests if the server is the nil object: since this is not the case, this 

// method always returns false. 

notNil returns Boolean; 

// Tests if the server is not the nil object: since this is not the case, this 

// method always returns true. 

//-----comparing 

equal(anObject : Any) returns Boolean;. 

// Answer whether the receiver and the argument represent the same 

// object. 

unequal(anObject : Any) returns Boolean; 

// Answer whether the receiver and the argument do not represent 

// the same object. 


// return not server.equal(anObject) 

same(anObject : Any) returns Boolean; 

// Answer true if the server and the argument, anObject, are the same 

// object (have the same object pointer) and false otherwise. 

different(anObject : Any) returns Boolean; 

// Answer true if the server and the argument, anObject, are not the 

// same object (have the same object pointer) and false otherwise. 


// return not server.same(anObject) 

//-----class membership 

class returns Class; 

// Answers the class of the server. 

inputfilters 

myBehavior : Dispatch = {inner.*}; 

end; // interface of class ActiveMessage 

A.3 <strong>Sina</strong>Message 


class <strong>Sina</strong>Message interface 

comment 

‘This class represents a reified message. It inherits the behavior from class 

ActiveMessage and adds behavior for changing the message’s attributes 

and for dereification’; 

internals 

activeMessage : ActiveMessage; 

methods 

//-----dereification 

continue returns nil; 

// Causes me to be (re)activated. Does not wait for my reply. 

fire returns nil; 

// Same as the method ’continue’: causes me to be (re)activated. 

// Does not wait for my reply. 

send returns Any; 

// Causes me to be (re)activated. Waits until I have received a reply. 

// Answers my reply. 

sendContinue returns Any; 

// Causes me to be (re)activated. Waits until I have received a reply. 

// Then, I will be reactivated a second time. Answers my reply. 

// In fact, the message expression 

// result := aMsg.sendContinue; 

// is equivalent to 

// result := aMsg.send; aMsg.continue; 

reply(anObject : Any) returns nil; 

// Returns anObject as the reply to the sender of myself. 

//-----copying 

copy returns <strong>Sina</strong>Message; 

// Answers a copy of myself, which has the same selector, server, 

// receiver and arguments as me, but who’s sender is undefined (nil). 


149

150 

//-----changing message attributes 

setSender(senderObject :Any) returns nil; 

// Changes my sender to be the argument, senderObject. 

setServer(serverObject : Any) returns nil; 

// Changes my server to be the argument, serverObject. 

setReceiver(receiverObject : Any) returns nil; 

// Changes my receiver to be the argument, receiverObject. 

setSelector(selector : String) returns nil; 

// Changes my selector to be the argument, selector. 

setArgs(args : Array) returns nil; 

// Changes my arguments to be the argument, args. 

argsAtPut(n : SmallInteger; anObject : Any) returns nil; 

// My n’th argument will become the argument, anObject. 

inputfilters 

myBehavior : Dispatch = {activeMessage.*, inner.*}; 

end; // interface of class <strong>Sina</strong>Message 

A.4 ObjectManager 


class ObjectManager interface 

methods 

active returns SmallInteger; 

// Answers the number of active method invocations in the object . 

activeForMethod(selector : String) returns SmallInteger; 

// Answers the number of active invocations of the method given by 

// the argument . 

blockedReq returns SmallInteger; 

// Answers the number of messages that have been blocked by an 

// input wait filter. 

blockedInv returns SmallInteger; 

// Answers the number of messages that have been blocked by an 

// output wait filter 

inputfilters 

myBehavior : Dispatch = {inner.*}; 

end; // interface of class ObjectManager 

Appendix A: <strong>Sina</strong> Class Interfaces

APPENDIX 

B Using Smalltalk 

classes in <strong>Sina</strong>⁄st 

B.1 <strong>Sina</strong>⁄st variable declaration using a Smalltalk class 

A variable v that is declared with the <strong>Sina</strong>⁄st variable declaration v : C; will have an initial 

value (an object) assigned to it. This initial value will be an instance of the class C. 

Table B-1 lists the initial values for some Smalltalk classes.When the class C is not listed 

in this table and C is a Smalltalk class, it will be initialized according to table B-2. 

TABLE B-1 Initial value of the variable v in the variable declaration v : C; a . 

Class C Initial value of v Class of v 

Number 0 SmallInteger 

Fraction 0/1 Fraction 

Integer 0 LargePositiveInteger 

LargeNegativeInteger 0 LargePositiveInteger 

LargePositiveInteger 0 LargePositiveInteger 

SmallInteger 0 SmallInteger 

LimitedPrecisionReal 0 SmallInteger 

Double 0.0d Double 

Float 0.0 Float 

Point 0@0 Point 

Character Character 

value: 0 

Character 

Boolean false False 

True true True 

False false False 

UndefinedObject nil UndefinedObject 

a. Note, that sometimes the class of v is not C. This is because instances of subclasses of 

ArithmeticValue will be created and initialized with the Smalltalk message zero. These 

subclasses include Number, LimitedPrecisionReal, Double, Float, 

Fraction, Integer, SmallInteger, LargeNegativeInteger, 

LargePositiveInteger and Point. 

TABLE B-2 <strong>Sina</strong> variable declaration using a Smalltalk class C 

<strong>Sina</strong> variable declaration Smalltalk equivalent 

v : C; v := C new. 

v : C(Expr); v := C new: Expr. 


151

152 

TABLE B-2 <strong>Sina</strong> variable declaration using a Smalltalk class C 

<strong>Sina</strong> variable declaration Smalltalk equivalent 

v : C(Expr1, Expr2, ..., ExprN); v := C new: Expr1 with: Expr2 

... with: ExprN. 

v : C keyw; v := C keyw. 

v : C keyw1:...keywN:(Expr1, ..., ExprN); v := C keyw1: Expr1 ... keywN: 

ExprN. 

Examples: 

<strong>Sina</strong> 

n : SmallInteger; 

point1 : Point; 

point2 : Point x:y:(260,435); 

arr1 : Array; // size not specified 

arr2 : Array(n+2); // initial size given 

arr3 : Array with:with:with:(3, ’ element’, ’array’); //initialized array 

arr4 : TypedArray(6,SmallInteger); // this class has not been defined 

today : Date today; 

circle : Circle center:radius:(point2, 50); 

Smalltalk 

n := 0; 

point1 := 0@0; 

point2 := Point x: 260 y: 435. 

arr1 := Array new. 

arr2 := Array new: n+2. 

arr3 := Array with: 3 with: ’element’ with: ’array’. 

arr4 := TypedArray new: 6 with: SmallInteger. 

today := Date today. 

circle := Circle center: point2 radius: 50. 

B.2 Smalltalk selectors 

Smalltalk provides three types of selectors 

• unary, consisting of alpanumeric characters only, eg. today; 

• binary, consisting of one or two non-alphanumeric characters, eg. +; 

• and keyword, consisting of a sequence of alphanumeric characters plus a 

colon, eg. center:radius:. 

In <strong>Sina</strong>⁄st , a selector is allowed to consist of alphanumeric or colon characters 

only. Therefore, Smalltalk unary and keyword selectors can be used in <strong>Sina</strong>⁄st 

unchanged, but binary selectors must be converted to an equivalent selector as 

listed in the center column of table B-3. Alternatively, you can use an operator 

expression with an operator shown in the right column. 

Appendix B: Using Smalltalk classes in <strong>Sina</strong>⁄st

TABLE B-3 Smalltalk binary selectors and their equivalents in <strong>Sina</strong>/st 

For the Smalltalk selector Use the <strong>Sina</strong> selector 

arithmetic 

Or use an operator 

expression with the <strong>Sina</strong> 

operator 

+ plus + 

- minus - 

* times * 

/ divide / 

// div div 

\\ mod mod 

negated negated 

logical 

- 

& and and 

| or or 

not not 

comparing 

not 

> greater > 

>= atleast >= 

< less < 

154 

Appendix B: Using Smalltalk classes in <strong>Sina</strong>⁄st

APPENDIX 

C <strong>Sina</strong>⁄st syntax 

definition 

This appendix contains the syntax definition of <strong>Sina</strong>⁄st in a notation used by the scanner 

and parser generator tool T-gen [Graver92a][Graver92b]. It is comprised of a token class 

specification and a grammar specification. 

The token class specification is a sequence of token class definitions. A token class is 

defined by its token class terminal, a colon (:), a regular expression, an optional scanner 

directive between curly braces ({}), and a terminating semicolon (;). 

The grammar specification is a sequence of production rule specifications similar to those 

used by YACC [Johnson75]. A production rule consists of a nonterminal, called the lefthand 

side of the production, followed by a colon (:), one or more right-hand side 

specifications separated by vertical bars (|), and is terminated by a semicolon (;). A righthand 

side specification is a sequence of terminals and nonterminals, and is optionally 

followed parser directive between curly braces ({}). A terminal is either a token between 

single quotes (‘’), or a token class. The parser directive is a translation symbol, which is 

either a Smalltalk identifier or a message selector, and is used to construct a parse tree node 

for its associated production rule. 

Parse trees building A parse tree consist of nodes where each node is an instance of a (subclass of) 

<strong>Sina</strong>ParseTreeNode. Each node can have zero or more child nodes. The parser directive of 

the right-hand side of a production rule specifies the node returned after the rule, and the 

rules of its associated nonterminals have been processed. 

There are two types of parser directives used toe specify the result node of a production 

rule. If the directive is a capitalized Smalltalk identifier then it is interpreted as a class 

name, typically a subclass of <strong>Sina</strong>ParseTreeNode. An instance of the corresponding class 

is created, with the nodes associated with the right-hand side nonterminals as children. 

The second form of parser directive represents a Smalltalk message selector. These can be 

one of the predefined message selector or a user-defined selector. The predefined selectors 

include nil, liftRightChild and liftRightChild. The nil directive associates nil (the empty node) 

with the left-hand side of the production rule. The liftLeftChild directive instructs the parse 

tree building process not to construct a new node, but instead to return the node associated 

with the first nonterminal and the nodes of the following nonterminals as its children. The 

liftRightChild directive similarly returns the node associated with the right-most 

nonterminal with the preceding nonterminal nodes as its children. 

User-defined parser directives (message selectors) require to accept the same number of 

arguments as there are nonterminals in the right-hand side of the corresponding production 

rule. A message with the designated selector, and the nodes associated with the right-hand 

side nonterminals as arguments, will be sent to the tree builder, an instance of class 

<strong>Sina</strong>Builder. The result of the corresponding <strong>Sina</strong>Builder method will be returned as result 

node of the associated production rule. In the grammar specification we have indicated 

between double quotes (“”) the class of the object which this method returns. 


155

Appendix C: <strong>Sina</strong>⁄st syntax definition 

C.1 Token class specification 

“--------------------------------------------- 

Revision date: 3 June 1994 

--------------------------------------------- 

Notes: 

- Use FSABasedScannerWithOneTokenLookahead in order to 

be able to distinguish a floating point dot from a message dot 

Eg. 3.0.negated and 3.negated 

- Identifiers are not allowed to have _-characters in them. 

- 7 February 1994: added 

- 3 June 1994: added 

---------------------------------------------” 

 

: [A-Za-z][A-Za-z0-9]* 

; 

 

: ([A-Za-z][A-Za-z0-9]*\:)+ 

; 

 

: \-?[0-9]+( 

((\.[0-9]+)([de][\+\-]?[0-9]+)?) 

| e[\+\-]?[0-9]+)? 

; “[0-9]+(\.[0-9]+)?(e[\+\-]?[0-9]+)?” 

 

: ‘(~[‘] | [\t\r\n] | ‘’)*’“Do not compactDoubleApostrophes” 

“An empty string ‘’ would become a single qoute” 

“Compaction of double apostrophes is done in” 

“the method <strong>Sina</strong>Builder>>as<strong>Sina</strong>String:.” 

; 

 

: $[\t\r\n\s-\~] 

; 

 

: [\s\t\r]+ {ignoreDelimiter} 

; 

 

: // (\t | [\s-\~])*[\r \n]{ignoreComment} 

; 

C.2 Grammar specification 

“--------------------------------------------- 

This is the <strong>Sina</strong> grammar specification augmented with 

parser directives 

--------------------------------------------- 

Revision date: 3 June 1994 

Grammar status: LALR(1) 

--------------------------------------------- 

Notes: 

- The interface, implementation or method commenttext must 

be placed between two ’-characters. 

---------------------------------------------” 

“----------------Program-------------------” 

sinaProgram 

: classDeclarations mainOPT 

{classDecls:main:} 

“a <strong>Sina</strong>ProgramNodeHolder” 

| main 

{main:} 

“a <strong>Sina</strong>ProgramNodeHolder” 

; 

classDeclarations 

: classDeclaration 

{<strong>Sina</strong>ClassDeclarations} 

| classDeclarations classDeclaration 

{liftLeftChild} 

; 

classDeclaration 

: classInterface classImplementation 

{interface:implementation:} 

“a <strong>Sina</strong>ClassNode” 

; 

“----------------Class interface-------------------” 

classInterface 

: classSwitches 

‘class’ className classParameters ‘interface’ 

comment 

externalsPart 

internalsPart 

conditionDeclarationsPart 

methodDeclarationsPart 

inputfiltersPart 

outputfiltersPart 

‘end’ ‘;’ 

{<strong>Sina</strong>InterfaceNode} 

; 

externalsPart 

: “empty” 

{<strong>Sina</strong>ObjectDeclarations} 

“i.e. an empty collection” 

156


| ‘externals’ objectDeclarations 

; 

internalsPart 

: “empty” 



| ‘internals’ objectDeclarations 

; 

conditionDeclarationsPart 

: “empty” 

{<strong>Sina</strong>ConditionDeclarations} 


| ‘conditions’ conditionDeclarations 

; 

methodDeclarationsPart 

: “empty” 

{<strong>Sina</strong>MethodDeclarations} 

“i.e. an empy collection” 

| ‘methods’ methodDeclarations 

; 

inputfiltersPart 

: “empty” 

{<strong>Sina</strong>Filters} 


| ‘inputfilters’ filterDeclarations 

; 

outputfiltersPart 

: “empty” 



| ‘outputfilters’ filterDeclarations 

; 

“----------------Class implementation-------------------” 

classImplementation 

: ‘class’ className ‘implementation’ 

comment 

instvarsPart 

conditionsPart 

initialMethod 

methodsPart 

‘end’ ‘;’ 

{<strong>Sina</strong>ImplementationNode} 

; 

instvarsPart 

: “empty” 



| ‘instvars’ objectDeclarations 

; 

conditionsPart 

: “empty” 

{<strong>Sina</strong>Conditions} 


| ‘conditions’ conditionImplementations 

; 

initialMethod 

: “empty” 

{nil} 

| ‘initial’ methodBody ‘;’ 

; 

methodsPart 

: “empty” 

{<strong>Sina</strong>Methods} 


| ‘methods’ methodImplementations 

; 

“----------------Main-------------------” 

mainOPT 

: “empty” 

{nil} 

| main 

; 

main 

: ‘main’ 

comment 

externalsPart 

tempsPart 

‘begin’ 


‘end’ 

{main:externals:temps:statements:} 

; 

“----------------Classes-------------------” 

className 

: 

{asIdentifier:} 

; 

classParameters 

: “empty” 



| ‘(‘ parameterObjectDeclarations ‘)’ 

; 

157


“classDescriptions 

: classDescription 

{<strong>Sina</strong>ClassDescriptions} 

| classDescriptions ‘;’ classDescription 


;” 

classDescription 

: className classConstructor classArguments 

{classDescription:constructor:arguments:} 

“a <strong>Sina</strong>ClassDescriptionNode” 

; 

classConstructor 

: “empty” 

{nil} 

| selector 

; 

classArguments 

: “empty” 

{<strong>Sina</strong>Expressions} 

“i.e. empty collection” 

| ‘(‘ expressions ‘)’ 

; 

“----------------Conditions-------------------” 

conditionName 

: 


; 

conditionDeclarations 

: “conditionDeclaration ‘;’” 

{<strong>Sina</strong>ConditionDeclarations} 

| conditionDeclarations conditionDeclaration ‘;’ 


; 

conditionDeclaration 

: conditionName associativeParameter 

{conditionDecl:parameter:} 

| objectName ‘.’ conditionName 

{object:conditionDecl:} 

; 

conditionImplementations 

: “empty” 

{<strong>Sina</strong>Conditions} 


| conditionImplementations conditionImplementation ‘;’ 


; 

conditionImplementation 

: conditionName conditionParameter methodBody 

{condition:parameters:body:} 

“a <strong>Sina</strong>ConditionImplementationNode” 

; 

conditionParameter 

: “empty” 



| ‘(‘ singleObjectDeclaration ‘)’ 

“a <strong>Sina</strong>ObjectDeclarations” 

; 

“----------------Filters-------------------” 

filterName 

: 


; 

filterDeclarations 

: “filterDeclaration ‘;’” 


| filterDeclarations filterDeclaration ‘;’ 


; 

filterDeclaration 

: filterName ‘:’ filterHandler ‘=’ ‘{‘ filterElements ‘}’ 

{filter:handler:elements:} 

| objectName ‘.’ filterName 

{object:filter:} 

; 

filterHandler 

: 


; 

filterElements 

: filterElement 

{<strong>Sina</strong>FilterElements} 

| filterElements ‘,’ filterElement 


; 

filterElement 

: messagePattern 

{messagePattern:} 

“a <strong>Sina</strong>FilterElementNode” 

| conditionSet filterOperator messagePatternSet 

{conditions:operator:messages:} 

“a <strong>Sina</strong>FilterElementNode” 

; 

filterOperator 

158


: ‘=>’ 

{enableOperator} 

| ‘~>’ 

{exclusionOperator} 

; 

conditionSet 

: condition 

{<strong>Sina</strong>FilterConditions} 

| ‘{‘ conditions ‘}’ 

; 

conditions 

: condition 

{<strong>Sina</strong>FilterConditions} 

| conditions ‘,’ condition 


; 

condition 

: conditionName associativeParameter 

{condition:associativeParameter:} 

“a <strong>Sina</strong>FilterConditionNode” 

| ‘true’ 

{conditionTrue} 

“a <strong>Sina</strong>FilterConditionTrueNode” 

; 

associativeParameter 

: “empty” 

{nil} 

| ‘(‘ ‘#’ ‘)’ 

{associativeParameter} 

“answers $#” 

; 

messagePatternSet 


{<strong>Sina</strong>MessagePatterns} 

| ‘{‘ messagePatterns ‘}’ 

; 

messagePatterns 


{<strong>Sina</strong>MessagePatterns} 

| messagePatterns ‘,’ messagePattern 


; 

messagePattern 

: substitutionPart 

{substitutionPart:} 

| ‘[‘ matchingPart ‘]’ substitutionPart 

{matchingPart:substitutionPart:} 

; 

matchingPart 

: messageSelector 

{tsWildCard:} 

| objectName ‘.’ messageSelector 

{tsObject:selector:} 

| ‘*’ ‘.’ messageSelector 

{tsWildCard:} 

| ‘self’ ‘.’ messageSelector 

{tsSelf:} 

; 

substitutionPart 

: messageSelector 

{tsWildCard:} 

| objectName ‘.’ messageSelector 

{tsObject:selector:} 

| ‘*’ ‘.’ messageSelector 

{tsWildCard:} 

| ‘#’ ‘.’ messageSelector 

{tsHash:} 

| ‘inner’ ‘.’ messageSelector 

{tsInner:} 

| ‘self’ ‘.’ messageSelector 

{tsSelf:} 

; 


: selector 

| ‘*’ 

{selectorWildcard} 

; 

“----------------Methods-------------------” 

methodName 

: 


| ‘and’ 

{methodNameAnd} 

| ‘or’ 

{methodNameOr} 

| ‘not’ 

{methodNameNot} 

| ‘div’ 

{methodNameDiv} 

| ‘mod’ 

{methodNameMod} 

| ‘class’ 

{methodNameClass} 

| ‘sender’ 

{methodNameSender} 

159


| ‘server’ 

{methodNameServer} 

; 

methodDeclarations 

: “empty” 

{<strong>Sina</strong>MethodDeclarations} 

| methodDeclarations methodDeclaration ‘;’ 


; 

methodDeclaration 

: methodName methodParameters ‘returns’ methodReturnType 

{<strong>Sina</strong>MethodDeclarationNode} 

; 

“methodParameterTypes 

:” “empty” 

“ {nil} 

| ‘(‘ classDescriptions ‘)’ 

;” 

methodImplementations 

: “methodImplementation ‘;’” 

{<strong>Sina</strong>Methods} 

| methodImplementations methodImplementation ‘;’ 


; 

methodImplementation 

: methodHeader methodBody 


; 

methodHeader 

: methodName methodParameters methodReturnTypeOPT 

{<strong>Sina</strong>MethodNode} 

; 

methodParameters 

: “empty” 



| ‘(‘ parameterObjectDeclarations ‘)’ 

; 

methodReturnTypeOPT 

: “empty” 

{nil} 

| ‘returns’ methodReturnType 

; 

methodReturnType 

: ‘nil’ 

{<strong>Sina</strong>NilNode} 

| classDescription 

; 

methodBody 

: comment 

tempsPart 

‘begin’ 


‘end’ 

{<strong>Sina</strong>BodyNode} 

; 

tempsPart 

: “empty” 



| ‘temps’ objectDeclarations 

; 

“----------------Statements-------------------” 


: statement 

{statement:} 

| statements ‘;’ statement 

{statements:statement:} 

; 

statement 

: “empty” 

{nil} 

| expression 

| assignment 

| returnExpression 

| conditionalStatement 

| whileStatement 

| forStatement 

; 

assignment 

: objectName ‘:=’ expression 

{<strong>Sina</strong>AssignmentNode} 

; 

returnExpression 

: ‘return’ 

{returnExpression} 

| ‘return’ expression 

{returnExpression:} 

; 

conditionalStatement 

: ‘if’ expression ‘then’ statements elsePartOPT ‘end’ 

{<strong>Sina</strong>ConditionalNode} 

; 

elsePartOPT 

: “empty” 

160


{nil} 

| ‘else’ statements 

; 

whileStatement 

: ‘while’ expression 

‘begin’ 


‘end’ 

{<strong>Sina</strong>WhileNode} 

; 

forStatement 

: ‘for’ objectName ‘:=’ expression ‘to’ expression forStep 

‘begin’ 


‘end’ 

{<strong>Sina</strong>ForNode} 

; 

forStep 

: “empty” 

{nil} 

| ‘by’ expression 

; 

“----------------Expressions-------------------” 

expressions 

: expression 


| expressions ‘,’ expression 


; 

expression 

: conjunction 

; 

conjunction 

: disjunction 

| conjunction ‘or’ disjunction 

{receiverOr:arg:} 

“a <strong>Sina</strong>MessageSendNode” 

; 

disjunction 

: equality 

| disjunction ‘and’ equality 

{receiverAnd:arg:} 


; 

equality 

: relational 

| relational ‘=’ relational 

{receiverEqual:arg:} 


| relational ‘!=’ relational 

{receiverUnequal:arg:} 


| relational ‘==’ relational 

{receiverSame:arg:} 


| relational ‘=!=’ relational 

{receiverDifferent:arg:} 


; 

relational 

: arithmetic 

| arithmetic ‘=’ arithmetic 

{receiverAtleast:arg:} 


; 

arithmetic 

: term 

| arithmetic ‘+’ term 

{receiverAdd:arg:} 


| arithmetic ‘-’ term 

{receiverSubtract:arg:} 


; 

term 

: factor 

| term ‘*’ factor 

{receiverTimes:arg:} 


| term ‘/’ factor 

{receiverDivide:arg:} 


| term ‘div’ factor 

{receiverDiv:arg:} 


| term ‘mod’ factor 

161


{receiverMod:arg:} 


; 

factor 

: operand 

| ‘not’ operand 

{receiverNot:} 


| ‘-’ operand 

{receiverNegated:} 


; 

operand 

: object 

| objectManager ‘.’ message 

{manager:message:} 

“a <strong>Sina</strong>ManagerMessageSendNode” 

| ‘inner’ ‘.’ message 

{innerMessage:} 

“a <strong>Sina</strong>InnerMessageSendNode” 

| operand ‘.’ message 

{receiver:message:} 


| ‘(‘ expression ‘)’ 

{enclosedExpression:} 

; 

“----------------Objects-------------------” 

objectName 

: 


; 

objectNames 

: objectName 

{<strong>Sina</strong>ObjectNames} 

| objectNames ‘,’ objectName 


; 

objectDeclarations 

: “empty” 



| objectDeclarations objectDeclaration ‘;’ 

{objectDeclarations:objectDeclaration:} 

; 

parameterObjectDeclarations 

: objectDeclaration 

| parameterObjectDeclarations ‘;’ objectDeclaration 

{objectDeclarations:objectDeclaration:} 

; 

objectDeclaration 

: objectNames ‘:’ classDescription 

{flattenDeclaration:type:} 

; 

singleObjectDeclaration 

: objectName ‘:’ classDescription 

{singleDeclaration:type:} 

; 

“objects 

: object ‘;’ 

{OrderedChildren} 

| objects object ‘;’ 


;” 

object 

: objectName 

{<strong>Sina</strong>ObjectNode} 

| ‘nil’ 

{<strong>Sina</strong>NilNode} 

| ‘true’ 

{<strong>Sina</strong>TrueNode} 

| ‘false’ 

{<strong>Sina</strong>FalseNode} 

| ‘self’ 

{<strong>Sina</strong>SelfNode} 


{<strong>Sina</strong>ServerNode} 


{<strong>Sina</strong>SenderNode} 

| ‘message’ 

{<strong>Sina</strong>MessageNode} 

| 

{as<strong>Sina</strong>Char:} 

“Remove the leading $-character” 

“Answers a <strong>Sina</strong>CharNode” 

| 

{as<strong>Sina</strong>String:} 

“Remove the enclosing quotes” 

“Answers a <strong>Sina</strong>StringNode” 

| 

{<strong>Sina</strong>NumberNode} 

; 

objectManager 

: ‘^’ ‘self’ 

{<strong>Sina</strong>ManagerSelfNode} 

| ‘^’ ‘server’ 

162


; 

{<strong>Sina</strong>ManagerServerNode} 

“----------------Messages-------------------” 

message 

: selector messageArguments 

{<strong>Sina</strong>MessageSendNode} 

; 

selector 

: 

{asSelector:} 

| 

{asSelector:} 

| ‘class’ 

{selectorClass} 


{selectorServer} 


{selectorSender} 

| ‘and’ 

{selectorAnd} 

| ‘or’ 

{selectorOr} 

| ‘not’ 

{selectorNot} 

| ‘div’ 

{selectorDiv} 

| ‘mod’ 

{selectorMod} 

; 

messageArguments 

: “empty” 


“i.e. empty collection” 

| ‘(‘ expressions ‘)’ 

; 

“----------------Miscellaneous-------------------” 

comment 

: “empty” 

{nil} 

| ‘comment’ commentText ‘;’ 

; 

commentText 

: 

{sinaComment:} 

; 

classSwitches 

: “empty” 


| classSwitches classSwitch 


; 

classSwitch 

: ‘#’ switch switchParameters ‘;’ 

{liftRightChild} 

; 

switch 

: 


; 

switchParameters 

: “empty” 


| switchParameters switchParameter 


; 

switchParameter 

: 

{asString:} 

| 


; 

163

164 

Appendix C: <strong>Sina</strong>⁄st syntax definition

APPENDIX 

D Conversion 

algorithm 

D.1 Introduction 

When a filter filters a message, the filter has to decide whether to accept or to reject the 

message. If the message is accepted by the filter, the accept action of the filter will be 

carried out. In the opposite case, if the message is rejected, the filter’s reject action will be 

carried out. The decision whether to accept or reject a message is called the accept test of a 

filter. 

The accept test The accept test decides if a filter has to accept or to reject a message. The filter initializer 

of the filter defines which messages the filter accepts. Other messages thus are rejected. 

The accept test is comprised of a number of sub tests: 

• selector matching: the selector of the message must match with one specified in the 

filter initializer; 

• receiver matching: for a message pattern [μ]σ that consists both of a matching part μ 

and a substitution part σ, and that is not the pattern of an exclusion element, the target 

of the message must match with the target of the matching part μ; 

• signature matching: for a message pattern σ that consists only of a substitution part, or 

a message pattern [μ]σ in an exclusion element —of which the matching part μ is 

ignored—, the message must be included in the signature of the target of σ; 

• condition evaluation 

• yielding a substitution target and/or selector 

When a message is evaluated by a filter to detect if the filter has to accept or to reject the 

message, the filter has to evaluate the conditions that a relevant for the message. The filter 

initializer, the part between the curly braces in the filter declaration, specifies the 

conditions and which message targets and selectors it accepts. The filter initializer does not 

specify, though, which conditions have to be evaluated for one particular message selector 

seperately. This would be very convenient, for instance, when a message has been blocked 

by a wait filter, to reevaluate only those conditions that are relevant for the blocked 

message in order to see if it can be unblocked. 

This appendix presents an algorithm that converts a filter initializer into a selectorcondition 

dictionary. Such a dictionary holds for a particular selector, an entry that 

contains all the conditions to be evaluated for that selector. When a filter has to decide if a 

message must be accepted or rejected, it can select from the dictionary the entry for the 

message’s selector and evaluate them. If they evaluate to true, the message will be 

accepted, and otherwise it will be rejected. 

In the following subsection we will informally describe which conditions a filter has to 

evaluate if a message m with a certain selector passes the filter. In section D.3 we formally 

define the filter initializer, the selector-condition dictionary and the components that can be 

found in them. In section D.4 we present the algorithm that converts a filter initializer to a 

selector-condition dictionary. 


165

166 

An exclusion filter 

element 

D.2 A closer look at the filter initializer 

We first describe informally which conditions have to be evaluated if a message m with a 

certain selector passes the filter. Consider, for example, a filter which has the following 

initializer: 

{c1=>[a.put]b.mput, {c2, c3}=>a.*, c4~>{*.get, c.*, d.*}} 

A message m with a selector put is accepted by the filter if it is accepted by either 

filterelement. This is the case if (1) m’s receiver is the object a and the condition c1 is true, 

or (2) if put is in the signature of a and either of the conditions c2 or c3 is true, or (3) if put 

is neither in c’s signature nor in d’s signature, and condition c4 is true. In case (1), a 

substitution target object b and selector mput is used for accept action of the message. In 

the latter two cases no substitution is returned. 

The conditions to be evaluated for a message with selector put can be written down into 

one condition which also states any substitutions that will be returned: 

(rcv(m)=a∧ c1:b.mput) 

∨(put∈sig(a)∧ (c2 ∨ c3):a.⊥) 

∨(¬( put∈sig(c) ∨ put∈sig(d)) )∧ c4:⊥) 

In this, the ¬ denotes the logical not, the ∨ the non-evaluating logical or, and the ∧ the 

non-evaluating logical and 1 . The substitutions that are returned are stated after the colon, 

with ⊥ denoting that no substitution is returned. 

A message m with selector get is accepted if: 

(get∈sig(a)∧ (c2 ∨ c3):⊥) 

∨(¬( get∈sig(*) ∨ get∈sig(c)) ∨ get∈sig(d)))∧ c4:⊥) 

Since the selector get is always in the signature of any object (get∈sig(*)≡true), the last 

line will never be able to accept the message (because ¬(true ∨…∨…)≡false and so 

false∧c4≡false). The conditions to be be evaluated for a message with selector get can 

therefore be reduced to (get∈sig(a) ∧ (c2 ∨ c3): ⊥). 

A message m with any selector except put or get will be accepted if 

(sel(m)∈sig(a)∧ (c2 ∨ c3):⊥) 

∨(¬( sel(m)∈sig(c) ∨ sel(m)∈sig(d)) )∧ c4:⊥) 

From the previous, we can see that for the acceptance of a message by a filter, based on the 

selector of the message, the following conditions have to be evaluated: 

• a receiver or signature matching condition: the receiver of the message has to be a 

certain target object, or, the selector of the message has to be in the signature of a 

certain object. 

• certain combinations of conditions as stated in the filter initializer; c1, c2, c3 and c4 in 

the initializer above. 

Consider a filter element {c1, c2}~>{a.get, b.*, *.put}. A message with a selector get will be 

accepted by this filter element when either of the conditions c1 or c2 evaluates to true and 

when this message is not accepted by the pattern set (since the exclusion operator ~> 

preceeds the message pattern set). The message with selector get will be accepted by the 

pattern set if get ∈ sig(a) or get ∈ sig(b) 2 . Hence, a message with selector get will be 

accepted by this filter element when ¬(get ∈ sig(a) ∨ get ∈ sig(b)) ∧ (c1 ∨ c2). A same 

proposition can be derived for a message with selector put. It will be accepted by the filter 

1. A ∧ B will be evaluated as: if value of A is false then return false else return the value of B. 

A ∨ B will be evaluated as: if value of A is true then return true else return the value of B. 

Appendix D: Conversion algorithm

element when ¬(put ∈ sig(b) ∨ put ∈ sig(*)) ∧ (c1 ∨ c2). Since put is always in the 

signature of every object (put ∈ sig(*)≡true), this message will never be accepted by this 

filter element, regardless of the values of the conditions c1 and c2. A message m with any 

other selector than put or get will be accepted by the message pattern set if sel(m) ∈ sig(b), 

and therefore, it will be accepted by the filter element if ¬(sel(m) ∈ sig(b)) ∧ (c1 ∨ c2). 

From this, we can see that if a selector has been mentioned in the message pattern set of an 

exclusion filter element, then the accept conditions to be evaluated for one selector are 

comprised of the condition(s) of the filterelement and a logically negated conjunction —an 

or-ed combination— of signature conditions: 

¬(sel(m) ∈ sig(t 1 ) ∨…∨sel(m) ∈ sig(t n )) ∧ (c 1 ∨…∨c c ). If the selector has not been 

mentioned in the pattern set, the accept conditions consist only of the condition(s) of the 

exclusion filter element. 

In the following section, we define an element containing a receiver or signature matching 

condition, a number of ordinary conditions and possibly returning a substitution target and 

selector as a condition-substitution element (f ∧ C: τ). For a message with a particular 

selector, a number of such condition-substitution elements have to be evalated until the 

first evaluates to true or all evaluate to false. In the latter case, the message will be rejected 

by the filter, whereas in the first case it will be accepted and the substitution τ of the first 

element that evaluated to true will be used by the filter to change the message accordingly. 

D.3 Definitions 

The following three definitions describe a filter initializer and the components that can be 

found in it. The syntax of <strong>Sina</strong> allows you to omit parts of a filter element, and to declare 

just a single or a set of conditions and message patterns. In the definition of a filter 

element, though, we allow only a set of conditions on the left hand side of the enable or 

exclusion operator, and only a set of message patterns on the right hand side. However, a 

filter initializer can be easily rewritten to acommodate this requirement. For example, the 

following filter initializer 

{get, c1=>put, {c2, c3}=>[get2]inner.extract2} 

can be equivalently written as 

{ {true}=>{*.get}, {c1}=>{*.put}, {c2, c3}=>{[*.get2]inner.extract2} } 

In this form, each filter element has on the left hand side and on the right hand side of the 

=> operator a set of conditions and message patterns, respectively. 

DEFINITION D-1 Message pattern 

A message pattern is a tuple μσ, where 

μ denotes the matching part; 

σ denotes the substitution part. 

When no matching part μ is specified in the filter initializer, then μ is undefined: μ = ⊥. 

Both the substitution part and the matching part of a message pattern have two 

components: the target and the selector. They will be denoted as tar(μ), tar(σ), sel(μ) and 

sel(σ), respectively. For μ=⊥, the target and selector are undefined: tar(⊥) = sel(⊥) =⊥. 

DEFINITION D-2 Filter element 

A filter element is a triple CωΠ, where 

C is an ordered set of q conditions: C=[c 1 ,c 2 , …, c q ]; 

2. For the moment, we consider only the selector of the message matches the signature of an object. 

The number and the types of arguments of the message should ofcourse also be regarded when 

we verify that the message matches the signature of the object. 


167

168 

ω is either the enable operator => or the exclusion operator ~>; 

Π is an ordered set of m message patterns: Π =[μ 1 σ 1 , μ 2 σ 2 , …, μ m σ m ]. 

DEFINITION D-3 Filter initializer 

A filter initializer FI = [C 1 ω 1 Π 1 , …, C n ω n Π n ] is an ordered set of n filter elements C i ω i Π i . 

As an example, the filter initializer { {empty, partial}=>{arr.put}, {partial}=>{inner.get}, 

{full}=>{[self.get]*.*} } 

contains three filter elements C 1 ω 1 Π 1 , C 2 ω 2 Π 2 , C 3 ω 3 Π 3 , where 

C 1 = [empty, partial]; 

C 2 = [partial]; 

C 3 = [full]; 

ω 1 = ω 2 = ω 3 = ‘=>’; 

Π 1 = [μ 1 σ 1 ], with μ 1 = ⊥, tar(σ 1 )=arr and sel(σ 1 )=put; 

Π 2 = [μ 2 σ 2 ], with μ 2 = ⊥, tar(σ 2 )=inner and sel(σ 2 )=get; 

Π 3 = [μ 3 σ 3 ], with tar(μ 3 )=self, sel(μ 3 )=get, tar(σ 3 )=* and sel(σ 3 )=*. 

The following definitions define the selector-condition dictionary and its components. A 

substitution is the target and the selector to be applied to the message if it is accepted by 

the filter. The receiver-signature match function tries either to match the target of a 

message pattern with the receiver of the message (the match function r(t)), or to check if 

the selector of the message is included in the signature of a target object (the match 

function s(t)) or excluded from the signature of a number of target objects (the match 

function e(t 1 , …, t n )). The match function r(t) always yields true when the target t is the 

wildcard target ‘*’, since the receiver of the message always matches with this target. 

Similarly, the match function s(t) always yields true when the target t is the wildcard target 

‘*’, since the selector of the message is always included in the signature of any object. 

Because the selector of a message is never excluded from the signature of every possible 

object, the match function e(t 1 , …, t n ) yields false when any t i is the wildcard target ‘*’. 

DEFINITION D-4 Substitution 

A substitution τ has a target tar(τ) and a selector sel(τ). Either can be undefined which will 

be denoted as tar(τ)=⊥ or sel(τ)=⊥. When both are undefined, τ=⊥. 

DEFINITION D-5 Match function 

A match function f is one of the five functions 

f = 

r() t 

⎧ 

⎪ s() t 

⎪ 

⎨e( 

t1, …, tn) ⎪ 

⎪ true 

⎩ 

false 

where 

r(t) denotes the match function rcv(m) =t. When t=‘*’ then r(t) yields true; 

s(t) denotes the match function sel(m) ∈sig(t). When t=‘*’ then s(t) yields true; 

e(t1 , …, tn ) denotes the match function ¬(sel(m) ∈sig(t1 ) ∨…∨ sel(m) ∈sig(tn )). 

When any ti = ‘*’ then e(t, …, tn ) yields false. 

DEFINITION D-6 Condition-substition element 

A condition-substitution element is a triple fCτ, where 

f is a receiver-signature match; 

C is an ordered set of conditions; 

τ is a substitution. 

We will denote a condition-substitution element more readable with 

(f ∧ C: τ) 

which is to be interpreted as “if the receiver-signature match function f is true and (then) if 

either condition in the condition set C is true, then the condition-substitution element 


yields true and substitution τ will be returned. Otherwise the condition-substitution 

element yields false.”. 

DEFINITION D-7 Selector-condition dictionary 

A selector-condition dictionary SD={s 1 →S 1 , …, s k →S k } is a set of k tuples s i →S i , 

where 

s i is a selector or the wildcard selector *; 

S i is an ordered set of p condition-substitution elements: S i =[f 1 C 1 τ 1 , …, f p C p τ p ]. 

The wildcard selector denotes a default entry for a selector that does not match a selector 

s j ≠ ‘*’, j = 1, …, k, contained in SD. A tuple s i →S i states that for a selector s i the 

condition-substitution elements of S i will have to be evaluated. The filter will accept a 

message with selector s when one of the condition-substitution elements f i C i τ i of the entry 

s→[f 1 C 1 τ 1 , …, f p C p τ p ] evaluates true. 

D.4 The algorithm 

The algorithm presented below will create a selector-condition dictionary from a filter 

initializer. The details of the algorithm will be elucidated after the algorithm. 

ALGORITHM D-1 Converting a filter initializer to a selector condition dictionary 

input: a filter initializer FI = [C1ω1Π1 , …, CnωnΠn ] containing n filter elements. (1) 

output: a selector-condition dictionary SD. (2) 

begin (3) 

create SD with selectors from FI; (4) 

for all (CiωiΠi ∈FI from 1 to n) (5) 

do if ωi =‘=>’ (6) 

then add filterelement CiωiΠi enabled to SD (7) 

else add filterelement CiωiΠi excluded to SD (8) 

fi; (9) 

od; (10) 

return SD (11) 

end (12) 

(13) 

add filterelement CiωiΠi enabled to SD (14) 

begin // ωi =‘=>’ (15) 

for all (μjσj ∈Πi from 1 to m) (16) 

do if μj = ⊥ (17) 

then ς := sel(σj );f := sel(m) ∈ sig(tar(σj ));τ := tar(σj ).⊥ (18) 

else ς := sel(μj );f := rcv(m) = tar(μj );τ := σj (19) 

fi; (20) 

if ς = ‘*’ (21) 

then for all (s→S ∈SD) do add ( f ∧ Ci : τ ) to S od (22) 

else add ( f ∧ Ci : τ ) to S where ς→S ∈ SD (23) 

fi (24) 

od (25) 

end (26) 

(27) 

add filterelement CiωiΠi excluded to SD (28) 

begin // ωi =‘~>’ (29) 

selSet := ∪μσ∈Πi {sel(σ)}; // selSet = {ς1 , …, ςs } (30) 

for all (s→S ∈ SD) (31) 

do if s ∈ selSet ∨ ‘*’ ∈ selSet (32) 

then (33) 

tarSet := ∪ μσ∈Πi : (sel(σ) =s ∨ sel(σ) = ‘*’) [tar(σ)] ; // tarSet = [υ 1 , …, υ t ] (34) 


169

170 

f := ¬( sel(m) ∈ sig(υ1 ) ∨…∨ sel(m) ∈ sig(υt )) (35) 

else // s ∉ selSet ∧ ‘*’ ∉ selSet (36) 

f := true (37) 

fi; (38) 

add ( f ∧ Ci : ⊥ ) to S (39) 

od (40) 

end (41) 

(42) 

create SD with selectors from FI; (43) 

begin (44) 

SD := ∅; (45) 

for all (CiωiΠi ∈FI from 1 to n) (46) 

do for all (μjσj ∈Πi from 1 to m) (47) 

do if μj = ⊥ or ωi =‘~>’ (48) 

then SD := SD ∪ { sel(σj )→∅ } (49) 

else SD := SD ∪ { sel(μj )→∅ } (50) 

fi (51) 

od (52) 

od (53) 

end (54) 

(55) 

add fCτ to S=[f1C1τ1 , …, fpCpτp ] (56) 

begin (57) 

S:=[f1C1τ1 , …, fpCpτp , fCτ] (58) 

end (59) 

The algorithm starts by creating a selector-condition dictionary with an entry for all the 

selectors mentioned in the filter initializer (lines 4 and 43-54). The selector of the 

substitution part σ j will be used, when the filterelement is an exclusion element — 

remember that the matching part of a message pattern μ j σ j in an exclusion element is 

ignored—, or when no matching part μ j is defined. Otherwise the selector of the matching 

part μ j is used for an entry in the dictionary. The algorithm then continues by adding every 

filterelement in the filterinitializer to the dictionary (lines 5-10). The algorithm has to 

distinguish between an element with an enable operator (ω i =‘=>’) or an exclusion 

operator (ω i =‘~>’). 

A filterelement with an enable operator will be added to the dictionary in the subroutine 

add filterelement enabled to SD (lines 14-26). All messagepatterns μ j σ j in the message 

pattern set Π i will be treated seperately. When the matching part μ j is undifined, signature 

matching will be used with the match function s(t) that checks if the selector of the 

message is included in the signature of target of σ j . In this case, no substitution will be 

returned (line 18). Otherwise, receiver matching is used with the match function r(t) that 

checks if the receiver of the message the target of μ j . The substitution returned in this case 

is the subtitution part σ j of μ j σ j (line 19). The selector matched in the former case is the 

selector of the substitution part and the selector of the matching part μ j in the latter case. A 

condition-substitution element fCτ, with the previously determined match function and 

substitution and the conditions C i of the filterelement, will be added to the dictionary entry 

of the selector only (line 23), or, when the selector is the wildcard selector *, to all selector 

entries in the dictionary (line 22), since condition-substitution element applies to all 

selectors in that case. 

A filterelement with an exclusion operator will be handled by the subroutine add 

filterelement excluded to SD (lines 28-41). First, a set selSet of selectors that are mentioned 

in the message pattern set is constructed (line 30). Then, we iterate over all the selectors s 

in the selector dictionary (lines 31-40) to add a condition-substitution element for each s. 

In case, the selector s was not mentioned in the message pattern set (s ∉ selSet, line 36), 

whether s will be accepted only depends on the conditions C i (line 34). In the opposite 

case, when s was mentioned in the message pattern set (s ∈ selSet), the match function f is 


uilt (line 34) from the targets that are applicable for s —all μσ∈Π i with sel(σ)=s or 

sel(σ)=‘*’— which have been collected in the set tarSet in the same ordering as they 

appeared in Π i . 

Rewrite rules 

The algorithm creates a dictionary in which for every possible selector the conditions are 

contained. The dictionary contains still all the information that is also stored in the filter 

initializer. The dictionary can be further simplified by using rewrite rules that discard 

unneccessary information. 

DEFINITION D-8 Rewrite rules for a selector condition dictionary 

(1) A match function s(t) denoting the function sel(m) ∈ sig(t), can be replaced by the 

match function true when t = ‘*’. 

(2) A match function r(t) denoting the function rcv(m) = t can be replaced by the match 

function true when t = ‘*’. 

(3) A match function e(t 1 , …, t n ) denoting the function 

¬(sel(m) ∈sig(t 1 ) ∨…∨ sel(m) ∈sig(t n )) can be replaced by the match function false 

if any t i = ‘*’, i = 1 … n. 

(4) A condition-substitution element f i C i τ i can be removed from the ordered set 

S=[f 1 C 1 τ 1 , …, f i C i τ i , …, f p C p τ p ], with s→S ∈SD, when f i is the match function false. 

(5) An ordered set of conditions C = [c 1 , …, c i , …, c n ] can be replaced by C = [c 1 , …, c i ], 

if c i is the condition true. 

(6) An ordered set of condition-substitution elements S=[f 1 C 1 τ 1 , …, f i C i τ i , …, f p C p τ p ], 

with s→S ∈SD, can be replaced by S=[f 1 C 1 τ 1 , …, f i C i τ i ] if the element f i C i τ i 

always accepts the selector s. That is if f i is the match function true and any 

c j ∈ C i =[c 1 , …, c n ] is the condition true. 


171

172 


References 

[Aksit88] Mehmet Aksit and Anand Tripathi. “Data abstraction mechanisms in sina/st.” In 

[Meyrowitz88], pages 267–275, 1988. 

[Aksit89] Mehmet Aksit. On the Design of the Object-Oriented Language <strong>Sina</strong>. Ph.D. dissertation, 

University of Twente, Dept. of Computer Science, P.O. box 217, 7500 AE, Enschede, The 

Netherlands, 1989. ISBN 90-365-0250-0. 

[Aksit91] Mehmet Aksit, Jan-Willem Dijkstra, and Anand Tripathi. “Atomic Delegations: Object- 

Oriented Transactions.” IEEE Software, pages 84–92, March 1991. IEEE Computer 

Society, 10622 Los Vaqueros Cir., PO Box 3014, Los Alamitos, CA 90720-1264, USA. 

ISSN 0740-7459. 

[Aksit92a] Mehmet Aksit and Lodewijk Bergmans. Obstacles in object-oriented software 

development. In Andreas Paepcke, editor, OOPSLA ’92, Conference Proceedings, 

volume 27 of ACM SIGPLAN Notices, pages 341–358, October 1992. ISSN 0362-1340, 

ISBN 0-201-53372-3. 

[Aksit92b] Mehmet Aksit, Lodewijk Bergmans, and <strong>Sina</strong>n Vural. An object-oriented languagedatabase 

integration model: The composition-filters approach. In Ole Lehrmann Madsen, 

editor, ECOOP ’92, European Conference on Object-Oriented Programming, number 615 

in Lecture Notes in Computer Science, pages 372–395, Berlin Heidelberg, June/July 1992. 

European Conference on Object-Oriented Programming, Springer-Verlag. ISBN 0-387- 

55668-0 / ISBN 3-540-55668-0. 

[Aksit93] Mehmet Aksit, Ken Wakita, Jan Bosch, Lodewijk Bergmans, and Akinori Yonezawa. 

Abstracting object interactions using composition filters. In Rachid Guerraoui, Oscar 

Nierstrasz, and Michel Riveill, editors, ECOOP ’93, Workshop on Object-Based 

Distributed Programming, number 791 in Lecture Notes in Computer Science, pages 152– 

184, Berlin Heidelberg, July 1993. European Conference on Object-Oriented 

Programming, Springer-Verlag. ISBN 0-387-57932-X / ISBN 3-540-57932-X. 

[Aksit94] Mehmet Aksit, Jan Bosch, William van der Sterren, and Lodewijk Bergmans. Real-time 

specification inheritance anomalies and real-time filters. In Mario Tokoro and Remo 

Pareschi, editors, ECOOP ’94, Object-Oriented Programming, number 821 in Lecture 

Notes in Computer Science, pages 386–407, Berlin Heidelberg, July 1994. European 

Conference on Object-Oriented Programming, Springer-Verlag. ISBN 0-387-58202-9 / 

ISBN 3-540-58202-9. 

[Aksit95] Mehmet Aksit and Lodewijk Bergmans. “Application Domains and Obstacles in 

Conventional Object-Oriented Software Development.” Draft version. University of 

Twente, Dept. of Computer Science, P.O. box 217, 7500 AE, Enschede, The Netherlands, 

1995. 


173

174 

[Algra94] Egbert Algra. “Process programming and learning domains in object oriented hermeneutic 

software development.” M.Sc. thesis, University of Twente, Dept. of Computer Science, 

P.O. box 217, 7500 AE, Enschede, The Netherlands, June 1994. 

[Bergmans94a] Lodewijk Bergmans. Composing Concurrent Objects. Ph.D. dissertation, University of 

Twente, Dept. of Computer Science, P.O. box 217, 7500 AE, Enschede, The Netherlands, 

June 1994. ISBN 90-9007359-0. 

[Bergmans94b] Lodewijk M.J. Bergmans. The Composition-Filters Object Model. This paper was derived 

from Chapter 2 of [Bergmans94a]. University of Twente, PO box 217, 7500 AE Enschede, 

The Netherlands, June 1994. 

[vDijk95] Wietze van Dijk and John Mordhorst. “CFIST: Composition Filters in Smalltalk.” HIO 

Graduation thesis, July 1995. 

[Ellis90] Margaret A. Ellis and Bjarne Stroustrup. The Annotated C++ Reference Manual. 

Addison-Wesley Publishing Company, Reading, Massachusetts, 1990. ISBN 0-201- 

51459-1. 

[Ferber89] Jaques Ferber. “Computational Reflection in Class-based Object-Oriented Languages.” In 

[Meyrowitz89], pages 317–326, 1989. 

[Goldberg83] Adele Goldberg and David Robson. Smalltalk-80 : The Language And Its Implementation. 

Addison-Wesley Series in Computer Science. Addison-Wesley, Reading, MA, USA, 1983. 

ISBN 0-201-11371-6. 

[Goldberg89] Adele Goldberg and David Robson. Smalltalk-80: The Language. Addison-Wesley Series 

in Computer Science. Addison-Wesley Publishing Company, Reading, MA, USA, 

September 1989. ISBN 0-201-13688-0. 

[Graver92a] Justin O. Graver. “T-gen: a string-to-object translator generator.” Journal of Object- 

Oriented Programming, 5(5):35–42, September 1992. SIGS Publications, Inc., 588 

Broadway, Suite 604, New York, NY 10012, USA. ISSN 0896-8438. 

[Graver92b] Justin O. Graver. T-gen Version 2.1 User’s Guide, 1992. Included in the T-gen package 

which is available at ftp://st.cs.uiuc.edu/pub/st80_r41/T-gen2.1/, and at ftp:// 

mushroom.cs.man.ac.uk/pub/goodies/uiuc/st80_r41/T-gen2.1/. 

[Johnson75] S.C. Johnson. “Yacc - yet another compiler compiler.” Computing Science Technical 

Report 32, AT&T Bell Laboratories, Murray Hill, New Jersey, USA, 1975. 

[Koopmans95] Piet S. Koopmans. <strong>Sina</strong>/st User’s Guide and Reference Manual. TRESE Project, 

Department of Computer Science, University of Twente, Enschede, The Netherlands, 

<strong>Sina</strong>/st version 3.00 edition, August 1995. 

[Maes87] Pattie Maes. “Concepts and Experiments in Computational Reflection.” In [Meyrowitz87], 

pages 147–155, 1987. 

[Meyrowitz86] Norman Meyrowitz, editor. OOPSLA ’86 Conference Proceedings, volume 21 of 

SIGPLAN Notices, 11 West 42nd Street, New York, New York 10036, USA, September 

1986. Association for Computing Machinery’s Special Interest Group on Programming 

Languages (ACM/SIGPLAN), Association for Computing Machinery, Inc. ISBN 0- 

89791-204-7. 

[Meyrowitz87] Norman Meyrowitz, editor, OOPSLA ’87 Conference Proceedings, volume 22 of 

SIGPLAN Notices, 11 West 42nd Street, New York, New York 10036, USA, December 

1987. Association for Computing Machinery’s Special Interest Group on Programming 

Languages (ACM/SIGPLAN), Association for Computing Machinery, Inc. ISBN 0- 

89791-247-0. 

References

[Meyrowitz88] Norman Meyrowitz, editor. OOPSLA ’88, Conference Proceedings, volume 23 of 

SIGPLAN Notices, 11 West 42nd Street, New York, NY 10036, USA, November 1988. 

Special Interest Group on Programming Languages, Association for Computing 

Machinery, Association for Computing Machinery, Inc. ISBN 0-89791-284-5, ISSN 0362- 

1340. 

[Meyrowitz89] Norman Meyrowitz, editor. OOPSLA ’89, Conference Proceedings, volume 24 of 

SIGPLAN Notices, 11 West 42nd Street, New York, NY 10036, USA, October 1989. 

Special Interest Group on Programming Languages, Association for Computing 

Machinery, Association for Computing Machinery, Inc. ISBN 0-0201-52249-7, ISSN 

0362-1340. 

[Marcelloni95] Francesco Marcelloni and Mehmet Aksit. “Design and Implementation of the Object- 

Oriented Fuzzy-Logic Reasoning Framework.” Draft version, University of Twente, 

P.O.Box 217, 7500 AE Enschede, The Netherlands, 1995. 

[ParcPlace92a] ParcPlace Systems, 999 E. Arques Ave., Sunnyvale, CA 94086–4593, USA. 

Objectworks\Smalltalk Release 4.1 User’s Guide, 1992. 

[ParcPlace92b] ParcPlace Systems, 999 E. Arques Ave., Sunnyvale, CA 94086–4593, USA. VisualWorks 

Release 1.0 User’s Guide, 1992. 

[Rumbaugh91] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William 

Lorensen. Object-Oriented modeling and design. Prentice-Hall International Inc., 

Englewoods Cliffs, New Jersey 07632, 1991. ISBN 0-13-630054-5. 

[Tekinerdogan94] Bedir Tekinerdogan. “The design of an object-oriented framework for atomic 

transactions.” M.Sc. thesis, University of Twente, Dept. of Computer Science, P.O. box 

217, 7500 AE, Enschede, The Netherlands, March 1994. 

[Ungar87] David Ungar and Randall B. Smith. “Self: The Power of Simplicity.” In [Meyrowitz87] , 

pages 227–242. 

[Vuijst94] Charles Vuijst. “Design of an Object-Oriented Framework for Image Algebra.” M.Sc. 

thesis, University of Twente, Dept. of Computer Science, P.O. box 217, 7500 AE, 

Enschede, The Netherlands, December 1994. 

[Wegner87] Peter Wegner. “Dimensions of object-based language design.” In [Meyrowitz87], pages 

168–182, 1987. 

[Wirfs-Brock90] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. Designing Object-Oriented 

Software. Prentice Hall, Inc., Englewood Cliffs, New Jersey 07632, USA, 1990. ISBN 0- 

13-629825-7. 


175

176 

References

Index 

#Category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 

#DefaultObject . . . . . . . . . . . . . . . . . . . . . . . . . . .41 

#DefBehaviorFilter . . . . . . . . . . . . . . . . . . . . . . . .42 

#DefSyncFilter . . . . . . . . . . . . . . . . . . . . . . . . . . .41 

#NoDefaultObject. . . . . . . . . . . . . . . . . . . . . . . . .41 

#NoDefBehaviorFilter. . . . . . . . . . . . . . . . . . . . . .42 

#NoDefSyncFilter. . . . . . . . . . . . . . . . . . . . . . . . .41 

^self (pseudo variable). . . . . . . . . . . . . . . . . . . .30 

messages to ~ . . . . . . . . . . . . . . . . . . . . . . . .62 

see also object manager 

^server (pseudo variable) . . . . . . . . . . . . . . . . .30 

messages to ~ . . . . . . . . . . . . . . . . . . . . . . . .62 

see also object manager 

A 

abstract communication type . . . . . . . . . . . . . .73 

ACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 

active message . . . . . . . . . . . . . . . . . . . . . . .74, 77 

ActiveMessage (class) . . . . . . . . . . . . . . . .75, 148 

Any (type) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 

assignment statement . . . . . . . . . . . . . . . . . . . .28 

B 

behavior injection . . . . . . . . . . . . . . . . . . . . . . . .7 

C 

character literal . . . . . . . . . . . . . . . . . . . . . . . . .24 

class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 

~ parameter . . . . . . . . . . . . . . . . . . . . . . . . . .25 

~ switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 

declaration. . . . . . . . . . . . . . . . . . . . . . . . . . .39 

implementation part . . . . . . . . . . . . . . . . . . .40 

instance of a ~. . . . . . . . . . . . . . . . . . . . . . . .43 

interface part . . . . . . . . . . . . . . . . . . . . . . . . .39 

comment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 

composition filters object model . . . . . . . . .6, 15 

concurrency . . . . . . . . . . . . . . . . . . . . . . . . .45, 76 

condition. . . . . . . . . . . . . . . . . . . . . . . . . . . .16, 57 

~ in filterinitializer . . . . . . . . . . . . . . . . . . . .64 

conditional statement . . . . . . . . . . . . . . . . . . . .37 


177 

continue (dereification method). . . . . . . . . 78, 79 

control flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

requirements . . . . . . . . . . . . . . . . . . . . . . . . 51 

~ for the conditional statement. . . . . . . 52 

~ for the while and for statement . . . . . 52 

control structure . . . . . . . . . . . . . . . . . . . . . . . . 37 

conditional statement . . . . . . . . . . . . . . . . . 37 

for statement . . . . . . . . . . . . . . . . . . . . . . . . 37 

while statement . . . . . . . . . . . . . . . . . . . . . . 38 

D 

dereification . . . . . . . . . . . . . . . . . . . . . . . . 77, 78 

dispatch filter . . . . . . . . . . . . . . . . . .7, 69, 70, 108 

E 

early return . . . . . . . . . . . . . . . . . . . . . . . . . 51, 55 

error filter . . . . . . . . . . . . . . . . . . . . .7, 69, 70, 109 

exclusionelement . . . . . . . . . . . . . . . . . . . . . . . 64 

expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

message expression. . . . . . . . . . . . . . . . . . . 32 

operator expression. . . . . . . . . . . . . . . . . . . 33 

external . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 25 

F 

false . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

filter 

~condition . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

~element. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

exclusionelement . . . . . . . . . . . . . . . . . . 64 

inclusionelement . . . . . . . . . . . . . . . . . . 64 

rewrite rules . . . . . . . . . . . . . . . . . . . . . . 65 

~handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

dispatch . . . . . . . . . . . . . . . . . . . 69, 70, 108 

error . . . . . . . . . . . . . . . . . . . . . . 69, 70, 109 

meta . . . . . . . . . . . . . . . . . . . . . . 69, 71, 109 

send . . . . . . . . . . . . . . . . . . . . . . 69, 70, 109 

wait . . . . . . . . . . . . . . . . . . . . . . 69, 70, 109 

~initializer . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

declaration . . . . . . . . . . . . . . . . . . . . . . . . . . 63

178 

dispatch ~ . . . . . . . . . . . . . . . . . . 7, 69, 70, 108 

error ~ . . . . . . . . . . . . . . . . . . . . . 7, 69, 70, 109 

input filters . . . . . . . . . . . . . . . . . . . . . . .16, 62 

local ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

messagepattern . . . . . . . . . . . . . . . . . . . . . . 64 

matchingpattern . . . . . . . . . . . . . . . . . . . 64 

signaturepattern . . . . . . . . . . . . . . . . . . . 64 

meta ~ . . . . . . . . . . . . . . . . . . . . . 7, 69, 71, 109 

output filters . . . . . . . . . . . . . . . . . . . . . .16, 62 

reused ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

send ~. . . . . . . . . . . . . . . . . . . . . . 7, 69, 70, 109 

wait ~ . . . . . . . . . . . . . . . . . . . . . . 7, 69, 70, 109 

first-class object . . . . . . . . . . . . . . . . . . . . . . . . 22 

floating point literal. . . . . . . . . . . . . . . . . . . . . 24 

for statement. . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

G 

global external . . . . . . . . . . . . . . . . . . . . . . . . . 28 

I 

implementation part . . . . . . . . . . . . . . . . . . . . 19 

inclusionelement . . . . . . . . . . . . . . . . . . . . . . . 64 

initial method . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

inner (pseudo variable) . . . . . . . . . . . . . . . . . . 30 

during method invocation . . . . . . . . . . . . . 55 

messages to ~ . . . . . . . . . . . . . . . . . . . . . . . 62 

input filters . . . . . . . . . . . . . . . . . . . . . . . . . .16, 62 

instance variable . . . . . . . . . . . . . . . . . . . . .16, 25 

integer literal . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

interface method . . . . . . . . . . . . . . . . . . . . . . . 45 

interface part . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16, 25 

L 

literal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

character . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

floating point . . . . . . . . . . . . . . . . . . . . . . . . 24 

integer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

number. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

local variable . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

M 

main method . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

matchingpattern . . . . . . . . . . . . . . . . . . . . . . . . 64 

message 

active ~ . . . . . . . . . . . . . . . . . . . . . . . 74, 77, 97 

dereification. . . . . . . . . . . . . . . . . . . 77, 78, 112 

continue . . . . . . . . . . . . . . . . . . . . . . . .78, 79 

reply . . . . . . . . . . . . . . . . . . . . . . . . . . .79, 80 

send . . . . . . . . . . . . . . . . . . . . . . . . . . .79, 82 

Index 

filtering a ~. . . . . . . . . . . . . . . . . . . . . . 66, 101 

recursive ~ . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

reification . . . . . . . . . . . . . . . . . .73, 77, 77, 112 

reified ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 

sending a ~ . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

message (pseudo variable) . . . . . . . . . . . . 30, 75 

during condition invocation. . . . . . . . . . . . 59 

during method invocation . . . . . . . . . . . . . 55 

messages to ~. . . . . . . . . . . . . . . . . . . . . . . . 62 

message expression . . . . . . . . . . . . . . . . . . . . . 32 

message representation . . . . . . . . . . . . . . . . . . 97 

messagepattern . . . . . . . . . . . . . . . . . . . . . . . . . 64 

matchingpattern. . . . . . . . . . . . . . . . . . . . . . 64 

signaturepattern . . . . . . . . . . . . . . . . . . . . . . 64 

meta filter . . . . . . . . . . . . . . . . . . . . .7, 69, 71, 109 

method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

~ invocation . . . . . . . . . . . . . . . . . . . . . 54, 109 

~ parameter . . . . . . . . . . . . . . . . . . . . . . . . . 25 

control flow in a ~ . . . . . . . . . . . . . . . . . . . . 50 

early return ~ . . . . . . . . . . . . . . . . . . . . 51, 111 

invocation of an ~ . . . . . . . . . . . . . . . . . 55 

initial ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

interface ~ . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

main ~. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

normal ~ . . . . . . . . . . . . . . . . . . . . . . . . 51, 111 

invocation of a ~ . . . . . . . . . . . . . . . . . . 55 

private ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

returning a value from a ~ . . . . . . . . . . . . . 49 

returntype . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

N 

nil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

normal return . . . . . . . . . . . . . . . . . . . . . . . 51, 55 

O 

object manager . . . . . . . . . . . . . . . . . . .30, 44, 116 

^self . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

^server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

ObjectManager (class) . . . . . . . . . . . . . . . . 44, 150 

operator expression . . . . . . . . . . . . . . . . . . . . . 33 

output filters . . . . . . . . . . . . . . . . . . . . . . . . 16, 62 

owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

P 

private method . . . . . . . . . . . . . . . . . . . . . . . . . 48

pseudo variable . . . . . . . . . . . . . . . . . . . . . . . . .29 

^self. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 

^server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 

inner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 

message . . . . . . . . . . . . . . . . . . . . . . . . . .30, 75 

messages to ~ . . . . . . . . . . . . . . . . . . . . . . . .62 

self . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 

sender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 

server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 

R 

reification . . . . . . . . . . . . . . . . . . . . . . . . . . .77, 77 

reified message . . . . . . . . . . . . . . . . . . . . . . . . .77 

reply 

(dereification method) . . . . . . . . . . . . . .79, 80 

(method return). . . . . . . . . . . . . . . . . . . . . . .50 

return 

early ~ . . . . . . . . . . . . . . . . . . . . . . . . . . .51, 55 

normal ~ . . . . . . . . . . . . . . . . . . . . . . . . .51, 55 

return statement . . . . . . . . . . . . . . . . . . . . . . . . .50 

returntype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 

S 

self (pseudo variable) . . . . . . . . . . . . . . . . . . . .30 

during method invocation . . . . . . . . . . . . . .55 

messages to ~ . . . . . . . . . . . . . . . . . . . . . . . .62 

send (dereification method) . . . . . . . . . . . .79, 82 

send filter . . . . . . . . . . . . . . . . . . . . . 7, 69, 70, 109 

sender (pseudo variable). . . . . . . . . . . . . . . . . .30 


messages to ~ . . . . . . . . . . . . . . . . . . . . . . . .62 

server (pseudo variable) . . . . . . . . . . . . . . . . . .30 


messages to ~ . . . . . . . . . . . . . . . . . . . . . . . .62 

signature of an object . . . . . . . . . . . . . . . .68, 106 

signaturepattern . . . . . . . . . . . . . . . . . . . . . . . . .64 

<strong>Sina</strong>Message (class). . . . . . . . . . . . . . . . . .86, 149 

<strong>Sina</strong>Object (class) . . . . . . . . . . . . . . . . . . . .41, 147 

<strong>Sina</strong>Repository (global external). . . . . . 28, 29, 49 

statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 

assignment ~ . . . . . . . . . . . . . . . . . . . . . . . . .28 

conditional ~ . . . . . . . . . . . . . . . . . . . . . . . . .37 

for ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 

message expression . . . . . . . . . . . . . . . . . . .32 

operator expression . . . . . . . . . . . . . . . . . . .33 

return ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 

while ~. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 

string literal . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 

synchronization . . . . . . . . . . . . . . . . . . . . . . . .116 

T 

thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74, 75 

TRESE project. . . . . . . . . . . . . . . . . . . . . . . . . . .3 


179 

true . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

type 

~description . . . . . . . . . . . . . . . . . . . . . . . . . 26 

Any . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

method return~ . . . . . . . . . . . . . . . . . . . . . . 45 

V 

variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

assignment . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

class parameter . . . . . . . . . . . . . . . . . . . . . . 25 

declaration . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

external. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

global external. . . . . . . . . . . . . . . . . . . . . . . 28 

initial value . . . . . . . . . . . . . . . . . . . . . . . . . 28 

instance ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

local ~. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

method parameter . . . . . . . . . . . . . . . . . . . . 25 

typedescription . . . . . . . . . . . . . . . . . . . . . . 26 

W 

wait filter . . . . . . . . . . . . . . . . . . . . . .7, 69, 70, 109 

while statement. . . . . . . . . . . . . . . . . . . . . . . . . 38

Sina/st - trese - Universiteit Twente

Create successful ePaper yourself

Delete template?

Save as template?