A view of object-oriented programming - CiteSeerX

LIBRARY

RET,"

:\\

NAVAI

REPORTS DIVISION :

;HOOl

MONTEREY, CALIFOMIA 93940

NPS52-83-001

NAVAL POSTGRADUATE SCHOOL Monterey, California

A VIEW OF OBJECT-ORIENTED PROGRAMMING

Bruce J. MacLennan

February 1983

Approved for public release; distribution unlimited Prepared for:

FEDDOCS D 208.14/2:NPS-52-83-001

Naval Postgraduate School Monterey, CA 93940

NAVAL POSTGRADUATE SCHOOL Monterey, California

Rear Admiral J. J. Ekelund Superintendent

A. Schrady Provost

D.

The work reported herein was supported in part by the Foundation Research Program of the Naval Postgraduate School with funds provided by the Chief of Naval Research.

Reproduction of all or part of this report is authorized. This report was prepared by:

UNCLASSIFIED SECURITY CLASSIFICATION OF THIS PAGE (When Data

Entered)

READ INSTRUCTIONS BEFORE COMPLETING FORM

REPORT DOCUMENTATION PAGE 1.

REPORT NUMBER

2.

GOVT ACCESSION NO

3.

RECIPIENT'S CATALOG NUMBER

5.

TYPE OF REPORT

NPS52-83-001 4.

TITLE (and

Subtitle)

AUTHORS;

Bruce J 9.

.

PERFORMING ORG. REPORT NUMBER

S.

CONTRACT OR GRANT NUMBER* *) -

N00014-83-WR-20162

PERFORMING ORGANIZATION NAME AND ADDRESS

10.

61152N; RR000-01— 10

CONTROLLING OFFICE NAME AND ADDRESS

MONITORING AGENCY NAME

&

PROGRAM ELEMENT. PROJECT, TASK AREA 4 WORK UNIT NUMBERS

N0001482WR20043 12.

REPORT DATE

13.

NUMBER OF PAGES

'5.

SECURITY CLASS,

February 1983

Naval Postgraduate School Monterey, CA 93940 1*.

6.

MacLennan

Naval Postgraduate School Monterey, CA 93940 II.

PERIOO COVERED

Technical Report

A View of Object-Oriented Programming

7.

&

AOORESS(lt

different /ram Controlling Office)

(of thla report)

UNCLASSIFIED 15a.

DECLASSIFICATION/ DOWNGRADING

SCHEDULE 16.

DISTRIBUTION STATEMENT

'of this Report)

Approved for public release; distribution unlimited

17.

DISTRIBUTION STATEMENT

18.

SUPPLEMENTARY MOTES

19-

KEY WORDS

rot the abstract

.'Conllnua on reverse aide

entered

In

Block

20, If different Irom Report)

neceeaary and Identify by block number)

if

Object-oriented Programming, Value-oriented Programming, Applicative Programming, Functional Programming, Production Systems, Data-flow Languages, Information Hiding, Capabilities, Concurrency, Synchronization. 20

ABSTRACT

'Continue on reverae aide

It

neceaeary and Identity by block number)

The differences between values and objects and, hence, between valueoriented and object-oriented languages are clarified. It is argued that languages should have both values and objects; the proper role of each is described. A proposal is presented for a true object oriented programming system. This includes both an informal description of object-oriented programming constructs and a formal semantics for these constructs. Nondeterminancy, synchronization and recovery from failures are briefly discussed

DD

FORM 1

JAN

73

1473

EDITION OF 5

1

NOV

55

IS

N 0102- LF-0U- S601

OBSOLETE

KMrT.ASSTFTFn SECURITY CLASSIFICATION OF THIS PAGE (Whan Data

Bntarad)

A VIEW OF OBJECT-ORIENTED PROGRAMMING

B.

MacLennan

J.

Computer Science Department Naval Postgraduate School

Monterey, CA 93940

CONTENTS

1.

Introduction 1.1

What are Values?

1.2

What are Objects?

1.3

Objects in Applicative Languages

2.

Intension versus Extension

12

3.

Condition-Action Rules

14

4.

Indivisibility of Rules

19

5.

Examples

20

6.

Notational Extensions

22

6.1

Compound Rules

22

6.2

Sequential Blocks

23

-

l

-

6.3

Procedure Calls

24

6.4

Valueless Procedures

29

6.5

Applicative Expressions

30

6.6

Applicative Conditions

31

6.7

State Variables

33

7.

System Structure

34

8.

Formal Semantics

39

9

.

8.1

Abstract Syntax

39

8.2

State Space

40

8.3

Multiple-valued Functions

41

8.4

Semantics of Rules

42

3.5

Semantics of Execution

49

S

umma ry

51

10.

Acknowledgement

52

11.

References

53

-li-

A VIEW OF OBJECT - ORIENTED PROGRAMMING

B.

J.

MacLennan

Computer Science Department Naval Postgraduate School

Monterey, CA 93940

Abstract

.

Applicative programming languages and flow

machines

a

oriented

been

LISP

has

object-oriented.

data-

for

often described as value - oriented languages

are

Other languages, such .

languages

Smalltalk,

are

described

as

.

object -

described as both value-oriented and

What exactly do these terms mean?

This paper attempts to identify and clarify the

differences

between values and objects and, hence, between value-oriented and

object-oriented languages. of

whether

objects

The paper then turns to the

should be included in applicative languages in those

and the role they can fill

the

paper

is

a

proposal

oriented programming. of

for

for

constructs.

one

approach to

a

of

true object-

This includes both an informal description

Nondeterminacy

,

Introduction

-1-

a

formal semantics

synchronization

recovery from failures are briefly discussed.

1.

remainder

languages. The

object-oriented programming constructs and these

question

and

1.1

What are Values?

Value-oriented programming can be described use

the

memory.

The basic idea

of

is

or an updatable

side-effects,

variables,

without

the

that

value

programming

as

of

expression

an

depends only on its operands, and that the only effect of executThus the operators in

ing an expression is the value it returns. an expression are mathematical

functions.

Almost every programming language has set:

its

such as

this

(3

arithmetical + 2)

case),

the value,

sub-

The value of an expression

depends only on its input operands

and

(3

2,

in

the only effect of executing the expression is

and

5,

expressions.

value-oriented

a

returned.

One of the desirable

predictability.

We

can

characteristics tell

the

of

values

is

their

interfaces of an arithmetic

Since all of the functions

expression by simple inspection.

are

side-effect-free, all of the inputs and outputs of each functions are manifest .

This

simplifies

manipulation

of

value-oriented

expressions, and simplifies proving properties about them. What is it about values that give tics?

We

them

these

characteris-

have noted that the most value-oriented parts of most

programming languages are there most mathematical parts, so it no surprise to

is

find that mathematics is that discipline that most

consistently deals with values.

Hence, we can discover

many

of

the characteristics of values by studying mathematical entities.

-2-

What are these characteristics?

The fundamental property of

mathematical

entities

universals)

For example, the number two is an abstraction

subsumes

.

as

is

that they are abstractions

particulars

its

past

existence,

of

number of marbles in

the abstraction two remains.

but a

Particular pairs may come into or

or

go

Also, the

bag may be subsumed by the abstraction two

one time, and the abstraction three at

at

present,

Because mathematical entities are abstrac-

