LISP AND SYMBOLIC COMPUTATION An International Journal

c

Kluwer Academic Publishers Manufactured in The Netherlands

Applications of Telos

PETER BROADBERY pabmathsbathacuk

CHRISTOPHER BURDORF cbmathsbathacuk

School of Mathematical Sciences University of Bath Bath BA AY United Kingdom

Keywords Eulisp Telos p ersistence nalizatio n virtual shared memory

Abstract EULISP has an integrated ob ject system with reective capabiliti es We

discuss some example application s which use these facilities to exp eriment with some

advanced and p owerful concepts namely nalization virtual shared memory and p ersis

tence A secondary goal is to attempt to illustrate the additional p ossibili ties of metaob

ject programming over nonmetalevel techniques

Intro duction

EULISP provides an ob ject system called Telos which is fully inte

grated with the rest of the language and includes a metaob ject proto col

MOP which allows programs to reect on the structure and inheri

tance relationships b etween classes Reection here is the pro cess of taking

a system ob ject such as a class and transforming it into a userlevel ob ject

which a program can read and p erhaps mo dify Using this structure a pro

gram is free to change the representation and computation of these asp ects

to obtain new b ehaviour by sub classing existing classes and metaclasses

These new classes have the same status as the systemdened classes so

the extensions b ecome a part of the original languageno sp ecial co de is

needed to use them

This pap er comes in ve parts First we intro duce the Telos MOP from

a users p oint of view with a particular emphasis on the slot access pro

to col After this we lo ok at a fairly simple extension of the slot access

proto col to add nalization section Two larger scale applications are

virtual shared memory mo del section and p ersistent ob jects section

The last section diers from the earlier ones in that instead of b eing

illustrative fragments of metaob ject programming it describ es a complete

application written using EULISP and Telos which dep ends heavily on Telos

in order to create an interface into an ob ject store for simulation programs

A secondary asp ect of this last part is that the system in question was

originally written in CLOS and had rst to b e p orted to EULISP b efore the

BROADBERY AND BURDORF

extensions describ ed here were made

Metaob ject proto cols and Telos

A detailed description and rationale for the design of Telos app ears in

Two principles of the design are i a program should not pay for the cost of

a feature that it do es not use also known as don use dont lose ii as

large a prop ortion as p ossible of the metaob ject level op erations should b e

done when classes are created rather then when they are usedin eect a

form of compiletime versus runtime tradeo A consequence of this second

prop erty is that the creation and access routines can b e extended without

imp osing overheads on other programs and with minimal overheads on the

client program

There are four comp onents to the Telos MOP

 Class denition and inheritance

 Slot accessor creation and invo cation

 Generic function dispatch

 Ob ject allo cation and initialization

Each of these consists of a numb er of generic functions which have dened

semantics and are guaranteed to b e called at sp ecic p oints in the proto col

Of course these proto cols are not entirely separateeach relies on the

existence of the other three to function but the actual details of each

proto col are largely indep endent of one another New b ehaviour is obtained

by sub classing the classes sp ecied in the denition and sp ecializi ng the

appropriate parts of the MOP for the new classes

Sp ecializi ng slot access

The Telos slot creation and access proto col diers from the CLOS

proto col in a numb er of imp ortant ways but primarily the balance of work

is shifted from the access proto col to the creation proto col

The slot accessor creation routine has four phases Figure

 Create slotdescription ob jects

 Finalize the details of the ob ject representation

 Create the slot accessor functions

 Create sp ecialized slot accessors

APPLICATIONS OF TELOS

computeinheritedslotdescriptions

computeslotdescriptions

computeandensureslotaccessors

ensureslotreader

computeprimitivereaderusingclass

computeprimitivereaderusingslotdescription

ensureslotwriter

computeprimitivewriterusingclass

computeprimitivewriterusingslotdescription

Figure slot access proto col

Each phase allows the programmer to sp ecialize the slot in dierent ways

add extra slots to the class in the rst and move slots and allo cate space

for hidden slots in the second However the last two are probably the most

commonly used one can change the function used to dispatch slot access

in the third phase whilst the last enables arbitrary functions to b e called

at slot access time

Where the slot description is an instance of localslotdescription

the default case accessing a slot is just an indexed reference or up date

op eration However this can b e sp ecialized at will The exibility of this

approach can b e used to build complex systems from the primitive functions

provided by EULISP In the following sections we describ e some applications

that use this technique

Finalization

In many applications it is required to do some p ostpro cessing when it can

b e established that an ob ject will no longer b e needed This pro cess is

known as nalization For example many systems require that close

should b e called on a le ob ject b efore a program is exited otherwise

the stored version of the le may b e inconsistent with the version held

by the program due to buering by either the op erating system or the

application program The problem is that a program may lose a p ointer

to such an ob ject and never b e able to run the nalization co de on it

b efore the ob ject is recycled by garbage collection after which nalization

is imp ossible To circumvent this situation we need to b e able to to note

when an ob ject b ecomes inaccessible recover its slots from some hidden

storage and invoke a tidying op eration on the ob ject

The Bath implementation of EULISP provides two extensions to the lan

guage that simplied the implementation the system allows the user to

BROADBERY AND BURDORF

defclass file

create a class with a slot to be used in the nalization method

file initarg file

accessor fileinternal

slotclass finalizablesd

class finalizableclass

initargs openargs

constructor opensafefile openargs

open a le and set the actual hand le

defmethod initialize x file lst

let new callnextmethod

setter fileinternal new

apply open findkey openargs lst

new

tidy up the le

defmethod finalize x file

close fileinternal x

Figure Finalization of a le handle

install a function which is called directly after each garbage collection a

p ostGC ho ok and secondly a new class of ob jectweak wrapp ers It is

guaranteed that the p ost garbage collection function is never called during

the execution of a previous nalize and always runs on the which in

voked the garbage collection pro cess The purp ose of these rules is to avoid

problems with innite lo ops and concurrency resp ectively Weak wrapp ers

are ob jects with a single slot which initially contains some ob ject but is

set to nil if the ob ject is garbage collected during a garbage collection

references from weak p ointers are not followed therefore the referenced ob

1

ject may b e garbage collected These two extensions and the facilities of

Telos allow the implementation of a simple nalization scheme

The idea is to store the slot values of an ob ject that are needed for

nalization somewhere safe so that when the space o ccupied by the ob ject

is recovered by garbage collection the values that were stored in the nal

ization slots are still available Under the proto col for this implementation

of nalization each class which needs this facility is required to nominate

a proxyclass with similarly named slots for the values needed for the

nalization metho d The proxy class defaults to the class itself When the

1

One do es not absolutely need the p ost GC callback as one could use the wait prim

itive with a timeout but the GC callback is more ecient

APPLICATIONS OF TELOS

defclass finalizableclass class

count accessor finalizableslotcount

proxy accessor proxyclass

initargs proxy

class initialization

defmethod initialize cl finalizableclass lst

let cl callnextmethod

let slotposn classinstancesize cl

setter classinstancesize cl slotposn

setter finalizablehandleposn cl slotposn

cl

instance al location

defmethod allocate cl finalizableclass lst

let handle makevector finalizableslotcount cl

obj callnextmethod

setter primitiveslotref cl

finalizablehandleposn cl

handle

obj

Constructing new proxy objects

defun makeproxyobject class values

let newcl proxyclass class

let obj allocate newcl proxy t

do lambda sd

slotdescriptionslotwriter

findslotdescription newcl

slotdescriptionname sd

obj

vectorref values slotdescriptionposition sd

classslotdescriptions class

obj

Figure Fragment of nalization co de

original instance is garbage collected the change of status can b e detected

in the weak wrapp er and the slot values can b e recovered The naliza

tion metho d is then executed on an instance of the proxyclass with the

proviso that this particular instance cannot b e nalized From the co de in

Figure you will see that a slot is added to the instance to b e nalized

when it is allo cated This slot is initialized with a vector in which the slot

BROADBERY AND BURDORF

values needed for nalization are stored The vector is also reachable via

an asso ciationlist indexed by a weak p ointer referencing the ob ject to b e

nalized

When an ob ject b ecomes unreachable the p ostGC function instantiates

the proxyclass makeproxyobject with the slot values from the vec

tor and calls the nalization routine with the resurrected ob ject If the

proxy class is by coincidence sub ject to the nalization scheme then an

argument is passed to the allocate metho d to ensure that the resurrected

ob ject is not added to the nalization list See Figure

This technique is adequate in most circumstances but cannot nalize

a cyclic structure as the values of the slots are accessible via nonweak

p ointers It should b e noted that it is hard to dene an algorithm for

nalizing circular structures which picks the correct p oint in the cycle to

breakmore likely this indicates that the structure of the ob jects needs

to b e rethought although an extra level of indirection can generally b e

used to achieve a similar eect To handle cyclic structures prop erly more

information must b e given to the pro cessor ab out how the ob jects interact

Networks without cycles take n cycles to b e completely nalized where

n is the diameter of the network To do b etter than this the garbage