or future.

tions, they do not change.

out

that

all of the various pairs, whether

they exist in reality or our imagination, or in the the

(concepts,

ther abstraction has been altered.

later time, but nei-

a

Similarly,

it

not meaning-

is

ful to speak of the creation or destruction of a value; mathemat-

ical equations such as

among

=

2+3

relationships

timeless

describe

not descriptions of their creation, modification,

values,

or destruction.

concept

5

In this sense values are atemporal

does not apply to them.

time

to apply time concepts

to a number as

It it

is

is

that is,

;

the

just as meaningless

to apply

color

con-

cepts.

Another characteristic of values is that they are universal that is

is,

they are not particular

.

coextensive with the particulars

;

This is because an abstraction it

subsumes.

For

example,

the abstraction two is coextensive with all particular pairs, and

conversely, anything coextensive with all particular pairs is the

abstraction two

.

The result of this is that it makes no sense to

talk of "'this number two" or "that number two" or

many

number

two's are there?"

to

ask,

"How

These are concepts that apply to

-3-

particular things, and values are universals, not particulars. The characteristics of values can be summarized:

t

values are atemporal;

values are immutable; values are neither created nor destroyed;

values are universal. It can be seen now that applicative

tially

programming.

value-oriented

programming

In

a

purely

is

essen-

applicative

language, there is no assignment operation and no idea of

state.

Functions compute values solely on the basis of their inputs, and have no side-effects.

This is of course why applicative program-

ming is so mathematical;

it

i_s

mathematics.

Consider an applicative subset of LISP (i.e., without RPLACA and

RPLACD,

and with SQ restricted to atoms).

lists can be treated like tuples)

the

and

mathematical

entities

In this language

(specifically,

list processing operations can be treated like

mathematical functions on these entities.

Lists may be computed,

but they are not modified, created, destroyed, copied, or shared.

Again, applicative programming

(value-oriented

programming)

is

nature

of

essentially mathematics.

1

.

2

What are Objects? There

is

probably

more

confusion

-4-

about

the

,

object-oriented

programming

oriented programming (see, [Robson81],

[Rentsch82]

identify some of

than

characteristics

the

[Lomet76]

[MacLennan82]

)

[Lomet80]

,

In this section we

.

objects

of

of value-

nature

the

example,

for

and

about

object-

and

oriented programming. In object-oriented programming systems

all

computation

is

viewed

such

Here, programming

simulation.

as

Smalltalk,

as

language objects correspond to real-world objects, and

manipula-

of real-world objects are simulated by sending messages to

tions

the programming

language

objects.

programming

Smalltalk,

In

language objects are grouped into classes

abstractions) of

(i.e.,

similarly behaving objects. What is an object? common

We can get

use of the term.

a

clue to its nature from the

In common usage an object

entity existing in space or time. for

a

is

a

material

Let us consider what it

programming language object to exist

i_n

t

ime

means

This means

.

that it persists as an identifiable entity through some period of time, which in turn means that it can come into existence at some

point in time

existence

(i.e., be created)

at some point

common characteristic

objects

in

of

in time

and (i.e.,

objects

in

that

it

can

go

be destroyed).

computers;

for

out

This is

of a

example,

Smalltalk and Simula are created by explicit request

(the new operation),

and are

destroyed

by

a

garbage-collector

when they are no longer accessible. Just as real objects exist

_in_

_«;_

space

,

programming

language

objects

enter

may

into

a

number of relationships, spatial and

of another object, or

part

another object. object

are

In

an

by instance variables, whose values are

represented

knowledge,

be

operating system) the owner of

system like Smalltalk the attributes of

a

In data bases intended

themselves objects.

world

(in an

may

object

For example, one

otherwise, with other objects.

representing

nodes

represent

to

real-

are connected by

objects

labeled arcs representing relationships among the objects.

change

Real-world objects not only exist in time, they also through

time.

That

relationships with

is,

other

various factors can alter an object's

objects

(such

object's other attributes (such as size).

and

position)

as

This is in marked con-

Another

trast to values, which, as we have seen, are immutable. way

to

state

,

state

an

this is that at any point in time an object has

which is the sum-total of its relationship with all

a

other

objects in the system.

Various laws then determine how the state

of an object can change

in

in

time.

Of course,

the ultimate

change

state that any object can undergo is its creation or destruc-

tion. In systems like Smalltalk the

the

state

of

instance

variables

an object and the methods defined

determine

in the

object's

class determine the object's behavior in time. The mutability of objects leads to another of

tant

characteristics:

values are universal,

the notion of sharing. i.e.,

their

impor-

We have said that

that the concept of instance does not

-o-

apply

to

This is not the case for objects.

them.

finite number of properties are representable on puter

system,

it

is

properties,

same

objects.

It

is

oriented programs to have two point

in

time

finite

a

represent

yet

than

different

objects

have the same attributes.

universal

.

If

will

that

the

be visible to the other entity.

directly

same state)

cause

shared/non-shared

a

then

change

at

some

particular

two entities share access to the same

two entities each have access to

have

distinct

Thus, objects have an

object, then if one entity changes the state of the

change

com-

course quite common in object-

of

identity independent of their state, which makes them rather

a

quite possible that two programming language

objects have all the real-world

Since only

a

to

distinct

object,

the

Conversely, if the

objects