collector would have to b e mo died to make another pass over the weak

p ointers after the nalization phase is complete which could seriously aect

the p erformance of the system when no nalization is required Including

such extra routines would complicate the garbage collection suciently that

sto ck algorithms would not b e able to handle it whereas it was desired

to make the system reasonably p ortableevery implementation of Telos

so far has b een on a system with some kind of weak p ointer generally

provided as an extension The other advantage of this approach is its

relative simplicitythe co de itself is quite short lines and quite

readily comprehensible

Virtual Shared Memory

Virtual Shared Memory VSM is a software technique for simulating the

shared memory of many parallel architectures on a network of pro cessors

with lo cal memory only giving ob jects a form of spatial p ersistency

It can also b e viewed as an abstraction for passing data b etween multiple

physically disjoint pro cesses without message passing It involves inventing

a virtual arena in which ob jects are stored and some interface to deal

with an ob jects allo cation and slot access The idea is to add a mechanism

whereby ob jects can b e passed b etween pro cesses without the exp ense of

copying the ob jects at each communication Such a system is useful for a

variety of reasons

APPLICATIONS OF TELOS

distributed data structures The pro cessors can coop erate to form a

large data structure which is accessible equally from all pro cessors

hides message passing Client programs do not need to know that other

pro cesses will b e asking for data in their spaceso message handling

co de do es not need to b e written explicitly

more familiar programming mo del The concept of a numb er of ob

jects interacting via shared memory is more familiar to the program

mer than disjoint memory spaces

On the other hand such a system do es have its drawbacksthe relative

sloth of a network is hidden by the abstraction so it is easy to write slow

co de suering from the delusion of uniform access cost Consistency mo dels

may add even more ineciency to this proto col

The abstraction of VSM should b e capable of expansion in several ways

memory consistency For some applications up dates to ob jects never

happ en for example if the program is totally functional or at the

other extreme up dates must b e atomic and no ob ject must copied

without an invalidation proto col Both should b e accommo dated

garbage collection It should b e p ossible to write a garbage collector on

top of the abstraction so that deallo cation is handled by the system

rather than by some adhoc metho d

ob ject naming One should b e able to retrieve ob jects by indirect mech

anisms such as pattern matching This would provide Lindalike

functionality

eciency The default mechanism should not have an excessive overhead

for the most common cases For example multiple reads of the same

slot and additional classes can override parts of the proto col so that

they may b e yet more ecient

The current version of VSM consists of a numb er of classes of ob ject which

interact with Telos to provide a simple virtual memory system and supp ort

for proto cols such the system could b e extended to supp ort more of the

other mechanisms listed

Layout of memory

The allo cation of memory closely mirrors that of the underlying Lisp

systemob jects are allo cated from pages a xedsize group of slots or

ob jects which are in turn allo cated by a distributed allo cator which tracks

BROADBERY AND BURDORF

memory usage to ensure that it do es not swamp the rest of the system

The pages store either atomic data such as instances of strings symb ols

and numb ers or addresses of instances of other ob jects stored in the VSM

system

Implementation

The classes used in the implementation are designed to b e sub classed

and provide an extension to Telos to encompass allo cation strategy garbage

collection and distribution of data The implementation is made up of four

abstract classes of ob ject

page Actually holds the information These are sent atomically through

the distribution layer

address Contains a page p ointer and an oset Used to reference ob jects

handle The part of an ob ject used to store its address

ob ject Seen by users of the VSM co de

The VSM system consists of a proto col which new page and address

classes can sp ecialize plus a numb er of implementations of these abstract

classes Normal application co de do es not need to b e aware of this pro

to col although if new page and address classes are dened it must b e

observed One change from the dened semantics of EULISP is that ob jects

may not app ear to b e eq to themselves b ecause of caching arrangements

a page may leave the lo cal pro cessor and return However it is arguable

whether eq should b e welldened or even used in these circumstances

The function eql which has an appropriate metho d to compare VSM ad

dresses must b e used instead

Pages are held in caches on lo cal pro cessors with a reference to the pages

owning pro cessor and when a page fault o ccurs the system then queries

the pages owner ab out its lo cation Once found the page is copied to the

pro cessor

Other page lo okup mechanisms are p erfectly p ossiblea message can

b e sent to the owner of the page on every request and the owner replies

with the appropriate ob ject Other mechanisms can b e supp orted by the

proto col and work is in progress exploring the advantages of some of these

Without a means of starting remote threads VSM is not esp ecially useful

Currently the system uses a version of futures although a paralation

implementation has also b een develop ed The underlying interpro

cess communications mechanism is PVM although this is transparent to the rest of the system

APPLICATIONS OF TELOS

The system is strictly exp erimental and has b een designed to p ermit

exp eriments to b e made on the eciency and interaction of various con

sistency proto cols page caching and replacement algorithms and garbage

collection The integration of VSM with p ersistence is b eing investigated

so that one can employ b oth temp oral and spatial p ersistency in a system

Persistence

Persistence has b een explored as a topic in its own right as a means to sup

p ort largescale ob jectoriented simulation in EULISP This section discusses

that exp erience

Persistent ob ject systems POS aim to provide a seamless integration

b etween a programming language and a database The POS requires a

cache to hold ob jects which have b een loaded into primary memory to avoid

the need for reloading an ob ject each time it is accessed The p ersistent

ob ject cache can b e viewed as similar to the working set in a virtual memory

system The size of the cache has to b e limited so as not to swamp the

runtime system with more ob jects than can exist without exceeding the

size of swap space Also since ob jects may b e shared with other users it

is not desirable for any one user to have control over to o many ob jects at

a given time and therefore caches can also b e useful to limit the numb er

of ob jects owned by a user

Some of the advantages of p ersistent systems listed by Morrison and

Atkinson include

 reduced complexity

 reduced co de size and time to execute

 data outlives the program

Firstly complexity is reduced for the application builders b ecause with

p ersistent systems there is no distraction for the programmer in dealing

with the complexity of managing the database He or she need only con

sider the complexities involved in the mapping b etween the programming

language and the problem to b e solved Secondly p ersistent systems reduce

co de size b ecause the application program need not contain co de concerned

with the explicit movement of data b etween primary and secondary mem

ory Also the time to execute is reduced b ecause only ob jects required by

the system get loaded into primary memory Finally the data outlives the

program b ecause it resides in a database

In this section we discuss the implementation of a such a p ersistent ob

ject system designed for use in simulation applicationsThe Persistent

BROADBERY AND BURDORF

Simulation Environment PSE develop ed at UC Berkeley and some of

the problems encountered in p orting it from its original language Allegro

Common Lisp to EULISP

Persistence in PSE

PSEs p ersistent ob ject system supp orts sharing maintaining and in

sp ecting of ob jects Sharing of p ersistent ob jects has not b een pursued

b ecause it involves issues of transaction management and is not one of the

primary goals of this work Other p ersistent ob ject languages for example

GEMSTONE and Picasso are researching this topic and their results will

contribute to the success of p ersistent ob ject systems

In general an ob ject which is declared to b e p ersistent is retained in sec

ondary storage after program execution terminates In PSE once a class

has b een declared to b e p ersistent instances of that class will automatically

b e made p ersistent However from the programmers p ersp ective p ersis

tent ob jects in PSE are referenced identically to nonp ersistent simulation

ob jects Furthermore fetching and instantiating of a p ersistent ob ject from

secondary storage is p erformed transparently by the underlying PSE kernel

The kernel implementation of PSE is based on Rowes SOH shared

ob ject hierarchy metho dology

PSE is comp osed of the following comp onents pictured in Figure p er

sistent ob ject les ob ject space and an ob ject directory The ob ject les

store an ascii representation of the ob jects in secondary storage Ob ject

space denotes the area in main memory where the ob ject structures re

side and the ob ject directory contains one handle p er ob ject which maps

an ob ject identier into the ob ject handle The ob ject handle contains

metainformation ab out the ob ject and always remains in main memory A

handle includes information such as i a p ointer to the ob jects memory lo

cation which is nil if the ob ject is not present in the ob ject space ii the

ob jects lo cation in the ob ject le iii whether or not the ob ject has b een

mo died iv the ob jects up date mo de The up date mo de indicates how

the ob ject will b e mo died on disk If the mo de is directupdate the ob ject

will b e up dated immediately up on mo dication If it is deferredupdate

the ob ject will b e up dated when the numb er of ob jects in the ob ject space

reaches capacity thereby triggering garbage collection of the ob ject direc

tory and up dating of necessary ob jects Localcopy ob jects only exist in

main memory and therefore are not up dated on disk

The database consists of several les One le stores the ob jects and

there are separate les for the caches and the classes Each ob ject is stored

as a xedsized record If an ob ject is mo died to increase its size such that

it exceeds the xed size allo cated then the ob ject is moved to the end of the

APPLICATIONS OF TELOS

PSE Object Object Space Directory persistent object files

airplane1 airplane1: color red

Application Program

object object space file pointer ... pointer