(that

might

change to the state of one will not state

the

of

the

other.

The

distinction is of course familiar from object-

oriented programming systems. The characteristics of objects can be summarized: t objects are

temporal; they exist in time;

t objects are mutable,

1

.

3

and have

a

state;

t

objects can be created and destroyed;

t

objects are particular, and can be shared. Objects in Applicative Languages. It would seem that objects should be excluded

from

applica-

programming

tive

many of the undesirable

have

They

systems.

such

characteristics of imperative languages, state,

a

changeable

dependence on the time sequence of events, and

strong

a

as

complications arising from the notion of sharing.

In

sec-

this

tion we will argue that this is not the case, that objects have

a

role in applicative languages.

the purpose of

The reason for this is simple:

a

program

is

often, directly or indirectly, the modeling of some aspect of the

real-world.

modeling

aspects

Further, the

often

world objects.

involve

in

changing relationships among real-

the

obvious

The

interested

are

we

that

approach

programming

use

to

is

language objects to model the real-world objects.

Given this observation it is not surprising cepts with

simulation

Smalltalk, languages,

gramming

languages,

one is

in

,

particular

in

widely

most

simulation

Chapter

[Kay77]

(see for example 1)

to

object-oriented

known

that

[Pr

i

tsker79]

,

pro-

all

Chapter

3

languages do

not

model the changing state of real-world objects.

imperative languages.

described by some value

and

are fundamental to our notion of objects.

technique is familiar from the use of denotational

describe

[Dahl70],

For these reasons many basic

.

It will be objected that applicative

objects

Simula

based on Simula and takes the view

ideas of simulation

[Maisel72]

the

of

con-

the

programming first arose in connection

object-oriented

of

that

,

semantics

need

The to

The total state of the system is

such as

a

-3-

sequence or

a

function.

This

value

input to an applicative state-transition function

the

is

that computes the value representing the new state.

Although this works, it is not very satisfactory. tend

to

accumulate large numbers of arguments, or highly struc-

composite

tured

defeats

arguments,

represent

the

acute

problem

The

operating-systems, real-time systems, graphics

in

software, data-base systems, and of course tions.

This

state.

of applicative programming by destroying the

goals

the

that

clarity and mathematical tractability of programs. becomes

Functions

in

simula-

explicit

For this reason the remainder of this paper will discuss

how objects can be best reconciled with applicative languages. We must first note an obvious point: the it

cannot be simulated inside

universe

becomes necessary

select

to

the

the a

entire

computer.

subpart

of

state

of

Therefore,

universe

the

relevant to the problem, and the appropriate level of abstraction for the simulation.

The

result

represented

by

is a

the

that

state

of

the

simulation

finite number of objects connected by

number of relationships.

is

a

finite

As the simulation progresses the

rela-

tionships among the objects may change and objects may be created or destroyed.

The relations and objects

corresponding

objects

and

described

above

can

be

termed

relations because they correspond to

the objects and relations in the real-world that they model.

system

The

may also contain non - corresponding objects and relations.

-9-

These do not necessarily correspond to any real-world objects relations,

but

used to implement the corresponding objects

are

and

objects and relations is analogous to the dis-

non-corresponding

programming

tinction in object-oriented visible

publicly

corresponding

Thus, the distinction between

and relations.

or

objects

between

languages

the

their abstract properties on one

and

hand, and the private objects and attributes

used

implement

to

the public ones on the other.

The non-corresponding objects are analogous ent

i

t

we cannot in general infer from

ies in a scientific theory:

like

the implementation details of

it

usually desirable

trol of name contexts.

non-corresponding

the

for

an

object

to

a

context

naming

a

The

is

objects

corresponding

that

class of objects

have

will

the non-corresponding objects and

and

relations

that

are

Thus,

intended

can be made public by giving them

are

name in

infor-

easily accomplished.

widely accessible context. texts

a

access

accessible capability list.

relations used to implement that class of objects.

mation hiding

and

This is analogous to having

in an

Generally, only the implementor of access

gain

That is, an entity can only

context accessible to that entity.

capability

objects

relation if that object or relation has

to an object or

a

Smalltalk or Simula object,

a

This can be accomplished by the proper con-

relations be hidden.

a

if

Thus,

objects.

real-world

them the existence of corresponding

is

theoretical

to

used

Of course,

to accomplish

-10-

a

to

be

a

more

name in

the changeable

name

con-

this control are themselves

objects. How do the relations among objects come to be

real-world

the

such changes are expressed by causal laws

state how certain relations holding

objects

among

which

,

cause

conditional statement about some class of objects.

ple,

In

these

These laws are usually expressed as

relations to change in time. a

changed?

exam-

For

"an electron in conditions C will act in manner A."

The same approach can be used for controlling

relations among objects in to what

done

is

programming system.

a

object-oriented

in

classes

of

various

message-receiving

objects

languages

changing

the

This is similar like

Smalltalk:

are defined which behave in the same way in

situations.

Thus,

the

methods

of

Smalltalk can be thought of as causal laws. How

do

languages? in

these

Note

ideas

relate

applicative

to

that values enter into the universe of objects

First, certain attributes of

several places.

objects

weight)

and

values.

Second, the relations that hold

given

programming

relations

among

objects

(e.g.,

(e.g., distance)

will be

among

objects

at

any

time are themselves values, since relations are mathemati-

cal abstractions.

At each

relations

to

determine

instant of time the causal laws must

associated with the relation-names at the next

be

instant of time.

new

These changes

are

expressed

as

transactions

that add tuples to, or delete tuples from, the relations.

Appli-

cative programs can

to

be

used

to

-11-

determine

the

values

be

associated

with the value-bearing attributes of an object. Thus,

value-oriented and object-oriented programming techniques can used

together

in

a

way that exercises the advantages of each. used

Values and pure functions are relationships,

their

be

abstractions

model

to

and

objects and causal laws are used to

while

model real-world objects and their behavior.

2.

Intension versus Extension It

is

necessary to distinguish

between

intension

the

and

extension of the relations in the computer that are used to model Two

corresponding external relationships and properties. tions

have

the same intension if they are intended to model the

Two

same external relationships or properties.

the

same

extension

the same objects two

(or

(at a given point

in time)

if

have

they apply to

Notice

that

relations may be extensionally the same even though they are For example, at

given point in

a

time,

same three objects may satisfy both the relations "blue" and

"round," but this does not imply that "blue" the

relations

tuples of objects and values).

intensionally different. the

rela-

same

property.

That

is,

and

model

"round"

"blue" and "round" have the same

extension but different intensions.

Also, notice that one of the

objects might at the next instant become "non-blue" while remaining

"round." Thus, although the intension

fixed their extension can vary in time.

tions with different intension can

extension.

-12-

of

relations

remains

From time to time, rela-

coincidently

have

the

same

The same distinctions apply to objects.

The intension of

a

computer object is the real-world object it is intended to model; the extension of

which

a

computer object is the

belongs.

it

set

of

relations

to

objects with different intensions can

Thus

coincidently have the same extension. These notions of intension and extension might seem to

con-

with Liebnitz' doctrine of the identity of indiscernibles

flict

,

which says that two things that are alike in every way are ident-

Symbolically,

ical.

x

y



Buffer(k,x), Pindex (Sue

*Consume(a), *Cindex(k), *Buffer(k,x)

where Suc(x) denotes the successor of

=»

Cindex (Sue

(k

(k

)

)

)

)

,

,

a(k).

a(x).

x.

Notice that the indivisibility of rules ensures that simultaneous Produce messages will get distinct Pindexes and that simultaneous

Consume requests will get consecutive buffer elements.

-21-

.

:

6

.

Notational Extensions

.

condition-action rules described

The syntax for

In this section we make

termed the canonical form for rules.

is

previously

several notational extensions to the canonical form

simplify

to

expressing rules. Compound Rules

6. 1

Suppose we wished to write rules that perform one action P

contains

pair of the form and

a

The following to rules

contains any other pair .

accomplish

this,

since

different action

a

pair



P (x, x)

=^

Action

1

P(x,y)

=»

Action

2.

a

will

if

will

if it

not

match the pattern

P(x,y)

What we would like to say is: only

if

using

a

this

fails

first try the pattern

P(x,x)

and

This idea can be expressed by

try P(x,y).

negative condition:

P (x, x)

=»

Action

~P(x,x), P(x,y)

1

=>

Action

2.

We allow the following notational abbreviation case:

P (x

else

,

x)

P(x,y)

=3>

=»

-22-

Action Action

1

2.

for

this

common

This extends in the obvious way to more that one else-arm and

to

more than one condition in the cause parts.

6

.

Sequential Blocks

2

Often we want the mechanism of an

object.

relation, say &

a

a

*

Cx

E 1#

*S*(n,

v)

'

cn

n'

a

the

of

v)

rf(l,

,

v)

rule

allow

Q

'jrf(l,

v

represent the state

For example,

E

where

to

,

sequen-

move

to

This can be programmed expli-

tially through two or more states. citly by using

object

4{2, v)

represents all the unbound variables of Cg. only

fire

to

Q

;

C

1

The semicolons are suggestive in

form

to

written

be

as

We a

:

{S

statements

allows

the object is in the proper state.

if

group of rules of the above

sequential block

This

conventional

C

1

,

of

...

the

E

,

n>

sequential

execution

programming languages.

the variables in Cg essentially become global

of

Notice that

variables

of

the

entire block.

Sometimes rules in sequential blocks have empty cause parts, for

example

"

=» E

,

"

since the rule is to be applied uncondition-

ally when the object is in the proper state.

-23-

In these

cases

we

.

allow the arrow to be dropped:

"E."

Procedure Calls

6. 3

The communication mechanisms we have described are asynchro-

nous

that

,

Lookup (d,n return

f

is,

a)

the

message

a

request to look up name

(a

result in

such as *a(x).

sent

is

a)

and

a

by n

action

an

such

directory

in

result is received by

Any amount of processing might

a

d

and

condition

done

be

as

by

the

sender between the Lookup and the reply. In many situations the sender cannot go on; a

reply.

For example,

Lookup( Public,

=^

*R(n,a)

*Receive(s), *2(a)

n,

rule

]>

is

to

convey

a

from

the

In these cases we are doing synchro-

to the second.

nous communication.

Receive), £(a).

Pop(s,a).

=*

where we assume the only purpose of first

must wait for

it

Since synchronous communication is

com-

so

mon, we allow the above example to be written: *R(n,a)

=»

Pop

(

Lookupf Public,

n]

,

a).

The square brackets indicate that Receive is to be passed as last

argument

and

that we are to wait for

private Receive relation) before followed

by an argument list

cedure call or, more briefly,

reply

continuing.

in square a

a

call

-24-

brackets

(through the

relation

^

is

the

termed

name a

pro-

,

Next we consider

slightly more complicated example.

a

Sup-

pose that we have two nested calls; what would this mean? a( Pop[ Lookup[ Public,

*R(n,a)

n]

]

)

.

in the same way as the previous example we

If we reduce this

get

the three rules: *R(n,a)

Lookup( Public, n, Receive), 2(n,a).

==»

*Receive(s), *j>(n,a)

=»

Pop

*Receive(x), *£(n,a)

=»

a(x).

A problem is apparent:

same left-hand sides;

(

s,

the

this means that either of these rules could

which

incorrect.

is

To

proper synchronous communication these rules must be

the

more tightly bound. is

essentially

have

The last two rules

accept the result returned by Lookup,

ensure

Receive), 2(n,a).

Since

a

particular instantiation of

a

rule

uniquely determined by the rule and the bindings performed by

the cause part, we can tag each communication with this tion.

informa-

Therefore, to reduce the rule P( Pop[

*R(n,a)

to the canonical

Lookup[ Public,

n]

]

)

.

form, we must create new relations 2, P

an

Pm+l^m+l

5




-23-

p-j»

•••)

completed,

.

this

(ID rule

and the completion signals in

;

:

A-

When this algorithm has been completed we will have rules

structure

this

with

(rule

numbers

are

set of

a

shown

in

parentheses) t

Creation of parameter record and reply relations Creation of activation record Call processing

Final actions t

6. 4

(7,

(2)

(3)

8)

(10)

Destruction of activation record

(11)

Valueless Procedures The procedures described above

return

In sequential blocks

not return

{

...

;

Push

[S

•

•

Push

is

often useful to

have

the block

x]

}

in which Push

•

,

it

For example,

value.

a

R(2)

i

returning

;

they

is

valueless, can be reduced to this block:

/

(S

value-

that is, procedures that have an effect but do

procedures,

less

value

value that is used in the expression in which the call

a

occurs.

are

,x,p)

;

-29-

r

3(2)

p(y)

}

waits for an acknowledgement and

In this case *p(y)

ignores

the

returned value. 6.5

Applicative Expressions useful

It is often

expressions

(value-oriented)

able

be

to

in

applicative

evaluate

to

the effect part of rules.

example, suppose that we represent name directories tion

For

associa-

by

The rules to put names in these directories and to

lists.

look up their values can be written: *Def ine

(d

,

n, x, a)

Contents(

=»

Lookup (d,n, a) In the second

tion

,

*Contents (d,y)

,

cons

d,

Contents

(

pair(n,x), (d

,

=*>

x)

rule above assoc(n,x)

is

y) a

,

)

a(d).

(assoc

(n

,

following,

which

)

.

interpreted as an applica-

of the function assoc to the values n and x.

be reduced to the

x)

explicitly

This rule can calls

for

the

evaluation of the expression:

Lookup

(d,n, a)

Contents

,

where assoc(n,x)

is

another

a

rule

,

a(

x)

now interpreted as

constructor and Current Since

(d

is

Eval

a

fire,

simple

data

structure

the current environment.

rule must always be executed

can

assoc(n,x), Current]

[

it might

to

completion

seem that the effect of

terminating computation would be to hang the entire system. this

is

before a

non-

That

not the case can be seen by eliminating the synchronous

-30-

)

call from the above rule:

Lookup (d, n, a) =»

Eval

Contents (d,x)

,

assoc(n,x), Current,

(

*p(y), *2(d,n,a,x)

but

£(d,n,a,x).

,

a(y).

result then the second

will

never

this will not prevent other rules from firing.

Since

If Eval never returns a

fire,

=»

p)

rule

all rules involving applicative expressions ultimately reduce

to

rules in the canonical form and since rules in the canonical form are never non-terminating, we can see that execution can never be

stopped by non-terminating applicative expressions.

6

.

Applicative Conditions

6

Consider

the

following

Sched(x,t) means that an event and

a

want

predicate Clock write

to

a

(t)

to

x

problem.

happen.

A

means that the current time

as

the

relation

scheduled to happen at time

is

rule to cause some effect

time is at least as late

scheduled

simulation

time

E

t.

We

whenever the clock

which

at

is

t

an

event

is

We allow this rule to be written as fol-

lows:

*Sched(x,t), Clock(t')

if

t

'

_>

t

=»

E

In general we allow any Boolean-valued applicative expression

appear

following an "if" in the cause part of

a

rule.

To illus-

trate the reduction of these rules to canonical form we show

reduction of the scheduling example:

-31-

to

the

.

.

Sched(x,t), Clock(t')

Here

=»

Tf(t'

*Sched(x,t), Clock(t'),

* IT

*TT(false), *2(x,t,t')

=*>

> t)

(true)

,

S(x,t,t').

Notice

that

with

value of the applicative expression

t

'

>^

t

has

no

longer

returned

been

by

This is because

Sched and Clock are retested in the second rule. may

rule.

Also notice that the conditions on

Eval and is known to be true.

they

this

Sched is not updated until after the

relation

the

E.

.

and 2 are two new relations associated

II

=»

*5(x,t,t')

,

.

true by the time Eval has returned its

be

result. As an example

present

a

read

record

r

applicative

of

conditions

we

simplified form of the file system described in David

Reed's thesis [Reed73] last

use

the

of

at time

at time

t

.

Let LastRead

r

,

t)

and let Value(r,t,x)

The value of

was x.

t

(

r

mean that record

r

was

mean that the value of at any time

can

T

be

read and passed to an action A by:

Value (r,T,x)

,

LastRead

Value (r,T,x)

,

*LastRead

Updating

a

denoted

by

record

r

Update

(r

,

(r

t) ,

T

;

t)

;

to a new value (r ,T ,y)

t

y

.

effective

at

(r

,

T)

,

A (x)

time

T

This operation is only allowed

.

has not been read effective at

a

later time:

Update (r,T,y)

,

LastRead

(r

,

t)

;

T>t

Update (r,T,y)

,

LastRead

(

r

,

t)

;

T

*R(x)

It a

is

part of the definition of

square on the screen.

a

graphic object that

The similarity

to

will be apparent to readers familiar with that language.

-32-

Smalltalk

;

;

;

;

;

=» *Show( self, reply) Color[ Ascribe, black]; { D r aw s e 1 [

f

]

;

reply(self)

}

=» *Erase( self, reply) Color[ Ascribe, background]; Draw[self reply(self) } {

]

=^ *Draw( self, reply) @origin] Goto Ascribe, { Turnf Ascribe, Stilt]; DrawAux[ self, 0]; reply(self) } [

*DrawAux

self,

reply(self)

reply)

=S

*DrawAux( self, k, reply) Go Ascribe, ?size] Turn[ Ascribe, 90] DrawAuxf ?self, k+1] reply(self)

=*>

{

(

4,

else

[

}

Figure

7

.

1.

Part of

a

Graphic Object

System Structure In this section we discuss

object-oriented only possible

programming organization,

a

possible

system. it

will

organization

Although

for

an

this is not the

illustrate

many

of

the

characteristics of these systems.

Consider the problem of information hiding, that is, the

corresponding

relations invisible. the

relations

relations

For example,

and the non-corresponding

in the definition

stacks,

of

NewStack, Push, Pop and Destroy are to be visible

to all potential stack users,

visible

visible

making

while

the

only to the implementor of stacks.

relation

Contents

This is accomplished

by placing the names of the corresponding relations in

-34-

is

a

public

directory

keeping

while

Suppose that all environments contain at

the implementor.

"Private"

bindings:

two

"Contents" in the private directory of

bound to the private directory and

is

"Public" is bound to the public directory.

directories

for

returns

a

defined

least

Then, using the rules

Section 6.4 and supposing NewRel[]

in

new relation object, we can define the private relation

Contents by: Define[ Private, "Contents", NewRel[] The distinction between public and

vides

private

];

relations

pro-

gross level of discrimination between kinds of access.

a

A

finer level of discrimination is required to maintain fidelity to For example, we might have

a

class

of objects that have a publicly visible attribute Velocity.

The

causal model of objects.

the

of this attribute might be determined by non-corresponding

value

causal laws private to this class sense

for

only

With just the

have

two

choices:

public/private

the

makes

it

attribute

public,

distinction,

make the attribute private,

(1)

which case other objects can not use it make

Thus

other objects to inquire the value of this attribute,

but not to alter it. we

objects.

of

conditions,

in

or

in (2)

which case it is vulnerable to

in

actions by other objects. We solve this problem by

addressing by

a

[Dennis66]

capabil i ty

object

,

.

which is

identifier

for

a

simple form of

capability

based

We assume that each relation is denoted a

pair



in

which

id

is

the

the relation and rs is the set of access

-35-

rights permitted to possessors of

is

relation is created

a

a

capability bearing

Define[ Private, "Push", NewRel[]

defines the private name "Push" to be

a

];

new relation that can

existence of procedures RemoveR, RemoveA, RemoveD, RemoveRD, create

that

new

a

capability

that is like

except that it has certain rights removed. define as

a

be

To restrict access to relations we assume the

any way.

in

rights

all

Thus,

returned.

used

three

The

read, add and delete.

tions in rules:

When

capability.

rights correspond to the possible uses of rela-

access

possible

this

a

...

given capability

Thus,

we

if

want

to

public name "Push" with just add-rights that is the same

the private Push, we would write:

Define[ Public, "Push", RemoveRD [Push] The capability management procedures make use

];

of

relations

private to the capability manager; these rules have this form: *RemoveR (c,a) =*>

else =>

else =»

Figure

2

,

Cmap(c,r), Has(c,A), Has(c,D), *AvailCap(d)

Cmap(d,r), Has(d,A), Has(d,D), a(d) *RemoveR

(c, a)

,

Cmap(c,r), Has(c,A), *AvailCap(d)

Cmap(d,r), Has(d,A), a(d). *RemoveR (c,a)

,

Cmap(c,r), Has(c,D), *AvailCap(d)

Cmap(d,r), Has(d,D), a(d). shows

a

complete definition of stacks.

-36-

In this

defini-

;

tion

;

;

used a procedure NewRules[S] which takes

have

we

;

rules in symbolic form, S, associates

these

with

rules

activates the rules and returns the object.

object,

set of

a

new

a

The result-

ing rule object is given a private name to allow later operations (such as editing or deactivating the rules).

on it

"NewStack", NewRel [] "Push", NewRelf] ]; "Pop", NewRel [] ]; "Destroy", NewRelf] "Contents", NewRel[]

Private, Private, Private, Private, Private,

Definef Define[ Definef Definef Definef

];

]

; ]

;

Define[ Private, "Rules", NewRules[ =» *NewStack (a) *Avail(s) Contents (s ni 1) a(s). Push (s, x ,a) *Contents (s ,y =» Contents (s, cons (x, y) a(s) =£ *Pop(s,a), *Contents (s ,cons (x,y) Contents (s ,y) a(x). Destroy (s a) *Contents (s, x) => a(x). ']]; •

,

,

,

)

,

)

,

Define[ Define[ Definef Definef Figure

Public, Public, Public, Public,

,

"NewStack", RemoveRD [NewStack] "Push", RemoveRD [Push] "Pop", RemoveRD [Pop] "Destroy", RemoveRD [Destroy] ]

]

Input Commands to Define Stack Objects

2.

object-oriented

viewpoint

Since

a

is

a

typical situation in which

preferable

is

person sitting at

a

to

and takes actions in time, we consider

object.

To allow people

computer

(real objects)

from

the value-oriented

to

a

person to be an

interact with

objects

(simulated objects) we represent people by surro-

gates, called user objects.

removed

the

terminal responds to con-

ditions

in the

]

]

Interactive programming

viewpoint.

,

,

)

relations

Therefore users can be put into

either

by

and

their own actions or by the

actions of other objects acting on the users' user objects. The user object is atomic as far as the users are concerned.

At

a

lower

level

of

abstraction

-37-

(the system level)

the user

object resolves into

a

number of smaller objects representing the

display screen, the keyboard, the directories etc. In their interactions with

objects

rest

objects.

other

any

like

act

the

system

the

of

However, because these

objects act as proxies for people they have some special

finite set of rules, the system must provide

ing

with

charac-

Since the future action of users cannot be defined by

teristics. a

user

a

way of interact-

This includes methods of informing them of the

users.

allowing

relations that hold on their user objects and means for them to direct their user objects to take actions.

Both of these

can be accomplished by allowing users to enter rules or parts

of

rules. To account for the fact that users might never repeat

actions

the same conditions, the commands that users type

under

are formally considered to be part of

block.

Thus

each

command

might type at

shown a

in

Figure

an

open-ended

implicitly

is

ever-changing attribute that can be

definitions

their

thought

parameterized by an of

as

The

time.

are typical commands that

2

a

user

-

the

terminal.

All the commands in Figure

2

are

synchronous