x= airplane1

y= color(x)

Figure Comp onents of PSE

le Its size allo cation is then increased to meet its new sp ecication The

system also contains a routine that will garbage collect the unreferenced

ob jects in the database

During program execution ob ject handles are used as parameters to

represent simulation ob jects When a slot in an ob ject is referenced one

of two actions is taken if it is determined that the ob ject is not in main

memory then it is fetched and instantiated b efore the slot value is returned

Alternatively if the ob ject is already in main memory the value of the slot

is simply returned As mentioned earlier the determination of the ob jects

lo cation fetching and instantiation are handled by the p ersistent ob ject

system and is transparent to the programmer

The system provides a set of parameters that can b e used to tune p er

formance For example the total size of ob ject space and the size of the

ob ject directory It is also p ossible to extract infomation on the dynamic

sizes of these ob jects so that a program may adjust the upp er limits as nec

essary The combination of these system parameters with the three choices

of up date mo des provides users with facilities for comparing p erformance

under dierent PSE system constraints

BROADBERY AND BURDORF

Porting PSE to EULISP

Concurrency provides the p ossibility of reducing the real execution time

of a program through simultaneous execution of dierent co de segments

PSE was p orted to EULISP b ecause it provides a thread facility on the Star

dent Titan multipro cessor which allows the implementation of concurrent

programs The comp onents p orted to EULISP include the p ersistent ob ject

system describ ed ab ove and the discreteevent and pro cessbased simu

lation utilities Those comp onents had previously b een implemented in

Common Lisp at RAND Corp oration

The p ort of PSE to EULISP required a signicant amount of eort b ecause

the entire interface with the ob ject system had to b e rewritten and EULISP

mo dules provide a more austere environment than Common Lisp packages

the EULISP language prefers to gain runtime eciency at the exp ense

of developmenttime aids such as binding names at runtime and the eval

construct In the Common Lisp version of PSE the ob ject system had b een

merged with the le system through lowlevel mo dications A new EULISP

metaclass was created for p ersistent classes and ob jects and metho ds were

added at the lowlevel to handle access and mo dication of these ob jects

Implementing p ersistent classes as the hardest part In Common Lisp

when a class was input from the database PSE would construct a call

to defclass and eval to instantiate the class This technique was not

p ossible in EULISP b ecause it do es not have eval Another problem is

that when a class is created the accessors for the slot values need to b e

dened In Common Lisp defclass denes the accessors However in

EuLisp the lack of eval makes it imp ossible to construct and execute a

call to defclass as in Common Lisp Calling make on the metaclass is one

alternative but make do es not create the accessors so that would have to

b e done manually A problem further arises when creating the accessors in

EuLisp at run time b ecause the accessor functions must b e b ound to the

accessor names but EULISP do es not allow the creation of new bindings in

mo dules at run time This problem was only partially solved by having

the accessor names dened at system load time This restriction means the

EULISP version of PSE do es provide p ersistent classes seamlessly in the way

of the Common Lisp version Additionally we note that it required more

than twice as much co de to implement p ersistent classes in EULISP than it

did in Common Lisp

Likewise mo dule restrictions made it dicult to have applications re

side in separate mo dules from the PSE mo dule Since EULISP do es not

allow mutually referential mo dules it was necessary to dene all p ersis

tent classes in the PSE mo dule b ecause lo cal bindings can only b e done in

macro expansions and the functions to build the accessors are in the PSE

APPLICATIONS OF TELOS

mo dule Therefore since the accessors were dened in the PSE mo dule

the application must b e a part of the PSE mo dule if it wants to use the

slot accessors

There are some compromises that can b e made to alleviate this problem

The rst compromise would b e to store classes in their own mo dule then

all of the slot accessors would have to b e declared in the exp ort list of the

mo dule This solution is quite unsatisfactory though b ecause when one

imp orts a mo dule of classes it will load all of the classes in that mo dule

instead of loading classes as demanded by the program Also it requires the

application programmer to structure their co de dierently from how they

would if the classes were nonp ersistent This requirement violates the

denition of p ersistent systems as having a seamless interface b etween the

program and the database Another solution which was implemented was

to provide a construct called persistentclasses This construct is used when

loading classes from an already existing database When p ersistent classes

are dened the system stores co de in the database which when loaded into

EuLisp and executed will create the accessors for a class and bind them

to the slotnames listed in the call to persistentclasses Thus the use of

the persistentclasses construct do es create a seam of sorts b etween the

program and database but it is less of a seam than would b e necessary if

the classes were required to b e in a dierent mo dule

On a more p ositive note EULISP slot descriptions provided an elegant

solution to the problem of access and mo dication of p ersistent slots A

macro called defdbclass was dened which caused all slot classes to b e

persistentslotclass Then a slot access metho d was dened on

persistentslotclass to handle the sp ecic mechanics of access and

mo dication of a p ersistent slot as describ ed previously

The remaining work of the p ort was sp ent dealing with technical dier

ences b etween EULISP and Common Lisp of which there are many but are

not of great interest so they will not b e discussed further

Applications of Persistence

One of the advantages of Lisp is that it can b e used as an assembly language

to build higherlevel constructs using macros that are tailored for sp ecic

domains such as rulebased systems natural language pro cessing and even

simulation It has b een found to b e advantageous to incorp orate the pre

viously describ ed p ersistentob ject facility into higherlevel constructs for

Petri net and connectionist simulations b ecause in the case of Petri nets

they can store the simulation history for later reference and in the case

of connectionism they can store information gained through the building

and training of the network for reuse

BROADBERY AND BURDORF

Concurrent Pro cessbased Simulation

The motivation for concurrency is to improve the p erformance of simu

lations However to execute a p ersistent ob jectbased simulation requires

proto cols to manage the concurrency to ensure that the simulation seman

tics are not altered from its sequential version The choice was made to

implement concurrency at the event level rather than the database trans

action level b ecause if dep endent events are synchronized on each ob ject

database transactions will b e sychronized as well Eventlevel sychroniza

tion will allow indep endent events eg move car to station X process rst

car on station Y to execute in parallel Dep endent events which act on the

same ob ject eg move car A to station X process car A at station X will

b e executed in lo ckstep Since events are the parallelizable unit if they

are synchronized based on the write sets of ob jects a writeset is a group

of ob jects that are dep endent on each other b ecause they mo dify or access

the same mutable attributes so will the database transactions they gen

erate If dep endent events are sychronized then all database transactions

will b e serialized for each ob ject b ecause events are the driving apparatus

of the simulation and the only agent which pro duces database op erations

Thus the environment demands a proto col which will control concurrency

for events and the transactions will follow suit

As is describ ed in conservative proto cols were chosen The main

advantage b eing that conservative mechanisms require less primary memory

than optimistic ones b ecause there is no need to save the state each time

an event is pro cessed and input queues contain no antimessages Also in

the case of p ersistent systems there is no need to save mo dications to the

database b ecause due to the lo ck step execution of events for each ob ject

once mo dications are made there is no need for the proto col to undo them

which is necessary under optimistic mechanisms

Connectionism

Connectionist mo dels provide a mechanism for representing knowledge

through connections b etween neurons Those connections are weighted to

represent the certainty factors b etween semantic relationships Due to the

recent increase in interest in the use of connectionist and neural systems

there has b een active development in to ols that supp ort their development

POCONS Persistent Ob ject CONnectionist Simulator is a new

comp onent added to the EULISP version of PSE which supp orts ob ject

oriented connectionist simulation With the exception of Neula other

neural network to ols do not supp ort an ob jectoriented design metho dology

Both Neula and NSL have ob jectoriented constructs but dier in their

APPLICATIONS OF TELOS

defdbneuron hobbit middleearthinhabitant

nature initform good

height initform short

isfondof initform birthdayparties

swimming

fighting

hasenemy initform dragon

defdbneuron bilbo hobbit

isfondof initform pipeweed light

defdbneuron dragon middleearthinhabitant

hasenemy initform dwarf

nature initform evil

defdbopposites nature good evil

Figure Fragment of POCONS co de for a Middle Earth neural net

syntax and semantics which is unlike the widelyused ob jectoriented lan

guages like Smalltalk C or CLOS In addition POCONS

is close to CLOS and Telos in syntax and semantics thus there should b e

a shortened learning curve for programmers familiar with either systems

POCONS can b e used to develop hybrid symb olicconnectionist systems

since it is emb edded in Lisp which has b een used extensively for symb olic

inference It is also extensible b ecause it allows a user to create new neu

rons interactively and rebuild the neural network a feature not available

in the other ob jectoriented connectionist simulators like Neula and NSL

Also unlike Neula and NSL POCONS supp orts p ersistence and it uses

ob jects to represent relationships b etween dierent elements of the network

POCONS is a declarative language in that the programmer simply sp ec

ies the structure of the network enters a command to make the system

build the networks internal structure and initiates execution of a simula

tion

An ObjectOriented Connectionist Model

POCONS is based on the ob jectoriented connectionist mo del where the