action

must

tinue.

Parallel activities can be initiated by

be

sequential

completed

(or

calls

before the user can con-

aborted)

uncondi-

simple

tional actions, for example:

Compile( Progl, Replyl), Compile

-33-

(

Prog2, Reply2)

;

;

The user can also type actionless conditions, e.g.,

Replyl (result)

=*

pause

which causes the user task to

;

until

conditions

the

are

Complete rules are useful for recovering results from

satisfied.

parallel tasks, e.g., Define[ Private, "Binary", result];

*Replyl (result)

Since applicative expressions are allowed users

sions

also

can

6

[

fac (3)

]

.

oriented language.

object-

and

This seems to be

object-oriented

the

as

the

value-oriented languages;

existing systems

.

same

the

the value-oriented language is embedded

language;

8

actions

for the evaluation of applicative expres-

call

Thus the command language is

.

of

:

Display

8

parts

as

(e.g.,

best

in the

object-

relationship

of

seen in several

it can be

LISP and 3ackus's AST).

Formal Semantics

1

Abstract Syntax In this section we present

a

tion of condition-action rules.

formal semantics for the execu(The casual

reader is advised to

skip this section.) The formal semantics will be expressed series

of

function

definitions

-39-

that

define

a

mapping

as

a

from

transition

abstract rules into state

syntax for rules is shown in Figure

functions.

3;

abstract

The

the correspondence between

the abstract and concrete syntaxes should be obvious.

cause effect predicate predicate name^constructor

rule cause effect predicate constructor item

Figure 8.2

item name

+

constant

+

name constructor

-

constructor

+

Abstract Syntax for Rules

3.

State Space As discussed

intensionally

different IDs. change

in

in

different

2

relations

(Intension

versus

Extension)

distinguished by having

are

Since the extensions of intensional relations can

time,

a

extensional relations. shown in Figure

Section

state is considered The definition

of

a

mapping from IDs into the

state

space

is

4.

states IDs -> relations P (tuples^ relations tuples elements elements objects + values + tuples objects atomic-objects + relation-objects where ?(s) denotes the powerset of the set s.

Figure

4.

The State Space

Recall that relations are manipulated

capabil i t ies

control read, add and delete access to the underlying rela-

that tions. set

through

of

Therefore we define the set relation-objects all capabilities.

to

be

the

This set has three exhaustive but not

mutually exclusive subsets,

-40-

)

C relation-objects

ReadCaps, AddCaps, DeleteCaps

relation-objects Note that

ReadCaps

U AddCaps U DeleteCaps

capability that bears multiple rights (e.g., add

a

will be

delete)

=

a

member of several of these sets The function Cmap takes

and DeleteCaps).

(e.g,,

capability

a

and

AddCaps its

to

underlying relation ID:

relation-objects

Cmap:

IDs

->

These notions are formally defined in Figure rights rights-sets relation -objects Cmap r ReadCaps AddCaps DeleteCaps

3

.

D}

P(rights) rights-sets 2(r) {c € {c €

(

Figure

A,

{R,

{c

6

IDs R

6

A D

€ €

1(c)} 1(c)} 1(c)}

Capabilities

5.

Multiple-valued Functions

3

function

from

the

is

in

we have

tion

Notice, however, that the

In other words,

That

is,

state

the

state transition relation rather than

Although

we

will

states X states such that Cycle(s,s')

possible

transition

What this means of course is that

multiple valued.

function .

a

transition

current state the state transition function may define

is a

state

a

non-deterministic.

general

several successor states.

function

define

condition-action rules.

for

execution of rules

is

X

relation-objects relation-objects relation-objects

Our goal in this section is to

Q

5.

successor state of

-41-

s,

define is

a a

state

transi-

relation

true if and only

it will

Cycle if

s'

often be more con-

.

venient to think of Cycle

definitions.

sections

as a multiple-valued

function.

This

us to use a more familiar functional notation in our

allow

will

(s)

Unless specified otherwise, in the will

"function"

refer

sub-

single-valued

both

to

following

and

multiple-valued functions. Since we will be dealing with multiple-valued functions, will

We write D

tions.

with

tions -»

D

necessary

be

R,

=>

talk about sets of multiple-valued func-

R for

the set of all multiple-valued func-

domain D and range R.

This notation is analogous to

the set of all single-valued functions from

course

Of

to

it

D

into

R.

mathematically D =» R is just DXR, but our notation

will better emphasize the functional viewpoint.

Although we introduce additional notation as we need it, the reader

can

find

a

complete

description of the functional and

relational operators we use in [MacLennan81] and [MacLennan83

8

.

4

]

Semantics of Rules Our goal in the following sections is to define

states

Cycle:

=»

that describes the non-deterministic

state.

We

a

function

states

transition

will do this by first defining

a

from

state

to

single-valued func-

tion Rule:

that

takes

rules

rule

into

->

envs X states

multiple-valued

-42-

=»

states

functions

that

take

.

pairs

environment-state

Note that the arrows are

states.

into

right associative and less binding than the cross.

use

the

of writing the names of abstract syntactic categories

convention in lowercase

semantic

We

and the names

"rule")

(e.g.,

functions

with

the

uppercase

leading

a

of

corresponding letter

(e.g.,

"Rule")

We will define the Rule function in

effect of the cause part of true of the state and,

bound

names

it

top-down

to

is,

extend the environment by the

matching

process.

This extended

environment is then used during execution of the effect

Rule[c,e] (S,s)

where

is

c

the

and

E

e

1

=

Effectfe]

Cause[c]

=

s

5'

of

and

E'

s

E

are the cause and effect parts of the rule

extended environment.

Note that function application is

assumed to be left associative; thus Fxy means We first address the effect part of little simpler. Effect:

executed

a

(?x)y.

rule because it

is

a

The type of Effect is:

effect

The effect part of are

part

The definition of Rule is:

the rule.

where

The

order.

rule is to test for the cause being

a

pattern

the

in

if

a

a

envs

->

states

rule is composed of

in order

in

a

states

series of actions that

the given environment.

Thus the state

transition function defined by the effect is just the composition of

the

state

transition

functions

-43-

defined by its constituent

:

actions

Effect^,

A2

,

(Action[A n

...

/

E)

'

]

An

E

]

...

(Action[A 2

*

]

(Act ion [A-J E)

*

E)

additions

There are two kinds of actions:

and

deletions.

The type of their semantic function is

predicate

Action:

To process an addition, nc,

structor part is

envs

->

whose name part is

we must evaluate

c,

c

states

=»

states

->

n

and whose

current environment

in the

and add it to the relation that results from looking up

current environment.

is

s

function

U {Constructor

the current state, and

the

in

Cmap

[c] E}

capability

the

is

the current environment.

is

E

n

The updated relation is

[s*Cmap*E]n

where

con-

mapping

This new relation

must replace the old value associated with the relation ID in the We use [x:y]/f to mean

state.

mapped to

y.

(

function like

f

except that

x

is

Therefore the new state is defined by

Action [nc] Es [

a

=

[AddCaps -»Cmap] (En)

)

:

([s*Cmap*S]n

U {Constructor

[c] E })] /

Here AddCaps -> Cmap is the capability mapping function

with

domain

means the

function

restricted f

to

add-capabi li ties

,

with its domain restricted to s.

do not add to

a

since

s -» f

its

This ensures that we

relation unless we have an add capability for it.

-44-

]

The semantics for deletions is analogous:

Action [-nc] Es [

(

=

[DeleteCaps -» Cmapl (En)

([s*Cmap*E]n

:

)

{Constructor

-

[c] E} )]

The formal semantics for constructors is straight-forward:

constructor

Constructor:

Constructor

[

...

iterr^



I

tern

[

i

tern

]

E>

constant

=

E

envs

item n ]E

item

Item:

->

Constructor [constructor

=

]

Next we address the cause part of rules.

type

The

of

the

semantic function for causes is: cause

Cause:

states

->

As expected, cause parts leave

porarily)

modify

the

The semantics of

just the composition of the semantics of its

tions

envs

unchanged

state

environment.

the

=»

envs

-»

but a

constituent

(tem-

cause is

condi-

:

Cause[C-,, C 2

,

...

(Cond[C n ]s)*

,

C

...

]

s •

(Cond[C 2 ]s)

*

(Cond[C 1

]

s)

The semantics of conditions is defined by the function Cond: Cond:

condition

->

states

-45-

-»

envs

=3>

envs

/s

E

First

address

we

where

Cond[nc]sE,

semantics

the

the name of

is

n

constructor

match:

a

relations

->

conditions,

relation and

a

To accomplish this we define

structor.

positive

of

c

is

a

function envs

-»

^>

envs

that will determine if the pattern c occurs in the relation

meaning of

is the

n

the current environment and state.

in

Cond[nc]sE where (ReadRel

s

the environment

E E

match

=

(ReadRel

s

that Thus,

n)E

E

relation whose name is

(readable)

is a

n)

[c]

con-

n

in

and the state s:

ReadRel

s

=

E

s

*

[ReadCaps -» Cmap]

*

Next consider match[c]RE; this must determine if the pattern c

occurs in the relation R and,

that is an extension of

pattern

matching

E

return an environment

it does,

if

that includes the bindings made by

process.

Now,

suppose we have

a

the

function Fin-

dEnvs:

FindEnvs: such that FindEnvs

result

[c]

relations

RE returns all

matching

from

-»

c

in R.

envs

P(envs)

-»

extensions

of

that

S

We want match to be

a

can

multiple-

valued function that can return any one of these extensions of

E.

Therefore, define match where

€ (x)

is

=

€

any set containing

""FindEnvs x

-46-

so

6

(S)

is

a

multiple-

valued function that returns any element of the set S.

Consider the function Constructor

constructor

c

(Constructor

[c]

Therefore

against

(Constructor

tuple and yields

a

match to succeed.

to yield a

E

[c]

evaluation

the

matches the pattern

)

environment

any

the

Therefore

tuple t.

environment in which

is any

t

)

of c yields t. c

environment

in the

evaluates

this

[c] E;

allows

that

the

Its type is

(Constructor

[c]

tuples

:

)

=»

envs

If unimg[f]x represents the set of all y such

unimg (Constructor [

[c]

]t

)

that

f(x,y)

then

the set of all such environments

is

and its type is

unimg

[

(Constructor

Now suppose that we have

such that minext E

that are in S.

[6 is any c

E

-1

t.

->

*

P(envs)

(defined later)

?(envs)

? (envs)

the set of all the minimum extensions

It

is

then easy to see that

S)

Now,

unimg

*

if

(minext

E)

f

(Constructor

~ [c]

)

1

of

]]t

that results from matching

E

pattern

img[f]S is the set of all y such that

for some x € S we have f(x,y),

img[6

=^

is

minimum extension to

against tuple

tuples

]:

S

(minext

'

)

function

a

envs

minext:

"

[c]

then it is easy to see that

*

unimg

-47-

[

(Const ructor

[c]

)

]]R

extensions to

is the set of all

against

any

E

that can result from matching c

Simplifying this expression we get our

tuple in R.

definition for FindEnvs: =

FindEnvs [c]RE

(minext

[

E)

img

*

minimum extensions of

of all supersets

is

[c]

"

]]R

)

containing

Observe that unimg[£]E

E.

(extensions) of E.

S

(Constructor

the subset of S

It remains to define minext E S,

the

[

is

the set

Therefore

unimg[5J]E

fl

We

the subset of S containing just extensions to E.

want

to

the minimum elements of this set, which is just the initial

find

members of the subset relation restricted to this set: minext

E

init[

S

S

T

unimg[fi]E)

(S

]

This completes the definition of positive conditions. The semantics of negative conditions is simpler tive conditions.

First define

Cond[-nc]sE

=

nomatch

[c]

(ReadRel

Negative conditions are simpler because environment.

E

=

R.

Recall that FindEnvs

such that c matches gi

then

they

s

E

n)E

don't

update

the

Therefore, nomatch[c]R is just an identity function

restricted to those environments in which in

posi-

than

a

[c]

c

doesn't match

tuple

a

RE is the set of all extensions to

tuple in R.

Therefore, if

there are no such environments;

-48-

in

FindEnvs

other words

c

[c]

RE

does

Thus, the set of all environments

not match any tuples in R.

which

doesn't

c

match

empty set under FindEnvs

in

tuple in R is the inverse image of the

a

By using this set to restrict

[c] R.

the

domain of the identity function we get the definition of nomatch:

nomatch[c]R

(FindEnvs

[unimg

=

[c] R)

-1

-» Id

tf]

where Id is the identity function.

8

.

5

Semantics of Execution We have now described the semantics of an

individual

rule;

it remains to define the state transition semantics of the entire

system.

Recall that

6

evaluated

rule has to be

Therefore

environment. p

a

postulate

we

means that

IDs such that sp(i,r,E)

the i

that must be evaluated in environment E. Ids

sp:

Next we define

state

s

Trans

IDs i

Thus Trans(i) To

function Trans

a

by rule object

Trans:

-» =

s

is

complete

multiple-valued

-»

is

the

in

existence the ID of

proper of an ID

a

rule

Hence,

rule X en vs

i

s,

which means

a

transition

of

i:

states

=»

states

where

Rule[r] (E,s)

(r,E)

=

spi

the state transition function for rule object

the

r

state

function

transition

Cycle

that follows immediately from s.

semantics

such that Cycle

Thus,

-49-

(s)

we is

need

i.

a

any state

.

states

Cycle:

We want Cycle(s,s') that Trans

[

i]

(s,s

*)

to be true .

all

these

of

there is any rule object

i

such

Now, Rng Trans is the range of Trans,

i.e.,

Therefore U (Rng Trans)

com-

the set of all Trans[i]

bines

if

states

=»

for any

i.

transition functions into one.

individual

Cycle can now be defined: Cycle

U (Rng Trans)

=

Notice that Cycle (s,s') means that state s'

Notice however

transitions.

non-terminating

often

object-oriented

that

non-deterministic,

and

denotational semantics can not take the form of Rather,

function.

oriented system

is

ble future states.

Cycle;

state

s'

Cycle state

then

so

semantics

denotational

therefore a

that

single-valued

for

possi-

Defining this relation is our next task.

Cycle

(s,s')

means

CanReach

(s

s ,

'

)

that state

s

rela-

can lead to

Thus we define CanReach

transitions. means

that state

s

=

can lead to

'

since CanReach

(s ,s

'

)

is true

mediate states that will get us from to

object-

an

The definition of CanReach is too permissive for

poses

are

their

relation that relates past states to

a

in zero or more

*

s

a

systems

be the reflexive transitive closure of the

Let Cycle

tion

can lead to state

transition; we would like to extend this to repeated

one

in

s

know if

a

if s

pur-

there is any set of interto s

1

.

Sometimes we

state can lead to another state that is

-50-

many

a

want

dead end,

]

We can express this idea as fol-

that we can't get out of.

i.e.,

lows.

Let

returns

a

const

represent

(J.)

distinguished value,

constant function that always

a

Then extend Cycle to

J_.

total

a

function Cycle / const [Cycle/const

so that

(J_)

]

s

is

if

J_

that this total function is

also

(_|_)

Cycle(s) J_

Notice

undefined.

is

preserving.

Now consider the

relation

Reaches If Reaches (s

can't that

9

.

,_)_)

then we know that

get out of. s

[Cycle / const

If this

s

can lead to an state that

not true,

is

(1)

then Reaches

(s

,

s

'

)

we

means

can safely reach s'.

Summary Several similarities will have been

work

previous work. For example, in [Lomet76]

and

David Lomet describes that

is

observed

a

distinction between

very similar to ours.

values

However,

notion of an object is

we

more

and and

this

[Lomet80]

objects

We recommend these papers to the

reader as an interesting alternate approach to

distinction.

between

believe

that

fundamental

our

than

the

value/object

simulation based Lomet's

storage

based idea. As has been noted,

on

a

finite

universe

the idea of of

objects

-51-

a

set of alterable is

relations

similar to the knowledge

representation networks used in artificial intelligence

applica-

tions and the set of causal laws has similarities to both produc-

PROLOG

tion systems

and

between

work and these systems is that our notion of

our

programs.

fundamental

A

duction does not require any backtracking. of

no

difference a

Furthermore, we

pro-

know

attempt to make these ideas the basis of an entire

other

programming system. This paper extends previous work in several it clarifies

the nature, purpose,

programming languages.

in

tive languages.

objects

and roles of values and objects

Second,

argues

it

objects

that

programming devices and should be included

important

can

Finally,

be

it

proposes

accommodated.

First,

areas.

This

a

in

are

applica-

specific

form

includes

the distinction

which

in

between corresponding and

non-corresponding

tions,

name contexts and capabilities to hide

and

the

use

of

non-corresponding objects and

relations.

objects

Finally,

rela-

and

it

proposes

that the manipulation of objects be specified by causal laws that

determine sets of transactions to alter the state. how

these

It

shown

is

concepts may be combined with applicative programming

ideas.

10

.

Acknowledgement Research leading to and the preparation of this

supported

by

was

the Office of Naval Research under contract number

N00014-82-WR-20162 and the Foundation Naval

report

Postgraduate

School

with

-52-

Research

Program

of

the

funds provided by the Chief of

Naval Research.

11

.

References Dahl, O.-J., Myhrhaug, 3. and Nygaard, K.

[Dahl70]

Common Base Definition

The SIMULA 67

,

Publication S-22, Norwegian Computing

,

Centre, Oslo, 1970. Dennis, Jack B. and Van

[Dennis66]

C,

9_,

(March

3

Microelectronics and the personal computer,

Scientific American 237 [Lomet76]

Programming

pp 143-155.

,

Kay, Alan

[Kay77]

C,

Earl

for multiprogrammed computations, CACM

semantics 1966)

Horn,

,

3

(September 1977), pp 230-244.

Lomet, David B., Objects and values:

the

basis

of

storage

model for procedural languages, IBM Journal Res

Dev

2

.

[Lomet80]

20.'

,

a

and

(March 1976), pp 157-157.

Lomet, David 3.

A data

definition facility based on

value-oriented storage model, IBM Journal Res

.

and Dev

.

24

a

,

6

(November 1980), pp 754-782.

[MacLennan73]

MacLennan, B. J., Fen

gram semantics, CACM 16

,

8

-

an axiomatic basis for pro-

(August 1973), pp 468-471.

[MacLennan75] MacLennan, 3. J., Semantic and Syntactic Specification

and

Extension

of

Languages

University, 1975.

-53-

,

PhD Dissertation, Purdue

[MacLennan81

MacLennan,

]

gramming, Arch

.

,

Proc

Conf

ACM

.

Introduction to

J.,

B.

Functional Prog

.

relational .

pro-

Lang , and Comp .

October 13-22, 1981.

[MacLennan82] MacLennan, 3. J., Values and objects in programming

languages, SIGPLAN Notices 17

12

,

(December 1982)

[MacLennan83] MacLennan, 3. J., Overview of

Notices

SIGPLAN

ming,

Postgraduate School Report NPS52-81-017 [Maisel72]

18

to

,

Computer

appear

Science

[Pritsker79]

,

SRA,

Pritsker, A. Alan

see also Naval

(1983),

Department

Simulation

Computer

Technical

Discrete

of

Pegden,

and

3.

,

Claude

Svstem,

Dennis,

John Wiley, 1979.

Reed, David P., Naming and Synchronization in

tralized

program-

relational

1972.

Introduction to Simulation and SLAM [Reed73]

pp 70-79.

(November 1981).

Maisel, H. and Gnugnoli, G.,

Stochastic Systems

,

PhD

Decen-

a_

Dissertation,

1973,

MIT/LCS/TR-205. [Rentsch82]

Rentsch, Tim, Object

Notices 17 [Robson81] 6,

8

,

9

oriented

programming,

SIGPLAN

(September 1982), pp 51-57.

Robson, David, Object-oriented software systems,

(August 1981), pp 74-86.

-54-

BYTE

INITIAL DISTRIBUTION LIST

Defense Technical Information Center Cameron Station Alexandria, VA 22314

2

Dudley Knox Library Code 0142 Naval Postgraduate School Monterey, CA 93940

2

Office of Research Administration Code 012A Naval Postgraduate School Monterey, CA 93940

1

Chairman, Code 52Hq Department of Computer Science Naval Postgraduate School Monterey, CA 93940

40

Professor Bruce J. MacLennan, Code 52M1 Department of Computer Science Naval Postgraduate School Monterey, CA 93940

12

Robert Grafton Code 433 Office of Naval Research 800 N. Quincy Arlington, VA 22217 Dr.

Dr. David W. Mizell Office of Naval Research 1030 East Green Street

1

1

Pasadena, CA 91106

John M. Hosack. Department of Mathematics Colby College Waterville, ME 04901 Dr. David B. Lomet

1

1

IBM Thomas J. Watson Research Center P.O. Box 218 Yorktown Heights, NY 10598

Jim Bowery Viewdata Corporation 3rd Floor 1111 Lincoln Road Miami Beach, FL 33139

1

J.

Craig Cleaveland

1F35

Bell Laboratories 1600 Osgood Street North Andover, MA 01845

Professor John M. Wozencraft, 62Wz Department of Electrical Engineering Naval Postgraduate School Monterey, CA 93940

Mark Himmelstein 1323 Tulip Way Livermore, CA 94550

1^205 B 37

DUDLEY KNOX LIBRARY

-

RESEARCH REPORTS

fllill

5

6853 01069635 4