user do es not sp ecify any pro cedural information ab out the networks ex

ecution The mo del only requires that the user sp ecify the neurons which

represent the comp onents of the network their attributes and relation

ships b etween them POCONS can then b e instructed to generate a neural

network Queries can b e made on the network which initiate connectionist

BROADBERY AND BURDORF

simulations

The underlying POCONS system translates connectionist ob jects into

sets of neurons that represent the class hierarchy and attributes Each

class has a neuron asso ciated with it and likewise the class neuron has

weighted isa links to the neuron which represents its sup erclass Also a

neuron is created for each class and slotvalue pair eg nature good

which has links to its class and the class has links to it

defdbneuron is the dening comp onent for the creation of a p ersistent

neuron and an example is given in Figure

The neuronname will b e used as a symb ol that identies the neuron The

superclasses sp ecify the class or classes from which the neuron inherits The

slots describ e the explicit relationships that the neuron will have Slots are

sp ecied as an initialization list containing slotnames and slot options

defdbopposites indicates a relationship b etween two neuron typ es and

is dened as follows

defdbopposites slotname neuronname neuronname

defdbopposites can only take as arguments neuronnames used in calls

to defdbneuron The result of the use of defdbopposite will b e a nega

tive link b etween the two sp ecied neurons in the network Also the use

of defdbopposites generates a p ersistent ob ject containing the sp ecied

information Thus to reuse a sp ecic network after the rst time it was

executed one need only op en the database

The algorithm which converts this representation examines each ob ject

and a neuron is created for each neuron name and for each slot attribute

and value It then creates forward links from each sub class neuron to each

sup erclass neuron Links are also created from class neurons to their slot

neurons

For a more extensive description of POCONS including some examples

see and for exp eriments in mapping POCONS onto SIMD and MIMD

machines see

Petri nets

Petri nets are widely used in the simulation of concurrent systems

As a result of the p opularity of Petri nets a variety of to ols have b een

develop ed including ones for the graphical editing and creation of

Petri net systems This section describ es a to ol for the development of

Petri nets a language called Pertrans which features the fusion of

p ersistent ob ject technology with Petri net development Pertrans is a

comp onent added to the EULISP version of PSE

APPLICATIONS OF TELOS

Pertrans has features that simplify the task of developing sto chastic

Petri net mo dels It contains constructs that sp ecify the places transi

tions and token lo cations in the Petri net The underlying system handles

all the pro cedural execution of the simulation

Pertrans components

Pertrans provides an application programmer with primitives to repre

sent and execute simulations using the sto chastic Petri net mo del Pertrans

has the following general features

 Persistence

 Declarative

 Allows emb edded Lisp co de

It supp orts p ersistence b ecause all the various elements of the Petri net

mo del places transitions and tokens can b e represented as p ersistent

ob jects The application programmer can decide whether he or she wants

some or all of the net to b e p ersistent It is declarative in that the pro

grammer need not sp ecify any of the control information used to determine

when a transition will re and send tokens throughout the net The Per

trans dening forms generate an eventbased simulation that is executed

by the underlying scheduler and simulator of PSE The programmer need

only sp ecify the places and transitions where they are connected and any

time delays that might exist on transitions The internal scheduler exam

ines places and transitions to determine whether a transition is enabled

and when it should re It also passes tokens to places that are enabled

once a transition res The underlying scheduler sends messages to ob jects

that contain a time stamp for when they should execute The underlying

simulator then executes those messages at the appropriate simulation time

Finally Pertrans allows the application programmer to emb ed Lisp co de

in the denition of sp ecic no des places and transitions The emb edded

co de will b e executed when a token moves to the no des lo cation in the net

work Such emb edded co de can b e used to pro cess information or pro duce

graphical output illustrating the nets b ehaviour Graphical output can b e

pro duced in the X Window System as supp orted under Feel

Several Petri net mo dels have b een implemented using Pertrans and

it has b een extended to pro duce parallel simulations The Pertrans

language is explained in detail with examples in

BROADBERY AND BURDORF

Conclusions and Further Work

We have discussed the use of the Telos ob ject system in various program

ming problems and shown how it can b e used to construct applications

The use of an ob jectoriented language encourages a to olb ox of useful rou

tines to b e written which can then b e combined to form a complete appli

cation The addition of the metaob ject proto col allows this idea to extend

into the representations of classes as well as the interface they provide

One of the strengths of Telos is that it is integrated into its host language

EULISPto a greater degree than CLOSand can b e used to change parts

of the system which are commonly not part of the ob ject system for in

stance arithmetic op erations and threads This p ower in combination with

EULISPs mo dule system assists with b oth language extension and language

emb edding However exp erience with supp orting p ersistence suggests it

makes dynamic demands that are hard to reconcile with uncharacteristi

cally static tendencies of this Lisp which have b een motivated by a desire

to b e able to deliver more ecient applications Clearly this is an area for

further work

References

Atkinson M and Morrison R Persistent System Architectures In

Pro ceedings of the Third Annual Conference on Persistent Ob ject Sys

tems SpringerVerlag

Batey DJ DPL A Distributed Implementation of Paralation Lisp

Bath Mathematics and Computer Science Technical Rep ort

June

Bobrow D et al Common Lisp Ob ject System Sp ecication

XJ Do cument R

Bretthauer H Davis H Kopp J and Playford K Balancing the

EULISP Metaob ject Prototcol In Reection and Metalevel Architec

ture Pro c of the International Workshop on New Mo dels for Software

architecture Novemb er

Burdorf C Parallel Simulation of Sto chastic and Colored Petri Nets

Submitted for Publication

Burdorf C PerTrans A Persistent Sto chastic Petri Net Representa

tion Language In Pro ceedings of the nd Annual Pittsburgh Confer

ence on Mo deling and Simulation

APPLICATIONS OF TELOS

Burdorf C Compiling Connectionist Simulations for SIMD and MIMD

Architectures In Pro ceedings of the Europ ean Simulation Multi

conference So ciety for Computer Simulation

Burdorf C POCONS APersistent Ob jectbased Connectionist Sim

ulator In Pro ceedings of the SCS Western Multiconference

Ob jectOriented Simulation So ciety for Computer Simulation

Burdorf C and Fitch J Cloning Persistent Ob jects Under a Con

servative Mechanism for Concurrency Control In Pro ceedings of the

Europ ean Simulation Multiconference So ciety for Computer Sim

ulation

DAutrechy C Reggia J A Sutton G G and Go o dall SM A

GeneralPurp ose Simulation Environment for Developing Connection

ist Mo dels Simulation

Feldbrugge F Petri Net To ol Overview In Lecture Notes in

Computer Science Advances in Petri Nets

Feldman J A Fanty M A and Go ddard N H Computing with

Structured Neural Networks IEEE Computer

Floreen P Myllymaki P Orp onen P and Tirri H Compiling Ob

ject Declarations into Connectionist Networks AICOM

Geist G and Sunderam V Network Based Concurrent Computing on

the PVM System Oak Ridge National Lab oratory

Goldb erg A and Robson D Smalltalk The Language and its

implementation AddisonWesley Reading Massachusetts

Halstead Rob ert H Multilisp A Language for Concurrent Symb olic

Computation ACM Transactions on Programming Languages and

Systems Octob er

Hayes B Finalization in the collector interface In International Work

shop on Memory Management SpringerVerlag Septemb er

Jeerson D Virtual Time ACM Transactions on Programming Lan

guages and Systems July

Kiczales G des Rivieres J and Bobrow D The Art of the Metaob

ject Proto col MIT Press Cambridge Massachusetts

BROADBERY AND BURDORF

Kind A and Freidrich H A practical approach to typ e inference for

eulisp Published in this Journal

Marsan M Sto chastic Petri Nets An Elementary Intro duction In

Lecture Notes in Computer Science Advances in Petri Nets

Misra J Distributed DiscreteEvent Simulation Computing Surveys

March

Morrison R and Atkinson M P Persistent Languages and Architec

tures In International Workshop on Computer Architectures to Sup

p ort Security and Persistence of Information SpringerVerlag

Padget JA and Nuyens G Eds The EULISP Denition

in preparation

Peterson J L Petri Net Theory and the Mo deling of Systems

PrenticeHall Englewo o d Clis NJ

Playford K J and Broadb ery P A Feel An Implementation of Eu

Lisp Concurrent Pro cessing Research Group Scho ol of Mathematical

Sciences University of Bath June May b e obtained by anony

mous ftp from ftpbathacuk

Rowe L A A Shared Ob ject Hierarchy In International Workshop

on Ob jectOriented Database Systems IEEE

Sab ot G W The Paralation Mo del Architecture Indep endent SIMD

Programming MIT Press Cambridge MA

Stroustrup Bjarne The C Programming Language Addison Wes

ley second edition

Wang D and Hsu C SLONN A Simulation Language for mo deling

of Neural Networks Simulation

Weitzenfeld A Neural Simulation Language Version Technical

Rep ort Center for Neural Engineering University of Southern California August