Mutable

Object

State

for

Object-Oriented

Logic

Programming

A

Survey

Technical

Report

TR

Vladimir

Alexievy

Department

of

Computing

Science

University

of

Alberta

GSB

Edmonton

Alberta

email

vladimir@cs.ualberta.ca

August

Abstract

One

of

the

most

difficult

problems

on

the

way

to

an

integration

of

Object-Oriented

and

Logic

Programming

is

the

modeling

of

changeable

object

state

-LRB-

i.e.

object

dynamics

-RRB-

in

a

particular

logic

in

order

not

to

forfeit

the

declarative

nature

of

LP

Classical

logic

is

largely

unsuitable

for

such

a

task

because

it

adopts

a

general

-LRB-

both

temporally

and

spatially

-RRB-

Platonic

notion

of

validity

whereas

object

state

changes

over

time

and

is

local

to

an

object

This

paper

presents

the

problem

and

surveys

the

state-of-the-art

approaches

to

its

solution

as

well

as

some

emerging

promising

new

approaches

The

paper

tries

to

relate

the

different

approaches

to

evaluate

their

merits

and

deficiencies

and

to

identify

promising

directions

for

development

The

Problem

Dynamics

of

Objects

From

the

research

literature

on

integration

of

Object-Oriented

Programming

-LRB-

OOP

-RRB-

and

Logic

Programming

-LRB-

LP

-RRB-

one

gets

the

impression

that

the

most

obstinate

difficulty

on

the

way

to

such

an

integration

is

the

following

problem

how

to

represent

-LRB-

model

adequately

-RRB-

state

change

in

a

declarative

and

logically

sound

way

On

the

other

hand

the

structural

aspects

of

OOP

-LRB-

encapsulation

classes

inheritance

polymorphism

and

aggregation

-RRB-

can

be

accommodated

in

the

LP

paradigm

with

relative

ease

Representation

of

state

-LRB-

object

dynamics

-RRB-

and

representation

of

structurisation

-LRB-

object

statics

-RRB-

are

largely

orthogonal

but

in

some

cases

they

interfere

with

each

other

So

notwithstanding

that

the

emphasis

of

this

paper

is

on

mutable

state

-LRB-

for

a

general

survey

of

OOLP

see

the

one

by

Davison

-LSB-

-RSB-

-RRB-

in

some

cases

I

discuss

static

aspects

as

well

Classical

logic

emerged

from

studies

in

the

foundations

of

mathematics

and

thus

it

is

designed

to

reason

about

static

things

relations

functions

etc.

Correspondingly

predicate

calculus

adopts

a

notion

of

truth

which

is

Available

by

anonymous

FTP

from

ftp.cs.ualberta.ca

Z

or

pub

oolog/state.ps

Z.

Comments

and

corrections

are

most

welcome

ySupported

by

a

University

of

Alberta

PhD

Scholarship

ffl

Global

all

the

consequences

of

a

logic

theory

are

-LRB-

conceptually

-RRB-

known

to

hold

-LRB-

this

is

named

logical

omniscience

-RRB-

ffl

Eternal

-LRB-

universal

in

time

-RRB-

a

formula

is

either

true

or

false

independent

on

the

time

it

is

evaluated

Furthermore

the

same

holds

for

terms

-LRB-

data

items

-RRB-

a

logic

variable

-LRB-

as

e.g.

in

Prolog

-RRB-

once

bound

can

not

take

on

another

value

-LRB-

except

on

backtracking

-RRB-

The

property

that

a

formula

or

a

part

of

it

always

has

the

same

meaning

no

matter

where

and

when

it

is

evaluated

is

called

referential

transparency

To

the

opposite

object

encapsulation

and

the

dynamics

of

objects

make

object

state

ffl

Local

the

state

of

an

object

is

its

private

property

and

no

other

object

have

access

to

it

except

by

asking

the

owner

using

message

passing

ffl

Time-dependent

in

a

system

which

should

be

able

to

model

the

dynamic

world

object

state

changes

over

time

This

renders

classical

logic

unsuitable

for

state

change

representation

There

are

a

number

of

proposals

for

a

logic

of

action

and

change

but

of

them

has

ever

become

the

core

of

a

database

or

a

logic

programming

system

On

the

other

hand

classical

predicate

calculus

is

the

foundation

of

queries

in

Relational

and

Deductive

Databases

and

of

Logic

Programming

both

in

theory

and

in

practice

In

addition

to

this

general

unsuitability

of

classical

logic

for

the

modeling

of

dynamic

systems

there

is

a

number

of

other

side

problems

with

the

representation

of

change

in

LP

which

are

better

understood

in

the

context

of

the

respective

approaches

they

appear

in

and

are

covered

in

the

respective

sections

below

The

following

problem

however

is

sufficiently

general

to

be

mentioned

here

object-orientation

is

often

used

to

implement

open

highly

interactive

systems

which

do

some

input

-LRB-

perception

-RRB-

then

some

computation

then

some

output

-LRB-

actuation

-RRB-

and

so

on

in

a

loop

Therefore

those

are

reactive

systems

Even

if

not

open

to

the

external

world

a

large

object-oriented

system

consists

of

a

large

number

of

component

objects

and

their

interactions

Examples

of

such

systems

are

user

interfaces

operating

systems

simulations

communication

software

industrial

control

and

robotics

applications

etc.

To

the

contrary

LP-based

programs

are

transformational

in

the

sense

that

they

get

some

inputs

and

produce

-LRB-

a

set

of

-RRB-

corresponding

outputs

which

make

a

certain

I/O

relation

true

-LRB-

one

of

the

strengths

of

LP

is

that

one

can

flexibly

apply

inputs

the

program

is

like

a

black

box

with

bidirectional

pins

which

can

serve

as

both

inputs

and

outputs

according

to

demand

-RRB-

A

complex

object

has

a

correspondingly

large

state

information

an

object

in

an

OOLP

program

should

store

a

number

of

its

previous

states

for

backtracking

purposes

It

is

a

very

subtle

matter

to

determine

the

exact

amount

of

backtracking

information

-LRB-

state

history

-RRB-

to

be

stored

between

message

sends

For

example

Conery

in

-LSB-

p.

-RSB-

writes

Is

there

an

operation

analogous

to

cut

that

commits

the

system

to

a

new

object

state

and

allows

us

to

discard

the

history

of

some

objects

How

will

this

interact

with

the

top-level

user

dialog

The

question

is

even

more

complex

if

there

are

more

stimulus

sources

than

a

single

user

A

sample

proposal

for

the

solution

of

this

problem

which

I

deem

impractical

is

as

follows

-LSB-

-RSB-

upon

a

message

send

a

logical

deduction

process

is

initiated

during

the

course

of

which

every

object

computes

its

new

state

but

does

not

commit

updates

and

responds

to

queries

with

its

old

state

After

that

a

special

notification

is

broadcasted

globally

and

all

objects

move

to

their

new

computed

states

In

other

words

during

the

deduction

process

the

database

is

frozen

and

moves

to

a

new

state

synchronously

all

at

once

This

convention

greatly

simplifies

the

logical

semantics

but

contradicts

the

very

spirit

of

a

distributed

system

of

autonomous

objects

and

introduces

an

unneeded

distinction

between

deduction

and

update

also

it

is

not

clear

what

entity

the

programmer

should

authorize

to

broadcast

the

global

move

to

the

new

state

message

and

how

this

message

will

reach

all

its

recipients

The

survey

attempts

to

explicate

the

relations

-LRB-

sometimes

even

unintentional

-RRB-

which

exist

among

the

different

proposals

The

emphasis

in

this

survey

is

on

efficient

implementation

of

state

change

one

which

would

be

suitable

for

the

lowest

fundamental

level

of

a

general

OOLP

language

The

following

approaches

are

covered

in

the

sections

below

Assert/Retract

Declarative

Database

Updates

and

Transaction

Logic

Modal

and

Dynamic

Logics

Perpetual

Objects

Logical

Objects

and

Linear

Objects

Linear

Logic

Rewriting

Logic

and

MaudeLog

Assert/Retract

Non-Logical

State

Change

This

section

discusses

a

cover

under

the

carpet

approach

to

our

problem

namely

the

approach

of

not

addressing

the

problem

at

all

This

approach

is

rather

wide-spread

in

early

integration

proposals

like

the

one

by

Zaniolo

-LSB-

-RSB-

and

in

proposals

which

treat

objects

as

encapsulated

labeled

collections

of

clauses

-LRB-

local

theories

-RRB-

like

McCabe

's

L&O

-LSB-

-RSB-

-LRB-

class

templates

-RRB-

or

Ishikawa

and

Tokoro

's

-LSB-

-RSB-

-LRB-

an

object-based

OOLP

language

-RRB-

In

the

last

two

languages

mentioned

an

assignment

operator

is

introduced

for

convenience

and

efficiency

but

the

logical

semantics

is

the

same

as

for

assert/retract

Bancilhon

in

-LSB-

p.

-RSB-

talks

about

clean

queries

and

dirty

updates

and

argues

that

since

all

known

systems

which

have

a

clear

-LRB-

fix-point

-RRB-

semantics

do

have

a

semantics

only

for

queries

but

not

for

updates

we

should

accept

this

as

a

matter

of

fact

and

treat

updates

as

destructive

assignments

Many

of

these

approaches

are

based

on

the

destructive

modification

of

the

logic

program

through

the

assert

and

retract

operators

of

Prolog

which

insert

and

delete

a

clause

from

the

program

respectively

There

are

many

problems

with

assert/retract

which

motivate

e.g.

Warren

-LSB-

-RSB-

to

talk

about

The

evils

of

assert

and

which

make

programming

using

these

operators

a

rather

non-declarative

effort

ffl

They

depend

on

the

sequential

execution

of

the

literals

in

a

goal

-LRB-

which

is

peculiar

to

Prolog

-RRB-

thus

they

do

not

respect

the

commutativity

of

logical

conjunction

ffl

Theory

change

involves

higher-order

notions

which

however

with

assert/retract

remain

hidden

and

implicit

Metalanguage

-LRB-

in

which

Prolog

programs

are

written

-RRB-

and

object-level

language

-LRB-

in

which

Prolog

talks

about

real-world

objects

-RRB-

are

mixed

in

a

non-disciplined

way

Since

no

distinction

is

made

between

the

name

of

a

formula

-LRB-

the

argument

of

assert/retract

-RRB-

and

the

formula

itself

this

leads

to

strange

effects

such

as

assert

-LRB-

p

-LRB-

X

-RRB-

-RRB-

means

Assert

that

for

all

X

p

-LRB-

X

-RRB-

holds

-LRB-

a

universally

quantified

assertion

-RRB-

whereas

p

-LRB-

X

-RRB-

means

Does

there

exist

an

X

such

that

p

-LRB-

X

-RRB-

holds

-LRB-

an

existentially

quantified

query

-RRB-

ffl

assert

and

retract

do

not

undo

their

effects

on

backtracking

leaving

an

unwanted

residue

in

the

database

This

makes

it

hard

to

use

them

for

transaction

programming

where

the

changes

should

only

be

committed

in

the

case

when

the

transaction

succeeds

There

are

Prologs

featuring

fully

backtrackable

assert/retract

e.g.

Object-Prolog

-LSB-

-RSB-

In

SicstusProlog

one

can

implement

backtrackable

assert/retract

using

a

builtin

meta-predicate

whose

term

argument

is

executed

on

backtracking

For

example

backtrackable

retract

will

be

-LRB-

X

-RRB-

retract

-LRB-

X

-RRB-

undo

-LRB-

assert

-LRB-

X

-RRB-

-RRB-

Another

problem

-LRB-

which

however

is

not

inherent

to

assert/retract

-RRB-

is

that

changes

are

done

globally

to

the

database

and

are

not

encapsulated

in

a

local

part

pertaining

to

a

single

object

Although

this

approach

is

completely

unsatisfactory

there

are

surprisingly

many

commercial

OOLP

systems

which

adopt

it

This

can

be

seen

as

a

challenge

to

the

academia

to

provide

better

techniques

for

modeling

object

state

For

example

the

vendors

of

BIM-Prolog

say

something

to

the

effect

that

-LSB-

-RSB-

We

could

not

use

ineffective

approaches

based

on

maintaining

complete

histories

of

object

states

and

we

just

could

not

wait

for

something

better

to

develop

Declarative

Database

Updates

Transaction

Logic

One

of

the

fundamental

problems

in

the

area

of

Deductive

Databases

is

how

to

incorporate

new

knowledge

in

the

database

preserving

the

consistency

of

the

updated

database

-LRB-

declarative

database

updates

-RRB-

The

issue

of

dynamic

DB

updates

becomes

even

more

important

with

the

development

of

Deductive

and

Object-Oriented

Databases

because

of

the

inherent

dynamic

nature

of

objects

A

lot

of

research

has

been

performed

in

this

area

and

one

would

expect

that

most

of

this

research

should

be

relevant

to

our

problem

However

there

are

two

potential

misunderstandings

which

render

most

of

the

research

inapplicable

to

our

case

ffl

There

is

a

difference

between

updating

a

declarative

-LRB-

deductive

-RRB-

database

and

updating

a

conventional

or

object-oriented

database

in

a

declarative

way

The

former

is

relevant

in

the

area

of

Deductive

Databases

and

it

is

the

harder

problem

of

the

two

because

it

may

involve

updating

general

logic

theories

and

therefore

the

whole

suite

of

non-monotonic

problems

etc.

The

latter

is

more

relevant

to

conventional

OOP

and

to

mergers

of

OOP

and

LP

because

usually

object

attributes

-LRB-

the

dynamic

parts

of

an

object

-RRB-

are

simple

data

terms

and/or

atomic

formulae

So

the

majority

of

the

work

in

DB

updates

is

too

general

to

be

applicable

to

OOLP

one

would

not

like

to

deal

with

non-monotonicity

issues

for

a

simple

change

of

an

attribute

which

should

be

done

very

efficiently

ffl

There

is

a

big

difference

between

updating

a

database

and

revising

it

-LSB-

-RSB-

The

former

means

changing

the

database

in

order

to

reflect

a

change

in

the

real

world

the

latter

means

pointed

to

me

by

Bernhard

Pfahringer

incorporating

newly

acquired

knowledge

about

a

static

world

The

difference

is

that

revision

involves

reassessment

of

the

possibility

of

each

of

the

models

of

the

old

theory

because

some

of

them

may

turn

out

to

be

impossible

in

the

light

of

the

new

knowledge

whereas

update

can

never

change

the

set

of

possible

worlds

of

the

old

theory

it

merely

moves

the

system

to

a

new

set

of

possible

worlds

For

example

an

inconsistent

theory

can

never

be

made

consistent

using

update

-LSB-

-RSB-

which

is

not

the

case

if

revision

is

used

Technically

this

involves

a

revision

of

the

Alchourron-Gardenfors-Makinson

-LRB-

AGM

-RRB-

rationality

postulates

for

update

operators

Informally

it

means

that

the

non-monotonicity

issues

involved

are

quite

different

for

revision

and

for

update

generally

being

simpler

for

update

-RRB-

Although

many

of

the

works

are

declared

to

be

devoted

to

database

updates

in

fact

most

of

them

actually

deal

with

revision

With

this

precautions

in

mind

I

turn

now

to

a

brief

review

of

the

declarative

updates

field

Typical

approaches

which

I

deem

impractical

for

the

problem

in

hand

include

allowing

only

additions

but

not

deletions

with

newer

knowledge

overruling

inconsistent

older

knowledge

-LSB-

-RSB-

maintaining

a

complete

history

of

the

database

as

in

the

object-oriented

version

of

Kowalski

's

Event

Calculus

-LSB-

-RSB-

developed

by

Kesim

and

Sergot

-LSB-

-RSB-

etc.

Two

simple

concepts

predominate

in

the

work

in

this

field

One

is

the

application

of

modal

logic

and

the

possible

worlds

semantics

changing

a

logical

theory

leads

to

a

new

-LRB-

set

of

-RRB-

model

-LRB-

s

-RRB-

for

the

changed

theory

Another

is

the

concept

of

closeness

the

changed

database

should

maximally

resemble

the

old

one

involving

minimal

change

Two

variations

are

possible

here

closeness

can

be

interpreted

in

either

a

syntactic

-LRB-

minimal

change

of

the

set

of

formulae

-RRB-

or

a

semantic

sense

-LRB-

minimal

change

of

the

set

of

possible

worlds

-RRB-

The

work

of

Winslett

-LSB-

-RSB-

is

foundational

in

the

sense

that

she

first

gave

a

generally

accepted

formalization

of

the

notion

of

minimal

change

Fagin

Ullman

Vardi

and

Kuper

-LSB-

-RSB-

has

done

some

early

work

on

updating

databases

with

integrity

constraints

and

the

related

problem

of

view

updates

given

a

-LRB-

possibly

non-injective

-RRB-

mapping

of

the

database

state

-LRB-

a

view

-RRB-

map

an

update

of

this

view

back

to

an

update

of

the

basic

stored

facts

An

elementary

-LRB-

under

a

particular

definition

-RRB-

update

of

a

view

may

turn

to

be

non-elementary

for

the

stored

database

Usually

a

number

of

views

will

be

needed

to

disambiguate

how

to

perform

a

basic

update

Abiteboul

and

Vianu

-LSB-

-RSB-

developed

a

number

of

declarative

languages

for

database

updates

and

obtained

some

results

on

expressiveness

and

complexity

but

they

were

only

concerned

with

the

end

result

of

executing

an

update

and

not

with

the

execution

process

itself

There

are

syntactic

restrictions

on

the

ways

transactions

can

be

constructed

from

simpler

ones

and

no

transaction

subroutines

are

allowed

Chen

-LSB-

-RSB-

developed

a

calculus

and

an

equivalent

algebra

for

specifying

and

executing

updates

-LRB-

restricted

to

insertion

and

deletion

of

single

tuples

-RRB-

much

in

the

tradition

established

for

exploration

of

query

languages

A

work

which

stands

out

with

its

very

different

approach

to

the

problem

is

Transaction

Logic

-LRB-

T

R

-RRB-

of

Bonner

and

Kifer

-LSB-

-RSB-

They

opt

not

to

deal

with

the

whole

spectrum

of

non-monotonicity

issues

related

to

database

updates

and

assume

that

a

transition

base

of

elementary

updates

specifying

the

set

of

possible

transitions

for

each

update

is

given

beforehand

-LRB-

usually

through

an

algorithm

which

can

enumerate

it

-RRB-

In

this

way

T

R

manages

to

be

both

very

general

-LRB-

different

models

of

updates

can

be

accommodated

in

it

-RRB-

modular

-LRB-

a

particular

model

of

updates

can

easily

be

plugged

The

paper

is

far

from

comprehensive

in

this

respect

For

more

comprehensive

surveys

see

-LSB-

-RSB-

or

-LSB-

-RSB-

in

-RRB-

and

at

the

same

time

have

a

sound

semantics

-LRB-

all

the

difficult

non-monotonicity

issues

are

encapsulated

in

the

transition

base

and

do

not

spoil

the

rest

of

the

semantics

-RRB-

The

formulae

of

T

R

are

database

transactions

built

up

from

elementary

updates

which

may

succeed

or

fail

and

T

R

focuses

on

their

compositional

properties

T

R

interprets

all

the

classical

logic

connectives

in

terms

of

composition

of

transactions

-LRB-

e.g.

conjunction

constrains

two

transactions

so

that

they

both

should

run

along

the

same

execution

path

disjunction

corresponds

to

non-deterministic

choice

etc.

-RRB-

and

in

addition

introduces

serial

conjunction

denoted

which

composes

two

transactions

sequentially

and

its

dual

-LRB-

under

the

de

Morgan

laws

-RRB-

serial

disjunction

denoted

Also

left

and

right

serial

implications

are

defined

-LRB-

OE

def

OE

OE

-RRB-

def

OE

which

mean

Whenever

OE

happens

it

must

be

immediately

preceded

-LRB-

resp

followed

-RRB-

by

In

T

R

the

difference

between

a

transaction

and

a

query

is

blurred

because

a

successful

transaction

may

both

do

some

changes

to

the

database

and

bind

some

logic

variables

thus

returning

an

answer

This

is

corresponds

well

to

the

practice

in

LP

and

is

important

for

modeling

methods

in

OOP

where

a

method

can

both

return

a

value

and

have

side

effects

Also

both

hypothetical

reasoning

and

committed

transactions

are

possible

in

T

R

Other

features

which

are

important

for

database

programming

like

non-deterministic

and

bulk

updates

non-deterministic

sampling

static

and

dynamic

integrity

constraints

on

transaction

execution

etc.

are

also

provided

for

A

major

advantage

of

-LSB-

-RSB-

is

that

it

develops

a

sound

and

complete

proof

theory

of

the

Horn

fragment

of

T

R

which

is

suitable

for

Logic

Programming

It

turned

out

that

it

is

awkward

to

formulate

the

proof

theory

of

full

T

R

in

T

R

itself

so

a

general

logic

of

state

change

-LSB-

-RSB-

is

being

designed

for

this

purpose

The

proof

theory

can

both

reason

about

transaction

execution

and

actually

perform

this

execution

Two

dual

proof

systems

are

presented

for

normal

execution

and

for

reverse

execution

-LRB-

it

is

assumed

that

for

every

elementary

update

the

transition

base

given

the

current

state

can

compute

both

the

successor

state

-LRB-

s

-RRB-

and

the

predecessor

state

-LRB-

s

-RRB-

-RRB-

These

two

proof

systems

are

profitably

linked

together

for

hypothetical

reasoning

-LRB-

What

would

happen

if

such

and

such

update

is

performed

-RRB-

A

shortcoming

of

T

R

is

that

its

model

theory

is

somewhat

complex

truth

is

defined

on

paths

over

states

each

state

being

a

set

of

possible

worlds

Nevertheless

by

focusing

in

the

right

problem

-LRB-

the

properties

of

combining

updates

into

transactions

not

the

properties

of

updates

themselves

-RRB-

T

R

presents

a

rich

and

computationally

meaningful

framework

for

updates

In

summary

some

of

the

approaches

in

this

area

seem

too

heavy-weight

and

concerned

with

reasoning

about

updates

instead

of

per

se

performing

updates

to

be

useful

for

an

efficient

implementation

at

the

lowest

fundamental

level

of

a

general

OOLP

language

Nevertheless

these

results

are

important

to

consider

if

a

language

closely

tied

with

a

Deductive

and

Object-Oriented

Databases

-LRB-

resp

a

database

programming

language

-RRB-

is

seeked

Modal

and

Dynamic

Logics

There

is

a

number

of

logics

of

action

developed

either

in

the

Artificial

Intelligence

community

or

for

providing

a

formal

semantics

of

the

execution

of

imperative

programs

Those

developed

for

AI

applications

-LRB-

e.g.

planning

-RRB-

are

usually

too

general

and

cumbersome

to

be

the

basis

of

an

OOLP

system

either

because

they

represent

actions

as

nested

terms

and

reason

explicitly

about

the

current

global

state

of

the

world

-LRB-

e.g.

McCarthy

's

Situation

Calculus

and

McCarty

's

Logic

of

Action

-RRB-

or

because

they

focus

on

the

temporal

side

of

actions

-LRB-

e.g.

Allen

's

logic

of

temporal

intervals

-RRB-

A

number

of

formalisms

for

semantics

of

imperative

programs

stems

from

Modal

Logic

and

Kripke

's

possible

worlds

approach

One

of

the

first

was

Floyd-Hoare

's

program

logic

Then

comes

Pratt

's

Process

Logic

-LSB-

-RSB-

Here

I

describe

Dynamic

Logic

-LSB-

-RSB-

and

its

use

for

the

semantics

of

object

state

change

The

language

of

Dynamic

Logic

consists

of

two

kinds

of

expressions

formulae

OE

and

programs

ff

-LRB-

programs

are

deemed

non-deterministic

-RRB-

Formulae

are

constructed

from

simpler

formulae

by

the

usual

logic

connectives

and

in

addition

from

a

formula

and

a

program

by

a

couple

of

dual

operators

-LSB-

-RSB-

OE

and

h

iOE

which

correspond

to

the

usual

modal

operators

necessarily

and

possibly

-LRB-

In

fact

Dynamic

Logic

can

be

seen

as

a

kind

of

multi-modal

logic

where

modalities

are

formed

by

programs

-RRB-

The

semantics

of

these

operators

is

defined

as

follows

if

OE

is

a

formula

is

a

program

and

w

is

the

current

program

state

-LRB-

world

-RRB-

then

w

j

-LSB-

-RSB-

OE

iff

j

OE

for

every

successor

of

w

w

j

h

iOE

iff

there

exist

a

successor

of

w

such

that

j

OE

Here

is

successor

of

w

means

that

the

program

leads

-LRB-

or

may

lead

if

it

is

actually

nondeterministic

-RRB-

from

the

state

w

to

the

state

Correspondingly

in

OE

-LSB-

-RSB-

the

formulae

OE

and

are

Dijkstra-style

pre

and

postconditions

of

respectively

Programs

are

constructed

from

elementary

programs

much

like

regular

expressions

using

the

following

forms

sequential

composition

j

non-deterministic

choice

infinite

iteration

-LRB-

Kleene

star

-RRB-

The

iteration

construct

means

execute

zero

or

more

times

The

set

of

elementary

programs

usually

consists

of

x

e

assignment

of

a

term

to

a

variable

OE

test

of

a

program-free

formula

The

test

OE

succeeds

when

OE

is

true

without

changing

the

current

state

-LRB-

the

test

is

side-effect

free

-RRB-

and

aborts

the

program

if

OE

is

false

-LRB-

i.e.

there

are

no

possible

successor

worlds

-RRB-

Non-determinism

turns

out

to

be

very

useful

because

e.g.

an

if-then-else

construct

can

be

defined

as

if

-LRB-

OE

ff

-RRB-

def

-LRB-

OE

-RRB-

j

-LRB-

OE

-RRB-

Sometimes

Context-Free

Dynamic

Logic

is

considered

-LRB-

instead

of

Regular

DL

-RRB-

where

the

language

of

DL

is

enriched

with

variables

for

programs

-LRB-

program

names

-RRB-

programs

are

formed

from

elementary

ones

using

a

context-free

grammar

and

thus

-LRB-

mutual

-RRB-

recursion

can

be

expressed

Typical

axioms

for

Dynamic

Logic

include

-LSB-

x

e

-RSB-

OE

OEfx

eg

-LSB-

OE

-RSB-

OE

-LSB-

-RSB-

OE

-LSB-

-RSB-

-LSB-

-RSB-

OE

-LSB-

j

-RSB-

OE

-LSB-

-RSB-

OE

-LSB-

-RSB-

OE

and

the

axioms

of

Modal

Logic

Although

Dynamic

Logic

has

been

designed

from

the

very

beginning

as

a

logic

of

imperative

programs

and

state

change

there

is

relatively

small

number

of

attempts

to

use

it

for

the

description

of

object

state

dynamics

In

the

work

of

Meyer

and

Wieringa

-LSB-

-RSB-

Dynamic

Logic

is

combined

with

Abstract

Data

Types

and

Order-Sorted

Logic

in

a

formal

specification

system

called

Conceptual

Model

Specification

Language

ADTs

-LRB-

see

also

Section

-RRB-

are

used

to

formalize

structured

object

values

whereas

DL

captures

object

dynamics

The

connection

between

the

two

relies

heavily

on

the

use

of

object

identifiers

A

similar

series

of

works

by

Jungclaus

Saake

Sernadas

and

Hartmann

-LSB-

-RSB-

emphasizes

dynamic

aspects

of

object

interaction

and

develops

a

language

called

Oblog

Burandt

-LSB-

-RSB-

in

his

diploma

thesis

has

started

work

in

the

same

direction

Similar

work

using

multi-modal

-LRB-

but

not

dynamic

-RRB-

logic

is

one

of

Fari

nas

del

Cerro

and

Herzig

-LSB-

-RSB-

They

use

modalities

of

the

form

ASSUME

-LSB-

p

-RSB-

where

p

is

a

literal

-LRB-

propositional

formula

or

its

negation

-RRB-

This

modality

performs

a

transition

to

a

world

which

is

the

same

as

the

current

one

except

that

the

literal

p

is

true

in

the

new

world

However

their

approach

is

too

simplistic

only

literal

assertions/deletions

are

allowed

and

the

database

is

assumed

complete

so

that

assuming

:p

amounts

to

deleting

p

and

their

logic

collapses

to

conventional

propositional

calculus

-LRB-

This

work

may

also

be

considered

under

Section

on

database

updates

-RRB-

Warren

-LSB-

-RSB-

and

Manchanda

-LSB-

-RSB-

in

his

thesis

develop

a

theory

of

database

updates

in

pure

Prolog

based

on

modal

logic

and

the

two

operators

assume

and

forget

which

are

similar

to

assert

and

retract

but

have

a

clear

logical

semantics

The

language

Object-Prolog

-LSB-

-RSB-

developed

in

Hungary

also

features

fully-backtrackable

assert/retract

ObjVProlog

of

Malenfant

Lapalme

and

Vaucher

-LSB-

-RSB-

uses

a

similar

approach

Uustalu

-LSB-

-RSB-

proposes

a

two-dimensional

modal

logic

which

models

uniformly

two

phenomena

overriding

inheritance

along

the

object

hierarchy

dimension

and

state

change

along

the

time

dimension

Objects

inherit

the

non-overridden

part

of

their

behavior

from

their

ancestors

in

the

inheritance

hierarchy

much

in

the

same

way

as

they

inherit

the

non-changed

parts

of

their

state

from

the

previous

instant

in

time

A

major

problem

with

utilising

Dynamic

Logic

for

mutable

object

state

is

that

it

is

designed

to

reason

about

programs

and

changes

not

to

actually

execute

them

or

serve

as

the

basis

of

an

ObjectOriented

Logic

Programming

system

In

DL

programs

and

logical

formulae

are

two

disparate

types

of

entities

whereas

in

Logic

Programming

programs

are

formulae

with

computation

equated

to

proof

search

Also

in

Object-Oriented

Programming

queries

-LRB-

methods

to

return

some

information

-RRB-

and

transactions

-LRB-

methods

to

perform

some

changes

-RRB-

can

be

freely

mixed

in

methods

which

both

return

information

and

have

side

effects

So

it

is

not

by

chance

that

the

attempts

to

use

DL

for

OOLP

has

come

from

the

formal

specification

community

and

not

from

the

logic

programming

community

Also

there

are

quite

a

few

LP

systems

implementing

modal

logic

-LSB-

-RSB-

and

they

are

more

theorem

provers

than

programming

systems

Perpetual

Objects

Exploiting

the

Dynamics

of

Proofs

As

was

mentioned

in

the

introductory

section

the

notion

of

truth

in

classical

logic

is

global

and

static

However

there

is

a

dynamic

component

in

a

LP

or

automated

proof

system

the

proof

process

itself

A

proof

develops

over

time

and

its

-LRB-

conceptually

parallel

-RRB-

branching

subproofs

are

spatially

separated

Therefore

it

is

possible

to

represent

objects

as

perpetually

reappearing

-LRB-

by

recursively

calling

themselves

-RRB-

predicates

bearing

the

object

state

in

their

argument

terms

There

is

a

whole

family

of

OOLP

languages

based

on

concurrent

versions

of

Prolog

and

the

fore-mentioned

paradigm

Concurrency

-LRB-

at

least

coroutine-based

pseudo-concurrency

-RRB-

is

needed

in

order

to

capture

the

simultaneous

development

of

a

number

of

objects

-LRB-

But

see

Section

for

two

approaches

achieving

the

same

effect

which

do

not

rely

on

concurrency

-RRB-

JosSome

early

ideas

are

proposed

in

Kahn

's

Intermission

-LSB-

-RSB-

Hewitt

and

Agha

's

Actors

also

influenced

this

approach

The

seminal

paper

is

by

Shapiro

and

Takeuchi

-LSB-

-RSB-

and

later

languages

are

Mandala

-LSB-

-RSB-

Vulcan

-LSB-

-RSB-

Polka

-LSB-

-RSB-

-LSB-

-RSB-

The

base

language

of

the

Fifth

Generation

Computer

Systems

project

ESP

-LSB-

-RSB-

can

also

be

counted

here

A

good

introduction

to

these

ideas

is

-LSB-

-RSB-

The

mechanics

of

modeling

OO

notions

in

this

paradigm

is

as

follows

-LSB-

-RSB-

Objects

are

represented

by

perpetual

predicates

-LRB-

proof

processes

-RRB-

In

order

to

persist

between

message

sends

the

object

has

to

explicitly

reinstate

itself

by

making

a

recursive

call

Object

state

is

represented

by

the

arguments

of

the

object

predicate

State

change

is

achieved

by

substituting

in

the

recursive

call

values

differing

from

the

input

parameters

of

the

message

send

One

of

the

arguments

of

the

predicate

is

a

message

stream

to

the

object

represented

as

a

lazy

list

-LRB-

one

whose

tail

can

be

undetermined

-RRB-

After

handling

a

message

the

object

passes

the

rest

of

the

stream

to

itself

object

-LRB-

State

-LSB-

mesg

StreamRest

-RSB-

-RRB-

change

-LRB-

State

NewState

-RRB-

object

-LRB-

NewState

StreamRest

-RRB-

The

object

process

is

activated

when

a

message

is

received

-LRB-

the

head

of

the

stream

is

bound

-RRB-

and

after

handling

the

message

the

process

is

suspended

Technically

this

means

that

the

recursive

call

is

not

pursued

immediately

but

is

postponed

until

-LRB-

the

head

of

-RRB-

StreamRest

gets

determined

and

also

that

no

backtracking

information

is

stored

for

this

call

-LRB-

that

is

tail

recursion

elimination

is

being

done

-RRB-

In

committed-choice

languages

the

clause

body

is

being

split

into

a

guard

and

body

proper

Head

Guard

Body

and

after

the

guard

is

satisfied

execution

commits

to

this

clause

by

forgetting

all

other

choice

points

-LRB-

is

called

the

commit

operator

-RRB-

So

our

earlier

example

becomes

object

-LRB-

State

-LSB-

-LRB-

Param

-RRB-

StreamRest

-RRB-

-LRB-

mesg

Param

-RRB-

-LRB-

State

NewState

-RRB-

object

-LRB-

NewState

StreamRest

-RRB-

object

-LRB-

State

-LSB-

-LRB-

Param

-RRB-

StreamRest

-RRB-

-LRB-

mesg

Param

-RRB-

-LRB-

State

NewState

-RRB-

object

-LRB-

NewState

StreamRest

-RRB-

If

an

object

can

not

handle

a

message

it

delegates

it

to

its

superobject

-LRB-

an

acquaintance

held

in

one

of

the

predicate

parameters

-RRB-

similar

to

the

Actors

paradigm

and

Self

class-less

prototype

objects

A

message

is

responded

to

either

by

sending

a

dedicated

message

in

the

opposite

direction

or

by

binding

a

place-holder

result

variable

built-in

the

message

term

This

way

the

sender

does

not

have

to

wait

until

the

message

is

responded

to

but

can

continue

execution

until

the

result

is

needed

at

which

point

it

will

be

suspended

if

the

result

is

not

bound

yet

A

problem

with

this

approach

is

that

the

semantics

of

Concurrent

Prolog

and

other

committed-choice

languages

is

very

different

from

the

semantics

of

Prolog

-LRB-

some

authors

even

go

as

far

as

to

call

Concurrent

Prolog

an

impure

dialect

of

Prolog

-RRB-

The

-LRB-

potential

-RRB-

nondeterminism

of

Prolog

's

Selection

Rule

-LRB-

which

clause

to

try

next

in

order

to

achieve

the

current

goal

-RRB-

is

a

kind

of

do

n't

know

non-determinism

and

does

not

affect

the

declarative

semantics

of

the

program

because

backtracking

tries

all

applicable

clauses

in

turn

-LRB-

unless

cut

is

used

-RRB-

However

in

committed-choice

languages

after

a

guard

is

satisfied

the

execution

commits

to

the

corresponding

clause

and

the

execution

of

all

other

clauses

is

abandoned

Therefore

it

is

an

essential

fact

that

the

guards

are

tested

before

the

body

of

the

clause

is

executed

and

so

the

commutativity

of

logical

conjunction

is

not

respected

Furthermore

the

programmer

should

ensure

that

it

does

not

matter

which

of

the

eligible

clauses

will

be

committed

to

-LRB-

do

n't

care

non-determinism

-RRB-

The

fore-mentioned

problem

although

making

programming

in

Concurrent

Prolog

a

less

declarative

effort

than

one

would

like

it

to

be

has

a

bright

side

it

makes

the

programming

of

reactive

systems

-LRB-

as

described

in

Section

-RRB-

possible

because

the

search

tree

is

pruned

early

and

not

all

possible

answers

to

the

stimulus

are

computed

but

only

the

ones

relevant

to

the

current

state

-LRB-

of

course

this

can

be

achieved

in

conventional

Prolog

but

it

will

involve

extensive

use

of

cut

-RRB-

Another

problem

is

that

all

the

arguments

of

the

predicate

-LRB-

attributes

of

the

object

-RRB-

are

to

be

passed

to

the

reinstating

recursive

call

even

if

only

a

small

part

of

them

are

changed

-LRB-

similarly

to

the

frame

problem

in

AI

-RRB-

It

is

possible

to

overcome

this

by

packaging

all

attributes

in

an

Abstract

Data

Type

entity

which

is

only

capable

of

performing

elementary

attribute

updates

but

this

introduces

another

level

of

indirection

and

thus

inefficiency

Another

problem

is

that

this

approach

does

not

model

very

well

the

structurisation

-LRB-

static

-RRB-

aspects

of

OOP

In

order

to

achieve

incremental

-LRB-

default

-RRB-

programming

-LRB-

specifying

only

the

methods

which

specialize

an

object

from

its

corresponding

superobject

-RRB-

the

programmer

has

to

maintain

in

the

subobject

a

pointer

to

its

superobject

and

call

the

superobject

explicitly

It

would

be

fair

to

say

that

this

approach

achieves

delegation

only

but

not

inheritance

Therefore

plainly

applied

this

approach

is

rather

low-level

Some

higher-level

languages

-LRB-

e.g.

Vulcan

and

-RRB-

are

implemented

as

preprocessors

which

translate

them

to

an

underlying

concurrent

LP

language

or

as

specialized

interpreters

which

perform

delegation

automatically

But

even

if

these

languages

are

more

convenient

they

are

somewhat

inefficient

compared

to

convenient

OOP

languages

like

C++

or

Smalltalk

because

the

representation

of

an

object

is

not

a

record

formed

by

appending

the

specializing

attributes

of

the

object

to

the

record

of

the

superobject

but

rather

a

chain

of

partial

records

connected

by

delegation

links

So

in

order

to

use

an

inherited

attribute

a

method

in

the

object

has

to

ask

its

superobject

explicitly

Also

since

a

self

pointer

pointing

to

the

object

is

not

passed

automatically

upon

delegation

polymorphism

is

problematical

Namely

if

the

superobject

needs

to

call

a

polymorphic

method

in

the

object

an

explicit

passing

of

self

is

to

be

arranged

by

the

programmer

This

also

creates

a

proliferation

of

processes

corresponding

to

partial

objects

and

complicates

the

message

patterns

between

them

Another

problem

is

that

the

is-a

and

part-of

hierarchies

are

mixed-up

both

require

that

the

object

holds

pointers

to

its

parts/superobjects

and

both

rely

on

explicit

delegation

This

has

both

bad

methodological

implications

and

causes

inefficiency

In

Smalltalk

the

parts

of

an

object

are

represented

by

pointers

in

its

record

-LRB-

unless

they

are

atomic

non-object

entities

like

numbers

-RRB-

but

in

C++

one

has

the

option

to

either

have

pointers

to

the

subparts

or

package

the

part

objects

themselves

in

the

record

This

approach

models

relatively

well

the

short-term

aspects

of

state

but

is

not

that

good

at

modeling

long-term

aspects

For

example

it

is

not

quite

clear

how

to

integrate

it

with

an

ObjectOriented

Database

short

of

using

completely

disparate

object

representations

in

the

short-term

and

long-term

memories

The

inconvenience

that

the

programmer

should

write

explicit

code

in

order

to

conform

to

the

object-oriented

style

has

a

reverse

side

it

is

possible

-LRB-

and

even

not

very

hard

-RRB-

to

program

very

flexible

and

varied

patterns

of

communication

and

delegation

which

would

be

hard

if

a

commitment

is

made

to

specific

patterns

in

the

language

itself

For

example

an

object

may

have

a

number

of

message

streams

-LRB-

ports

-RRB-

and

not

only

one

one-to-many

broadcasting

is

easy

and

many-to-one

communication

is

possible

by

introducing

special

stream-merging

components

or

a

generalization

of

streams

called

channels

The

reader

will

see

a

similar

phenomenon

inefficiency

and/or

inconvenience

but

on

the

other

side

great

flexibility

in

other

approaches

as

well

-LRB-

Section

-RRB-

Notwithstanding

its

deficiencies

this

approach

is

an

easy-to-implement

integration

of

completely

separate

ideas

which

are

fitted

very

well

together

Logical

Objects

and

Linear

Objects

Multiple

Heads

It

turns

out

that

the

salient

feature

exploited

by

the

perpetual

objects

approach

-LRB-

covered

in

the

previous

section

-RRB-

is

not

concurrency

itself

but

the

ability

to

pursue

more

than

one

goal

simultaneously

thus

modeling

the

simultaneous

development

of

more

than

one

object

Concurrency

-LRB-

or

coroutine-based

pseudo-concurrency

-RRB-

is

only

a

means

to

this

end

there

are

other

ways

to

achieve

it

One

of

them

is

to

extend

Prolog

by

allowing

many

heads

in

a

clause

and/or

disjunctive

goals

In

order

to

avoid

the

combinatorial

explosion

of

the

search

space

restrictions

should

be

imposed

on

the

way

these

additional

heads

are

pursued

This

section

describes

two

proposals

which

although

stemming

from

different

grounds

and

having

different

formal

justifications

nevertheless

end

up

in

a

quite

similar

form

Logical

Objects

was

proposed

by

Conery

-LSB-

-RSB-

in

It

introduces

a

new

kind

of

literals

object

literals

whose

arguments

carry

the

object

state

-LRB-

similarly

to

Section

-RRB-

However

the

thread

of

control

is

not

programmed

as

a

message

stream

held

by

the

object

but

more

in

the

spirit

of

conventional

Prolog

using

normal

literals

-LRB-

Conery

calls

them

procedure

literals

-RRB-

If

the

current

goal

contains

an

object

literal

it

is

not

pursued

independently

but

is

consumed

only

in

conjunction

with

other

procedure

literals

-LRB-

An

exception

to

this

rule

is

that

when

the

goal

consists

of

object

literal

-LRB-

s

-RRB-

only

they

are

executed

by

themselves

which

corresponds

to

some

finalizing

actions

with

the

object

-LRB-

s

-RRB-

destroying

them

or

checking

their

integrity

-RRB-

A

program

clause

is

allowed

to

have

in

its

head

in

addition

to

one

procedure

literal

zero

or

more

-LRB-

but

usually

or

-RRB-

object

literals

Since

the

head

is

deemed

a

conjunction

of

literals

these

are

not

really

clauses

anymore

-LRB-

which

are

disjunctions

of

literals

-RRB-

However

this

does

not

change

the

inference

method

drastically

-LRB-

it

is

very

similar

to

normal

binary

resolution

-RRB-

because

an

object

literal

is

only

pursued

together

with

a

procedure

literal

Thus

the

proof

that

some

object

exists

is

constructed

in

parallel

with

the

proof

that

it

has

certain

properties

In

order

for

a

clause

to

fire

all

its

heads

are

to

be

matched

in

the

set

of

goals

then

these

goals

are

consumed

and

the

clause

is

executed

object

-LRB-

ID

State

-RRB-

mesg

change

-LRB-

State

NewState

-RRB-

object

-LRB-

ID

NewState

-RRB-

-LRB-

contrast

this

with

the

example

in

Section

-RRB-

The

merit

of

this

approach

is

that

is

does

not

depend

on

a

Concurrent

Prolog

implementation

the

language

Hoops

described

in

-LSB-

-RSB-

is

normal

backtracking

Prolog

Object

state

in

the

Concurrent

Prolog

approach

is

held

in

a

suspended

-LRB-

waiting

for

a

message

-RRB-

process

while

in

this

approach

the

object

literals

in

the

goal

are

suspended

-LRB-

pushed

back

in

the

set

of

goals

-RRB-

until

a

suitable

procedure

literal

is

available

Therefore

suspending

here

is

performed

globally

in

only

one

place

If

there

are

no

object

literals

in

the

head

of

a

clause

but

there

is

some

in

the

body

a

new

object

is

created

Deletion

of

objects

is

modeled

by

having

an

object

literal

in

the

head

but

no

object

literal

in

the

body

Object

literals

usually

bear

an

OID

used

to

distinguish

among

separate

instances

of

the

same

class

If

there

are

two

object

literals

with

the

same

ID

in

the

head

and

in

the

body

this

corresponds

to

state

change

-LRB-

ID

-RRB-

-LRB-

ID

-RRB-

stack

-LRB-

ID

-LSB-

-RSB-

-RRB-

creation

push

-LRB-

ID

X

-RRB-

stack

-LRB-

ID

S

-RRB-

stack

-LRB-

ID

-LSB-

X

S

-RSB-

-RRB-

update

pop

-LRB-

ID

X

-RRB-

stack

-LRB-

ID

-LSB-

X

S

-RSB-

-RRB-

stack

-LRB-

ID

S

-RRB-

update

top

-LRB-

ID

X

-RRB-

stack

-LRB-

ID

-LSB-

X

S

-RSB-

-RRB-

stack

-LRB-

ID

-LSB-

X

S

-RSB-

-RRB-

pure

query

delete

-LRB-

ID

-RRB-

stack

-LRB-

ID

-RRB-

destruction

Conery

does

not

develop

any

inheritance

mechanisms

in

his

original

proposal

he

only

observes

that

The

Logical

Objects

approach

does

not

hinder

the

implementation

of

inheritance

A

later

implementation

in

Andorra

at

SICS

-LSB-

-RSB-

proves

him

right

-LRB-

Andorra

is

a

concurrent

LP

language

but

it

does

not

use

commitment

a

choice

point

is

delayed

until

sufficient

information

to

make

the

choice

is

available

-RRB-

If

the

object

A

inherits

from

the

object

B

then

A

consists

of

two

object

literals

with

the

same

ID

one

for

the

base

object

B

and

one

for

the

additional

attributes

of

A

An

example

adapted

from

-LSB-

-RSB-

follows

assume

that

we

have

an

account

object

and

we

extend

it

to

a

object

which

also

knows

about

tax

deductions

and

accumulates

the

current

deductions

D.

-LRB-

-RRB-

-LRB-

ID

-RRB-

-LRB-

ID

-RRB-

-LRB-

ID

-RRB-

-LRB-

-RRB-

-LRB-

ID

D

-RRB-

spend

-LRB-

ID

X

-RRB-

-LRB-

-RRB-

spend

-LRB-

ID

X

-RRB-

-LRB-

-RRB-

deduction

-LRB-

X

-RRB-

-LRB-

ID

D+D

-RRB-

What

appears

to

be

a

misplaced

recursive

call

in

-LRB-

-RRB-

is

in

fact

a

call

to

the

overridden

method

in

the

superclass

The

following

mechanism

accomplishes

this

when

the

head

of

the

clause

-LRB-

-RRB-

is

matched

in

the

set

of

goals

the

literal

-LRB-

ID

D

-RRB-

is

consumed

Therefore

the

predicate

call

-LRB-

-RRB-

can

not

match

again

the

same

clause

-LRB-

-RRB-

because

no

corresponding

object

literal

is

present

This

calls

the

supermethod

and

upon

return

from

it

the

needed

additional

computation

is

performed

and

the

is

re-established

However

this

technique

is

order

and

implementationdependent

because

the

application

of

a

clause

should

be

non-atomic

Furthermore

Conery

and

Haridi

does

not

explain

how

is

the

more

specific

method

chosen

for

execution

in

the

first

place

if

the

literal

account

needed

for

the

execution

of

the

more

general

-LRB-

super

-RRB-

method

has

also

been

present

This

inheritance

mechanism

-LRB-

as

well

as

this

problem

-RRB-

is

very

similar

to

the

one

used

in

Linear

Objects

-LRB-

see

below

-RRB-

which

has

been

developed

earlier

There

is

an

efficiency

problem

with

this

approach

the

concept

of

message

sending

in

Logical

Objects

is

quite

far

from

message

passing

in

traditional

object-oriented

languages

A

sender

does

not

really

send

the

message

to

the

receiver

it

rather

includes

receiver

's

ID

in

it

and

then

posts

the

message

to

a

global

blackboard-like

structure

-LRB-

the

set

of

goals

-RRB-

from

where

the

receiver

picks

it

using

pattern

matching

Conery

and

Haridi

in

-LSB-

-RSB-

mention

Pattern

Matched

Object

Selection

-LRB-

PMOS

-RRB-

and

argue

that

it

simplifies

programming

-LRB-

compared

to

the

Concurrent

Prolog

approach

-RRB-

because

no

explicit

communication

patterns

are

to

be

established

no

streams

are

to

be

connected

etc.

Although

this

observation

is

true

PMOS

has

bad

influence

on

efficiency

because

a

general

pattern

matcher

-LRB-

e.g.

of

the

kind

of

RETE

-RRB-

is

to

be

employed

Object

IDs

in

Logical

Objects

are

not

machine-oriented

effective

address-like

entities

-LRB-

currently

they

are

simply

integers

-RRB-

and

they

can

not

be

during

the

processing

of

every

message

the

object

is

consumed

and

then

recreated

again

and

it

would

be

impossible

to

notify

all

objects

who

reference

it

about

this

change

of

address

Smalltalk

has

a

similar

problem

-LRB-

objects

may

be

moved

during

garbage

collection

-RRB-

which

is

solved

using

two

redirection

levels

However

even

if

this

is

applied

here

the

problem

with

the

distribution

of

the

object

over

a

number

of

partial

records

-LRB-

corresponding

to

incrementally

extending

the

object

during

its

specialization

-RRB-

remains

The

unstructured

blackboard-like

global

object

space

reappears

in

Maude

-LRB-

see

Section

-RRB-

and

the

fragmented

object

records

and

the

lack

of

real

OIDs

is

even

worse

in

Linear

Objects

-LRB-

see

below

-RRB-

Linear

Objects

of

Andreoli

and

Pareschi

-LSB-

-RSB-

goes

one

step

further

than

Logical

Objects

not

only

is

an

object

separated

from

its

message

stream

but

the

object

literal

itself

is

split

into

small

pieces

each

bearing

only

one

attribute

or

a

few

related

attributes

Note

the

Linear

Objects

system

which

is

based

on

Linear

Logic

probably

belongs

to

Section

but

I

wanted

to

emphasize

its

similarity

to

Logical

Objects

In

any

case

it

can

not

be

fully

understood

without

reading

the

section

on

Linear

Logic

More

papers

are

available

as

technical

reports

from

the

European

Computer

industry

Research

Center

-LRB-

ECRC

-RRB-

in

Germany

This

finer

granularity

allows

methods

to

specify

and

carry-over

only

the

essential

attributes

of

the

object

the

ones

which

are

either

changed

by

the

method

or

are

inputs

to

the

method

It

also

allows

the

system

to

infer

is-a

relations

automatically

an

object

A

is-a

B

iff

the

multiset

of

attributes

of

A

is

a

superset

of

those

of

B

This

justifies

Andreoli

and

Pareschi

in

saying

that

Linear

Objects

have

built-in

inheritance

For

example

all

the

methods

for

point

below

-LRB-

e.g.

clause

-LRB-

-RRB-

-RRB-

also

apply

to

a

subclass

colored

point

In

the

methods

of

the

specialized

class

-LRB-

e.g.

-LRB-

-RRB-

-RRB-

one

does

not

have

to

mention

and

carry-over

attributes

from

the

base

class

-LRB-

e.g.

x

-LRB-

X

-RRB-

and

y

-LRB-

Y

-RRB-

-RRB-

unless

they

are

really

needed

-LRB-

-RRB-

point

x

-LRB-

X

-RRB-

y

-LRB-

Y

-RRB-

move

-LRB-

-RRB-

point

x

-LRB-

-RRB-

y

-LRB-

-RRB-

-LRB-

-RRB-

point

color

-LRB-

C

-RRB-

-LRB-

-RRB-

point

color

-LRB-

-RRB-

The

new

connective

in

the

clauses

above

is

the

multiplicative

disjunction

of

Linear

Logic

-LRB-

see

Section

-RRB-

It

is

used

as

the

glue

which

ties

the

part

of

an

object

together

The

other

connective

-LRB-

which

is

allowed

in

clause

bodies

but

not

in

clause

heads

-RRB-

is

additive

conjunction

It

aggregates

objects

and

messages

into

larger

entities

called

contexts

and

at

the

same

time

separates

objects

from

one

another

and

does

not

allow

parts

of

different

objects

to

mix

together

-LRB-

binds

stronger

than

-RRB-

The

connective

which

divides

the

head

of

a

clause

-LRB-

method

-RRB-

from

its

body

is

linear

implication

Similarly

to

a

probelm

in

Conery

's

proposal

it

is

not

clear

how

exactly

the

most

specific

method

-LRB-

overriding

a

method

in

a

superclass

-RRB-

is

chosen

for

execution

There

is

one

more

kind

of

implication

-LRB-

linear

implication

combined

with

the

modality

of

course

-RRB-

which

specifies

that

the

method

is

applicable

only

if

the

literals

in

the

goal

exactly

match

the

literals

in

the

clause

head

-LRB-

and

are

not

simply

a

superset

-RRB-

but

Andreoli

and

Pareschi

do

not

use

it

for

this

purpose

Linear

Objects

are

well

suited

for

concurrent

programming

because

additive

disjunction

introduces

a

kind

of

OR-parallelism

dual

to

the

usual

AND-parallelism

of

goals

in

a

clause

Andreoli

and

Pareschi

compare

these

to

the

internal

distribution

of

tasks

in

an

organization

and

the

external

co-operation

among

organizations

-LRB-

In

fact

Linear

Objects

uses

message

streams

but

this

was

of

no

importance

for

the

examples

-LRB-

-RRB-

and

-LRB-

-RRB-

-RRB-

The

problem

of

Logical

Objects

that

an

object-message

pair

is

to

be

pattern-matched

to

its

corresponding

method

reappears

here

but

it

is

even

worse

because

the

granularity

is

finer

This

finer

granularity

enables

great

flexibility

but

one

has

to

pay

for

it

Andreoli

and

Pareschi

have

used

partial

evaluation

techniques

to

diminish

this

problem

probably

the

experience

gained

from

the

Self

language

will

be

useful

here

An

intuitive

criticism

of

Linear

Objects

is

that

such

finely

crushed

objects

do

not

seem

very

well

encapsulated

their

only

capsule

is

the

surrounding

pair

of

connectives

This

leads

to

bad

consequences

e.g.

all

the

attributes

of

an

object

have

to

be

mentioned

for

a

destruction

or

a

copy

operation

thus

every

object

should

have

its

own

such

operation

In

a

conventional

OOP

language

the

compiler

takes

care

of

this

Also

a

method

in

Linear

Objects

does

not

belong

to

a

distinguished

class

explicitly

by

the

program

its

owner

is

only

determined

at

runtime

by

the

set

of

object

literals

which

the

method

lists

in

its

head

In

a

summary

Logical

Objects

and

Linear

Objects

are

refinements

of

the

objects-asprocesses

approach

-LRB-

Section

-RRB-

overcoming

many

of

its

deficiencies

mainly

in

the

structurisation

and

inheritance

aspects

However

deduction

in

them

heavily

uses

pattern

matching

of

objectmessage

pairs

to

methods

which

may

be

a

source

of

inefficiency

Also

real

object

identifiers

are

impossible

in

these

approaches

Linear

Objects

are

firmly

founded

in

Linear

Logic

and

thus

have

a

sound

and

well-understood

semantics

Linear

Logic

Resources

Rather

Than

Truth

Values

Linear

Logic

has

been

proposed

by

Jean-Yves

Girard

in

-LSB-

-RSB-

and

since

then

has

received

the

attention

of

many

computer

scientists

-LRB-

see

e.g.

-LSB-

-RSB-

for

some

developments

and

-LSB-

-RSB-

for

a

survey

-RRB-

The

reason

for

this

is

that

unlike

classical

logic

Linear

Logic

regards

propositions

as

resources

which

are

consumed

and

produced

during

the

inference

process

and

not

as

universally

valid

-LRB-

or

universally

false

-RRB-

assertions

This

is

why

Linear

Logic

is

called

resource-aware

and

why

it

is

useful

in

many

areas

of

computer

science

which

deal

with

resources

Classical

logic

treats

the

proof

process

only

as

a

device

to

achieve

some

conclusions

whereas

in

Linear

Logic

the

proof

process

is

a

first

class

citizen

and

is

no

less

important

then

the

conclusions

themselves

This

is

why

it

is

useful

to

describe

and

program

-LRB-

concurrent

-RRB-

processes

-LRB-

Of

course

classical

logic

has

rich

and

substantial

proof

theory

but

it

is

outside

the

logic

-RRB-

There

are

many

ways

to

explain

why

Linear

Logic

but

one

of

the

most

natural

ways

is

to

look

at

it

as

restrictions

on

the

allowed

proofs

in

order

to

make

them

more

constructive

-LSB-

-RSB-

A

proof

in

classical

logic

contains

many

redundancies

which

increase

the

space

of

proofs

a

lot

and

make

searching

for

proofs

hard

These

include

various

non-essential

choices

-LRB-

permutations

of

parts

of

the

proof

-RRB-

and

worse

of

all

dead-ends

subproofs

of

propositions

which

are

then

simply

thrown

away

Linear

Logic

gets

rid

of

these

using

two

approaches

ffl

Every

proposition

should

be

used

once

and

exactly

once

during

the

proof

-LRB-

resource-awareness

-RRB-

The

sequents

of

Linear

Logic

are

not

sets

of

formulae

but

multisets

Linear

Logic

does

not

have

the

usual

structural

rules

of

classical

logic

-LSB-

Weakening

-RSB-

-LSB-

Contraction

-RSB-

which

allow

one

to

reuse

or

throw

away

formulae

-LRB-

and

denote

multisets

of

formulae

and

denote

individual

formulae

-RRB-

-LRB-

But

a

formula

may

be

preceded

by

the

modal

exponential

operator

of

course

or

its

dual

why

not

in

which

case

it

can

be

used

any

number

of

times

-RRB-

ffl

Linear

Logic

uses

special

syntactic

devices

in

order

to

explicate

the

intended

proof

of

a

formula

In

other

words

the

syntax

guides

the

proof

-LSB-

p.

ff

-RSB-

The

idea

of

syntax-directed

proof

search

leads

to

splitting

conjunction

and

disjunction

into

two

forms

additive

and

multiplicative

additive

multiplicative

conjunction

disjunction

-RCB-

These

new

connectives

are

not

idempotent

-LRB-

e.g.

-RRB-

unlike

the

classical

connectives

-LRB-

e.g.

-RRB-

so

a

formula

can

not

be

duplicated

or

disposed

of

arbitrarily

This

makes

it

possible

to

differentiate

between

two

intended

uses

of

the

connectives

which

are

mixed

in

classical

inference

rule

systems

Each

of

the

linear

connectives

have

one

corresponding

inference

rule

for

conjunctions

-LSB-

-RSB-

-LSB-

-RSB-

-LRB-

both

of

these

rules

would

be

allowed

for

in

classic

logic

-RRB-

Analogously

for

disjunctions

-LSB-

-RSB-

-LSB-

-RSB-

Linear

Logic

is

complicated

compared

to

classical

logic

Not

only

it

has

more

connectives

but

they

are

also

non-functional

which

means

that

truth

tables

can

not

be

used

For

example

the

linear

negation

OE

of

a

propositional

letter

OE

is

not

reducible

to

OE

in

a

sense

it

is

independent

of

it

Full

propositional

linear

logic

is

undecidable

-LRB-

classical

propositional

calculus

is

decidable

it

is

a

special

case

of

propositional

linear

calculus

with

every

formula

preceded

by

-RRB-

The

complexity

results

for

fragments

of

Linear

Logic

are

also

not

very

encouraging

for

example

the

multiplicative

fragment

which

corresponds

to

Horn

clause

programming

is

np-complete

-LSB-

-RSB-

During

goal-directed

proof

search

inference

rules

are

used

backwards

-LRB-

the

conclusion

is

given

and

we

are

searching

for

the

premises

-RRB-

The

specific

proof-theoretic

properties

of

Linear

Logic

justify

that

one

can

apply

initially

only

the

four

pure

logic

rules

listed

above

until

the

goal

is

split

to

atoms

and

use

the

logic

program

only

afterwards

This

simplifies

greatly

the

proof

construction

process

Andreoli

and

Pareschi

use

in

Linear

Objects

the

connectives

and

and

employ

the

specific

property

of

inference

rule

-LSB-

-RSB-

that

the

context

is

duplicated

in

the

two

premises

for

object

cloning

Linear

Logic

has

been

applied

in

various

areas

of

computing

science

from

encoding

Petri

Nets

in

logic

to

optimizing

functional

languages

by

controlling

interference

between

expressions

There

is

a

relatively

small

but

growing

number

of

attempts

to

use

it

for

logic

programming

-LSB-

-RSB-

I

believe

that

it

can

be

used

more

locally

to

deal

with

mutable

object

state

not

in

the

particular

style

of

Linear

Objects

in

order

to

avoid

the

global

blackboard

space

to

avoid

splitting

objects

into

such

small

pieces

and

to

achieve

an

OOLP

language

more

faithful

to

traditional

OOP

Rewriting

Logic

Free

Object

Reductions

In

Jos?e

Meseguer

proposed

a

logical

theory

of

concurrent

objects

-LSB-

-RSB-

based

on

his

earlier

joint

work

with

Joseph

Goguen

on

Abstract

Data

Types

and

the

OBJ

family

of

equational

languages

He

defines

Rewriting

Logic

and

a

language

for

declarative

concurrent

object-oriented

programming

called

Maude

Later

-LSB-

-RSB-

he

develops

a

theory

of

general

logics

based

on

Category

Theory

in

order

to

formalize

the

notion

of

a

Logic

Programming

Language

and

a

methodology

of

integration

of

such

languages

by

mapping

them

to

a

richer

logic

which

encompasses

them

all

-LRB-

Meseguer

calls

Logic

Programming

Language

any

declarative

in

nature

programming

language

and

what

traditionally

is

called

LP

he

names

Relational

Programming

-RRB-

He

proposes

Rewriting

Logic

as

such

an

encompassing

logic

and

using

it

integrates

rigorously

the

functional

relational

and

object-oriented

paradigms

In

this

work

he

extends

Maude

to

a

language

called

MaudeLog

which

includes

Horn

clause

programming

Some

aspects

of

the

paper

-LSB-

-RSB-

are

rather

technical

but

overall

it

is

very

clear

and

enlightening

Meseguer

argues

that

declarativeness

is

only

one

of

the

advantages

of

LP

and

another

no

less

important

is

its

suitability

for

concurrent

programming

logical

axioms

bear

no

inherent

order

or

sequence

so

their

application

can

be

performed

in

parallel

However

Horn

logic

-LRB-

and

more

generally

classical

logic

-RRB-

are

not

suited

well

for

dynamic

computations

because

they

are

based

on

a

Platonic

static

notion

of

truth

and

they

deal

with

static

objects

functions

relations

etc.

This

makes

traditional

LP

languages

awkward

for

concurrent

programming

and

even

for

sequential

object-oriented

-LRB-

state-oriented

-RRB-

programming

and

therefore

unsuitable

for

large

programming

tasks

Rewriting

Logic

is

very

similar

to

-LRB-

order-sorted

-RRB-

equational

logic

but

in

addition

to

equations

one

can

specify

rewriting

rules

which

differ

from

equations

in

that

they

work

only

in

one

direction

-LRB-

the

corresponding

relation

is

transitive

but

not

symmetric

-RRB-

An

example

is

-LRB-

-RRB-

eq

d

q

q

q

q

-LRB-

-RRB-

rl

d

q

q

q

q

Here

d

stands

for

a

dollar

q

stands

for

a

quarter

the

equation

-LRB-

-RRB-

specifies

that

a

dollar

equals

four

quarters

and

the

rewrite

rule

-LRB-

-RRB-

may

specify

the

behavior

of

a

change

machine

which

can

break

a

dollar

into

four

quarters

but

not

the

other

way

around

Lets

add

the

appropriate

declarations

in

order-sorted

logic

-LRB-

assuming

that

the

sort

Nat

is

imported

from

some

library

module

-RRB-

-LRB-

-RRB-

sorts

Cents

Purse

-LRB-

-RRB-

subsort

Cents

Nat

-LRB-

-RRB-

subsort

Cents

Purse

-LRB-

-RRB-

ops

d

q

Cents

-LRB-

-RRB-

op

Cents

Cents

Cents

-LSB-

assoc

comm

id

-RSB-

-LRB-

-RRB-

op

Purse

Purse

Purse

-LSB-

assoc

comm

id

-RSB-

Here

-LRB-

-RRB-

declares

the

sorts

Cents

for

an

amount

of

money

and

Purse

for

a

set

of

coins

-LRB-

-RRB-

declares

that

Cents

is

a

subsort

-LRB-

specialization

-RRB-

of

Nat

similarly

-LRB-

-RRB-

says

that

a

single

coin

makes

a

purse

Line

-LRB-

-RRB-

declares

d

and

q

as

constants

of

sort

Cents

-LRB-

zeroary

functions

returning

Cents

-RRB-

Line

-LRB-

-RRB-

declares

the

operation

Plus

which

adds

two

amounts

of

Cents

and

is

associative

-LRB-

this

justifies

the

absence

of

parentheses

in

-LRB-

-RRB-

-RRB-

commutative

and

with

as

its

identity

element

The

two

underlines

around

the

declare

it

as

a

binary

infix

operation

Line

-LRB-

-RRB-

declares

an

empty-syntax

operation

-LRB-

there

is

nothing

between

the

two

-RRB-

which

again

is

associative

commutative

and

with

identity

element

-LRB-

is

what

stays

between

the

d

's

on

the

right-hand

side

of

-LRB-

-RRB-

just

nothing

-RRB-

The

operation

in

-LRB-

-RRB-

is

simply

multiset

union

-LRB-

denoted

by

juxtaposition

of

elements

-RRB-

which

takes

two

Purses

and

combines

them

into

a

bigger

Purse

Now

it

becomes

clear

that

the

sort

Purse

denotes

a

multiset

-LRB-

bag

that

is

duplicates

are

allowed

-RRB-

and

not

just

a

plain

set

because

the

union

operation

is

not

idempotent

Note

Semantically

the

two

operations

-LRB-

-RRB-

and

-LRB-

-RRB-

are

rather

different

the

former

takes

two

elements

and

forms

their

sum

while

the

latter

keeps

the

two

elements

distinct

and

only

puts

them

into

an

aggregate

We

may

define

a

function

which

sums

all

the

coins

of

a

purse

-LRB-

-RRB-

op

amount

Purse

Cents

-LRB-

-RRB-

vars

Purse

-LRB-

-RRB-

eq

amount

-LRB-

-RRB-

-LRB-

-RRB-

eq

amount

-LRB-

-RRB-

amount

-LRB-

-RRB-

amount

-LRB-

-RRB-

but

once

two

amounts

of

Cents

are

summed

it

is

impossible

to

recover

the

coin

distribution

of

the

result

In

Maude

an

object

is

represented

as

a

term

hO

C

j

an

vni

where

O

is

the

object

identifier

a

term

of

sort

OID

C

is

the

object

class

an

are

the

object

attributes

and

vn

are

their

values

-LRB-

the

object

state

-RRB-

Messages

are

represented

similarly

as

terms

bearing

the

identity

of

the

receiver

and

other

relevant

information

These

message

parameters

are

injected

in

the

message

term

by

corresponding

message

constructor

functions

e.g.

-LRB-

-RRB-

msgs

credit

debit

OID

Nat

Message

-LRB-

-RRB-

msg

Nat

OID

OID

Message

Line

-LRB-

-RRB-

gets

a

receiver

's

OID

and

an

amount

and

constructs

a

Message

for

the

corresponding

operation

Line

-LRB-

-RRB-

declares

a

ternary

mix-fix

operation

which

constructs

a

message

to

transfer

a

Nat

amount

of

money

from

one

account

to

another

For

type-checking

purposes

it

probably

would

be

better

to

declare

the

object

parameters

of

these

functions

not

simply

as

OID

but

as

specific

object

classes

e.g.

Account.OID

There

is

no

problem

to

have

separate

OID

types

for

every

class

and

a

preprocessor

which

does

this

automatically

has

been

implemented

for

Maude

The

technical

device

of

an

Associative

Commutative

operation

with

Identity

-LRB-

ACI-operation

-RRB-

is

used

in

Rewriting

Logic

to

represent

collections

of

distributed

objects

and

the

messages

flowing

between

them

The

ACI

operation

binds

these

entities

into

an

object

space

-LRB-

configuration

of

distributed

objects

-RRB-

-LRB-

-RRB-

subsorts

Object

Message

Configuration

-LRB-

-RRB-

op

Configuration

Configuration

Configuration

-LSB-

assoc

comm

id

-RSB-

When

an

object

needs

to

communicate

with

another

object

it

simply

posts

a

message

to

this

global

space

Then

this

message

interacts

with

the

receiver

as

governed

by

the

appropriated

rewrite

rules

the

left

part

of

a

rule

is

matched

against

the

message

and

-LRB-

part

of

-RRB-

the

state

variables

of

the

receiver

and

then

the

message

is

-LRB-

usually

-RRB-

consumed

-LRB-

rewritten

to

-RRB-

and

the

receiver

's

state

changed

Also

another

message

can

be

generated

during

this

process

and

sent

to

some

other

object

Unlike

e.g.

Smalltalk

where

a

method

always

belongs

to

a

particular

class

and

every

message

should

have

a

designated

receiver

-LRB-

so

is

interpreted

as

the

message

sent

to

the

object

which

is

rather

unnatural

-RRB-

in

Maude

this

need

not

be

so

The

message

has

two

receivers

in

the

sense

that

the

corresponding

method

-LRB-

rewrite

rule

-RRB-

should

be

able

to

locate

both

objects

-LRB-

-RRB-

and

-LRB-

-RRB-

-LRB-

-RRB-

rl

-LRB-

-RRB-

transfer

A

from

X

to

Y

-LRB-

-RRB-

X

Account

bal

XB

-LRB-

-RRB-

Y

Account

bal

YB

-LRB-

-RRB-

-LRB-

-RRB-

X

Account

bal

XB-A

-LRB-

-RRB-

Y

Account

bal

YB+A

-LRB-

-RRB-

if

XB

A

-LRB-

of

course

this

can

be

written

more

compactly

-RRB-

This

rule

says

If

the

entities

-LRB-

-RRB-

-LRB-

-RRB-

and

-LRB-

-RRB-

are

simultaneously

present

they

can

be

rewritten

to

-LRB-

-RRB-

and

-LRB-

-RRB-

provided

-LRB-

-RRB-

holds

-LRB-

so

we

have

Conditional

Rewriting

Logic

here

-RRB-

Please

note

that

-LRB-

-RRB-

is

not

a

method

name

it

is

an

entity

which

should

be

present

in

the

Configuration

for

this

rewrite

rule

to

fire

just

like

the

two

receiver

objects

-LRB-

-RRB-

and

-LRB-

-RRB-

Formally

the

difference

between

equations

and

rewrite

rules

is

not

that

big

the

former

work

in

both

directions

-LRB-

symmetric

-RRB-

whereas

the

latter

work

in

only

one

direction

Actually

in

the

operational

sense

they

are

almost

the

same

because

one

usually

uses

equations

unidirectionally

to

rewrite

function

calls

with

the

corresponding

function

definitions

in

order

to

obtain

a

particular

canonic

form

However

the

underlying

logical

semantics

are

rather

different

the

unidirectional

nature

of

rewriting

rules

corresponding

to

the

unidirectional

flow

of

time

in

an

evolving

distributed

system

Adding

relational

programming

-LRB-

going

from

Maude

to

MaudeLog

-RRB-

is

not

hard

it

is

well

known

that

Prolog

goal-directed

deduction

can

be

thought

of

as

rewriting

the

current

set

of

goals

using

the

program

clauses

as

rewriting

rules

until

the

empty

goal

is

reached

Logic

variables

can

be

modelled

by

allowing

variables

in

the

rewriting

rules

and

non-determinism

-LRB-

with

which

Prolog

deals

by

backtracking

-RRB-

is

accounted

for

by

the

non-deterministic

nature

of

rewrite

-LRB-

there

may

be

many

rules

which

match

the

current

configuration

-RRB-

-LRB-

A

similar

in

spirit

work

by

Debart

-LSB-

-RSB-

demonstrates

clearly

the

power

of

equational

rewriting

techniques

by

implementing

multi-modal

logic

programming

through

a

translation

of

modal

formulae

to

many-sorted

equational

formulae

-RRB-

For

example

the

Prolog

program

grandparent

-LRB-

X

Z

-RRB-

parent

-LRB-

X

Y

-RRB-

parent

-LRB-

Y

Z

-RRB-

parent

-LRB-

peter

paul

-RRB-

parent

-LRB-

mary

paul

-RRB-

is

translated

to

the

Maude

module

mod

FAMILY

is

extending

PROLOG

sort

People

ops

peter

paul

mary

People

ops

parent

grandparent

People

People

Bool

vars

X

Y

Z

People

rl

parent

-LRB-

X

Y

-RRB-

parent

-LRB-

Y

Z

-RRB-

grandparent

-LRB-

X

Z

-RRB-

rl

true

parent

-LRB-

peter

paul

-RRB-

rl

true

parent

-LRB-

mary

paul

-RRB-

endm

The

module

PROLOG

imported

by

FAMILY

defines

the

sort

Bool

and

the

ACI

operation

Bool

Bool

Bool

-LRB-

conjunction

-RRB-

with

identity

true

Then

we

may

ask

the

system

whether

it

can

perform

the

rewrite

true

grandparent

-LRB-

X

paul

-RRB-

This

theory

seems

rigorous

general

and

elegant

many

of

the

difficult

problems

of

multiparadigm

programming

-LRB-

including

the

problem

of

mutable

state

-RRB-

simply

do

not

appear

in

it

The

main

criticism

to

it

is

that

its

efficient

implementation

does

not

seem

easy

For

one

thing

rewriting

should

be

done

modulo

the

ACI

rules

Formally

speaking

this

means

that

we

will

have

to

rewrite

not

simply

terms

but

equivalence

classes

of

terms

under

the

ACI

relation

Informally

this

means

that

a

powerful

enough

matching

algorithm

should

be

used

so

that

it

can

efficiently

try

all

possible

permutations

of

the

entities

in

the

configuration

-LRB-

e.g.

the

three

entities

-LRB-

-RRB-

-LRB-

-RRB-

and

-LRB-

-RRB-

above

should

be

thought

of

as

unordered

-RRB-

For

some

recent

work

on

AC

and

ACI-rewriting

see

-LSB-

-RSB-

Another

problem

is

that

a

rewriting

rule

should

mention

and

carry

to

the

other

side

all

of

the

state

of

an

object

even

the

attributes

which

do

not

affect

and

are

not

affected

by

the

rule

-LRB-

in

-LRB-

-RRB-

we

have

assumed

that

the

only

attribute

of

Account

is

bal

-RRB-

This

can

be

avoided

using

partial

matching

-LRB-

with

placeholder

do

n't

care

variables

-RRB-

inside

the

structure

of

the

object

e.g.

-LRB-

-RRB-

rl

transfer

A

from

X

to

Y

X

Account

bal

XB

RestX

-LRB-

-RRB-

Y

Account

bal

YB

RestY

-LRB-

-RRB-

X

Account

bal

XB-A

RestX

-LRB-

-RRB-

Y

Account

bal

YB+A

RestY

if

XB

A

-LRB-

Here

the

operation

inside

the

object

structure

should

also

be

ACI

Of

course

the

addition

of

do

n't

cares

better

be

done

automatically

-RRB-

However

this

makes

the

job

of

the

pattern

matcher

ever

harder

There

was

a

similar

problem

in

Logical

Objects

-LRB-

Section

-RRB-

Although

each

individual

object

is

well-structured

the

configuration

of

objects

is

very

much

like

a

blackboard

-LRB-

the

same

like

in

Logical

Objects

-RRB-

and

is

to

be

accessed

globally

by

some

interpreter

which

detects

ready-to-interact

object-message

pairs

The

natural

way

to

avoid

this

huge

global

space

is

to

allow

objects

to

have

subobjects

as

components

-LRB-

aggregation

-RRB-

which

is

not

provided

for

in

Maude

In

conclusion

Rewriting

Logic

is

a

marvelous

device

which

integrates

in

a

very

simple

and

natural

manner

paradigms

which

were

traditionally

hard

to

reconcile

functional

object-oriented

relational

and

concurrent

programming

It

only

remains

to

implement

it

efficiently

Conclusions

Of

the

huge

variety

of

different

proposals

to

accommodate

state

change

in

Logic

Programming

a

couple

of

approaches

stand

out

as

most

promising

-LRB-

of

course

this

selection

is

highly

subjective

-RRB-

ffl

Traditional

but

revitalized

approaches

as

evidenced

by

Transaction

Logic

-LRB-

Section

-RRB-

Here

the

important

point

is

a

shift

of

the

emphasis

from

the

controversial

non-monotonic

issues

of

elementary

updates

to

the

compositional

properties

of

transactions

built

up

from

such

updates

and

the

possibility

to

really

program

such

transactions

ffl

Approaches

based

on

Linear

Logic

-LRB-

Section

-RRB-

whose

resource-awareness

makes

it

suitable

for

reasoning

about

concurrency

and

locality

and

whose

constructive

in

nature

proof

search

makes

it

suitable

for

logic

programming

I

believe

that

despite

Andreoli

and

Pareschi

's

numerous

-LRB-

and

excellent

-RRB-

works

Linear

Logic

has

not

been

utilized

in

full

in

this

area

yet

ffl

Ways

to

implement

Rewriting

Logic

-LRB-

Section

-RRB-

efficiently

which

would

make

the

three

major

programming

paradigms

available

in

a

well-integrated

framework

and

would

expose

unexpected

synergism

between

them

In

any

case

it

should

be

concluded

that

despite

numerous

efforts

no

generally

accepted

solution

to

this

problem

exists

yet

and

there

is

a

large

area

for

research

References

-LSB-

-RSB-

S.

Abiteboul

Updates

A

new

frontier

In

Second

Intl.

Conf

on

Database

Theory

pages

-LCB-

-LSB-

-RSB-

S.

Abiteboul

and

V.

Vianu

Procedural

and

declarative

database

update

languages

In

Principles

of

Database

Systems

-LRB-

PODS

-RRB-

pages

-LCB-

ACM

SIGACT-SIGMOD-SIGART

-LSB-

-RSB-

S.

Abramsky

Computational

interpretations

of

linear

logic

Theoretical

Comput

Sci.

-LCB-

Earlier

version

appeared

as

Imperial

College

Technical

Report

DOC

Oct.

-LSB-

-RSB-

V.

Alexiev

Applications

of

linear

logic

to

computation

An

overview

Technical

Report

-LCB-

University

of

Alberta

Dec.

Submitted

to

Bulletin

of

the

IGPL

-LSB-

-RSB-

J.-M

Andreoli

and

R.

Pareschi

Logic

programming

with

sequent

systems

A

linear

logic

approach

In

P.

Schroeder-Heister

editor

Intl.

Workshop

on

Extensions

of

Logic

Programming

number

in

LNAI

pages

-LCB-

Tubingen

Germany

-LSB-

-RSB-

J.-M

Andreoli

and

R.

Pareschi

Linear

objects

Logical

processes

with

built-in

inheritance

In

D.

Warren

and

P.

Szeredi

editors

Intl.

Conf

on

Logic

Programming

-LRB-

ICLP

-RRB-

pages

-LCB-

Jerusalem

Israel

June

MIT

Press

-LSB-

-RSB-

J.-M

Andreoli

and

R.

Pareschi

LO

and

behold

Concurrent

Structured

Processes

In

ECOOP

OOPSLA

Ottawa

Ontario

-LRB-

SIGPLAN

Notices

-LRB-

-RRB-

-LCB-

Oct.

-RRB-

-LSB-

-RSB-

J.-M

Andreoli

and

R.

Pareschi

Linear

objects

Logical

processes

with

built-in

inheritance

New

Generation

Computing

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

F.

Banchilon

A

logic

programming/object-oriented

cocktail

SIGMOD

Record

-LRB-

-RRB-

-LCB-

Sept.

-LSB-

-RSB-

A.

Bonner

and

M.

Kifer

Transaction

logic

programming

-LRB-

or

a

logic

of

procedural

and

declarative

knowledge

-RRB-

In

Intl.

Conf

on

Logic

Programming

-LRB-

ICLP

-RRB-

pages

-LCB-

Budapest

Hungary

The

full

papewr

is

available

as

University

of

Toronto

Technical

Report

April

-LRB-

revised

May

-RRB-

from

csri.toronto.edu

-LSB-

-RSB-

A.

Bonner

and

M.

Kifer

A

general

logic

of

state

change

Technical

report

Computer

Systems

Research

Institute

University

of

Toronto

In

preparation

-LSB-

-RSB-

A.

Burandt

Equivalence

of

Denotational

Semantics

and

Conditions

of

Standard

Models

in

the

Dynamic

Logic

Diploma

thesis

University

of

Karlsruhe

-LSB-

-RSB-

W.

Chen

Declarative

specification

and

evaluation

of

database

updates

In

C.

Delobel

M.

Kifer

and

Y.

Masunaga

editors

Deductive

and

Object-Oriented

Databases

-LRB-

DOOD

-RRB-

number

in

LNCS

pages

-LCB-

Munich

Germany

Dec.

-LSB-

-RSB-

T.

Chikayama

ESP

-LCB-

Extended

Self-contained

Prolog

-LCB-

as

a

preliminary

kernel

language

of

Fifth

Generation

computers

New

Generation

Computing

-LCB-

-LSB-

-RSB-

T.

Chikayama

Unique

features

of

ESP

In

International

Conference

on

Fifth

Generation

Computer

Systems

pages

-LCB-

Tokyo

Nov.

-LSB-

-RSB-

J.

Conery

and

S.

Haridi

Eudorra

and

object-oriented

Andorra

Position

paper

on

the

ICLP

Workshop

on

OOLP

June

-LSB-

-RSB-

J.

S.

Conery

HOOPS

an

object-oriented

Prolog

Technical

report

University

of

Oregon

-LSB-

-RSB-

J.

S.

Conery

Object-oriented

programming

with

First-Order

Predicate

Calculus

Technical

Report

University

of

Oregon

Aug.

-LSB-

-RSB-

J.

S.

Conery

Logical

objects

In

R.

A.

Kowalski

and

K.

A.

Bowen

editors

Fifth

International

Conference

and

Symposium

on

Logic

Programming

pages

-LCB-

-LSB-

-RSB-

A.

Davison

Polka

a

Parlog

object-oriented

language

Technical

report

DOC

Imperial

College

London

-LSB-

-RSB-

A.

Davison

From

Parlog

to

Polka

in

two

easy

steps

In

J.

Maluszy?nski

and

M.

Wirsing

editors

Third

International

Symposium

on

Programming

Language

Implementation

and

Logic

Programming

PLILP

number

in

LNCS

pages

-LCB-

Springer-Verlag

-LSB-

-RSB-

A.

Davison

A

survey

of

logic

programming-based

object-oriented

languages

Technical

Report

University

of

Melbourne

Jan.

Fourth

revision

first

published

April

-LSB-

-RSB-

F.

Debart

P.

Enjalbert

and

M.

Lescot

Multi-modal

logic

programming

using

equational

and

order-sorted

logic

In

H.

Kirchner

and

W.

Wechler

editors

Algebraic

and

Logic

Programming

-LRB-

ALP

-RRB-

number

in

LNCS

pages

-LCB-

Nancy

France

Oct.

Springer-Verlag

-LSB-

-RSB-

A.

Doman

Object-Prolog

Dynamic

object-oriented

representation

of

knowledge

In

T.

Henson

editor

SCS

Multiconference

on

Artificial

Intelligence

and

Simulation

The

Diversity

of

Applications

pages

-LCB-

San

Diego

CA

Feb.

-LSB-

-RSB-

R.

Fagin

G.

Kuper

J.

Ullman

and

M.

Vardi

Updating

logical

databases

In

P.

Kanellakis

editor

Advances

in

Computing

Research

volume

pages

-LCB-

Plenum

Press

-LSB-

-RSB-

R.

Fagin

J.

Ullman

and

M.

Vardi

On

the

semantics

of

updates

in

databases

In

Principles

of

Database

Systems

-LRB-

PODS

-RRB-

pages

-LCB-

Atlanta

GA

Mar.

ACM

SIGACT

SIGMOD-SIGART

-LSB-

-RSB-

L.

Fari

nas

del

Cerro

MoLog

A

system

that

extends

Prolog

with

modal

logic

New

Generation

Computing

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

L.

Fari

nas

del

Cerro

and

A.

Herzig

An

automated

modal

logic

of

elementary

changes

In

P.

Smets

E.

Mamdani

D.

Dubois

and

H.

Prade

editors

Non-Standard

Logics

for

Automated

Reasoning

pages

-LCB-

Academic

Press

-LSB-

-RSB-

L.

Fari

nas

del

Cerro

and

A.

Herzig

Deterministic

modal

logic

for

automated

deduction

In

L.

Aiello

editor

European

Conference

on

Artificial

Intelligence

-LRB-

ECAI

-RRB-

pages

-LCB-

Stokholm

Sweden

Aug.

-LSB-

-RSB-

K.

Furukawa

A.

Takeuchi

S.

Kunifuji

H.

Yasukawa

M.

Ohki

and

K.

Ueda

Mandala

A

logic

based

knowledge

programming

system

In

International

Conference

on

Fifth

Generation

Computer

Systems

Tokyo

Nov.

-LSB-

-RSB-

P.-J

Gailly

and

J.-L

Binot

The

BIM-Probe

experiment

Position

paper

on

the

ICLP

Workshop

on

OOLP

June

-LSB-

-RSB-

J.-Y

Girard

Linear

logic

Theoretical

Comput

Sci.

-LCB-

-LSB-

-RSB-

D.

Harel

First-Order

Dynamic

Logic

volume

of

LNCS

Springer-Verlag

-LSB-

-RSB-

D.

Harel

D.

Kozen

and

R.

Parikh

Process

logic

Expressiveness

decidability

completeness

Journal

of

Computer

and

System

Sciences

-LRB-

-RRB-

-LCB-

Oct.

-LSB-

-RSB-

J.

Harland

and

D.

Pym

The

uniform

proof-theoretic

foundation

of

linear

logic

programming

-LRB-

extended

abstract

-RRB-

In

V.

Saraswat

and

K.

Ueda

editors

Intl.

Symposium

on

Logic

Programming

-LRB-

SLP

-RRB-

pages

-LCB-

The

full

paper

is

available

as

University

of

Edinburgh

Technical

Report

Nov.

-LSB-

-RSB-

M.

Henz

Term

rewriting

in

associative

commutative

theories

with

identities

Master

's

thesis

State

University

of

New

York

at

Stony

Brook

Dec.

Available

by

anonymous

FTP

from

duck.dfki.uni-sb

de

Z.

-LSB-

-RSB-

J.

Hodas

and

D.

Miller

Logic

programming

in

a

fragment

of

intuitionistic

linear

logic

-LRB-

extended

abstract

-RRB-

In

Logic

in

Computer

Science

-LRB-

LICS

-RRB-

pages

-LCB-

Amsterdam

July

IEEE

Computer

Society

Press

Full

paper

to

appear

in

Journal

of

Information

and

Computation

available

from

ftp.cis.upenn.edu

pub/papers/miller

-LSB-

-RSB-

Y.

Ishikawa

and

M.

Tokoro

Concurrent

object-oriented

knowledge

representation

language

Its

features

and

implementation

In

OOPSLA

Portland

OR

Sept.

-LSB-

-RSB-

Y.

Ishikawa

and

M.

Tokoro

A

language

with

multiple

paradigms

in

the

object

framework

In

Nineteenth

Annual

Hawaii

International

Conference

on

System

Sciences

volume

II

Software

Track

Honolulu

HI

Jan.

-LSB-

-RSB-

R.

Iwanaga

and

O.

Nakazawa

Development

of

the

object-oriented

logic

programming

language

CESP

Oki

Technical

Review

-LRB-

-RRB-

-LCB-

Nov.

-LSB-

-RSB-

R.

Jungclaus

Logic-Based

Modeling

of

Dynamic

Object

Systems

PhD

thesis

Technical

University

Braunschweig

Germany

-LSB-

-RSB-

R.

Jungclaus

G.

Saake

T.

Hartmann

and

C.

Sernadas

Object-oriented

specification

of

information

systems

The

Troll

language

Technical

Report

Informatik-Bericht

Technical

University

Braunschweig

Germany

-LSB-

-RSB-

R.

Jungclaus

G.

Saake

and

C.

Sernadas

Formal

specification

of

object

systems

In

S.

Abramsky

and

T.

S.

E.

Maibaum

editors

International

Joint

Conference

on

Theory

and

Practice

of

Software

Development

-LRB-

TAPSOFT

-RRB-

Volume

Colloquium

on

Combining

Paradigms

for

Software

Development

number

in

LNCS

pages

-LCB-

Brighton

UK

Apr.

SpringerVerlag

-LSB-

-RSB-

K.

M.

Kahn

Intermission

Actors

in

Prolog

In

K.

L.

Clark

and

S.

A.

Tarnlund

editors

Logic

Programming

pages

-LCB-

Academic

Press

-LSB-

-RSB-

K.

M.

Kahn

Vulcan

Logical

concurrent

objects

In

E.

S.

Shapiro

editor

Concurrent

Prolog

Collected

Papers

volume

pages

-LCB-

MIT

Press

-LSB-

-RSB-

K.

M.

Kahn

Objects

-LCB-

a

fresh

look

In

S.

Cook

editor

European

Conference

on

Object-Oriented

Programming

-LRB-

ECOOP

-RRB-

pages

-LCB-

Nothingham

UK

July

-LSB-

-RSB-

K.

M.

Kahn

E.

D.

Tribble

M.

S.

Miller

and

D.

G.

Bobrow

Objects

in

concurrent

logic

programming

languages

In

OOPSLA

Portland

OR

Sept.

-LSB-

-RSB-

K.

M.

Kahn

E.

D.

Tribble

M.

S.

Miller

and

D.

G.

Bobrow

Vulcan

Logical

concurrent

objects

In

B.

Shriver

and

P.

Wegner

editors

Research

Directions

in

Object-Oriented

Programming

pages

-LCB-

Cambridge

MA

MIT

Press

-LSB-

-RSB-

M.

Kanovich

The

multiplicative

fragment

of

linear

logic

is

NP-complete

ITLI

Prepublication

Series

University

of

Amsterdam

-LSB-

-RSB-

M.

Kanovich

Horn

programming

in

linear

logic

is

NP-complete

In

Logic

in

Computer

Science

-LRB-

LICS

-RRB-

pages

-LCB-

Santa

Cruz

CA

June

IEEE

Computer

Society

Press

Also

University

of

Amsterdam

ITLI

Prepublication

Series

-LSB-

-RSB-

H.

Katsuno

and

A.

Mendelzon

On

the

difference

between

updating

a

knowledge

base

and

revising

it

In

J.

Allen

R.

Fikes

and

E.

Sandewall

editors

Knowledge

Representation

and

Reasoning

-LRB-

KR

-RRB-

pages

-LCB-

Boston

MA

Apr.

-LSB-

-RSB-

F.

Kesim

and

M.

Sergot

On

the

evolution

of

objects

in

a

logic

programming

framework

In

ICOT

editor

Fifth

Generation

Computer

Systems

-LRB-

FGCS

-RRB-

pages

-LCB-

-LSB-

-RSB-

R.

kowalski

Database

updates

in

event

calculus

Journal

of

Logic

Programming

-LRB-

-RRB-

-LCB-

Jan.

-LSB-

-RSB-

R.

Kowalski

and

M.

Sergot

A

logic-based

calculus

of

events

New

Generation

Computing

-LCB-

-LSB-

-RSB-

D.

Lugiez

and

J.

Moysset

Complement

problems

and

tree

automata

in

AC-like

theories

In

P.

Enjalbert

A.

Finkel

and

K.

Wagner

editors

Proceedings

STACS

volume

of

Lecture

Notes

in

Computer

Science

pages

-LCB-

Springer

Verlag

Feb.

Available

by

anonymous

FTP

from

duck.dfki.uni-sb

de

Z.

-LSB-

-RSB-

J.

Malenfant

G.

Lapalme

and

J.

Vaucher

Coherent

state

changes

for

logic

programs

Research

report

LITP

RXF

Equipe

mixte

LITP/RXF

Jan.

-LSB-

-RSB-

S.

Manchanda

Declarative

expression

of

deductive

database

updates

In

Principles

of

Database

Systems

-LRB-

PODS

-RRB-

pages

-LCB-

ACM

SIGACT-SIGMOD-SIGART

-LSB-

-RSB-

S.

Manchanda

and

D.

Warren

A

logic-based

language

for

database

updates

In

J.

Minker

editor

Foundations

of

Logic

Programming

and

Deductive

Databases

Los

Altos

CA

Morgan

Kaufmann

Publishers

-LSB-

-RSB-

F.

G.

McCabe

Logic

Objects

International

Series

in

Computer

Science

Prentice-Hall

-LSB-

-RSB-

J.

Meseguer

A

logical

theory

of

concurrent

objects

In

ECOOP/OOPSLA

Ottawa

Ontario

-LRB-

SIGPLAN

Notices

-LRB-

-RRB-

-LCB-

Oct.

-RRB-

-LSB-

-RSB-

J.

Meseguer

Rewriting

as

a

unified

model

of

concurrency

In

CONCUR

Intl.

Conf

on

Concurrency

Theory

number

in

LNCS

pages

-LCB-

Amsterdam

Aug.

Also

Technical

Report

SRI

International

Feb.

-LSB-

-RSB-

J.

Meseguer

Conditional

rewriting

logic

as

a

unified

model

of

concurrency

Theoretical

Computer

Science

-LRB-

-RRB-

-LCB-

Also

Technical

Report

SRI

International

Feb.

-LSB-

-RSB-

J.

Meseguer

Multiparadigm

logic

programming

In

Third

Intl.

Conf

on

Algebraic

and

Logic

Programming

pages

-LCB-

Volterra

Italy

Sept.

-LSB-

-RSB-

J.-J

C.

Meyer

and

R.

J.

Wieringa

Actor-oriented

system

specification

with

dynamic

logic

In

S.

Abramsky

and

T.

S.

E.

Maibaum

editors

International

Joint

Conference

on

Theory

and

Practice

of

Software

Development

-LRB-

TAPSOFT

-RRB-

Volume

Colloquium

on

Combining

Paradigms

for

Software

Development

number

in

LNCS

pages

-LCB-

Brighton

UK

Apr.

Springer-Verlag

-LSB-

-RSB-

G.

Mints

Resolution

calculus

for

the

first

order

linear

logic

Journal

of

Logic

Language

and

Information

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

V.

Pratt

Process

logic

In

Principles

of

Programming

Languages

-LRB-

POPL

-RRB-

pages

-LCB-

Jan.

-LSB-

-RSB-

M.

Rusinowitch

and

L.

Vigneron

Automated

deduction

with

associative

commutative

operators

Research

Report

Institut

National

de

Recherche

en

Informatique

et

Automatique

-LRB-

INRIA

-RRB-

May

Available

by

anonymous

FTP

from

duck.dfki.uni-sb

de

pub/ccl/inria-lorraine

AC

deduction.ps.Z

-LSB-

-RSB-

D.

Sacca

B.

Verdonk

and

D.

Vermeir

Evolution

of

knowledge

bases

In

A.

Pirotte

C.

Delobel

and

G.

Gottlob

editors

Advances

in

Database

Technology

-LRB-

EDBT

-RRB-

number

in

LNCS

pages

-LCB-

Vienna

Austria

Mar.

Springer-Verlag

-LSB-

-RSB-

E.

Shapiro

and

A.

Takeuchi

Object-oriented

programming

in

Concurrent

Prolog

New

Generation

Computing

-LCB-

-LSB-

-RSB-

T.

Tammet

Proof

strategies

in

linear

logic

Technical

Report

Programming

Methodology

Group

Chalmers

University

of

Technology

University

of

Goteborg

Accepted

to

Journal

of

Automated

Reasoning

Available

from

ftp.cs.chalmers.se

-LSB-

-RSB-

T.

Uustalu

Combining

object-oriented

and

logic

paradigms

A

modal

logic

programming

approach

In

O.

L.

Madsen

editor

European

Conference

on

Object-Oriented

Programming

-LRB-

ECOOP

-RRB-

pages

-LCB-

June

-LSB-

-RSB-

D.

Warren

Database

updates

in

pure

Prolog

In

Fifth

Generation

Computer

Systems

pages

-LCB-

ICOT

-LSB-

-RSB-

C.

Welsch

and

G.

Barth

Reasoning

objects

with

dynamic

knowledge

bases

In

J.P.Martins

and

E.M.Morgado

editors

Fourth

Portuguese

Conf

on

Artificial

Intelligence

-LRB-

EPIA

-RRB-

pages

-LCB-

Lisbon

Portugal

Sept.

-LSB-

-RSB-

R.

J.

Wieringa

A

formalization

of

objects

using

equational

dynamic

logic

In

C.

Delobel

M.

Kifer

and

Y.

Masunaga

editors

Second

International

Congress

on

Deductive

and

ObjectOriented

Databases

-LRB-

DOOD

-RRB-

number

in

LNCS

pages

-LCB-

Munich

Germany

Dec.

Springer-Verlag

-LSB-

-RSB-

M.

Winslett

A

model

based

approach

to

updating

databases

with

incomplete

information

Transactions

on

Database

Systems

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

M.

Winslett

Updating

Logical

Databases

volume

of

Cambridge

Tracts

in

Theoretical

Computer

Science

Cambridge

Univerity

Press

-LSB-

-RSB-

K.

Yoshida

and

T.

Chikayama

A'UM

stream

object

relation

In

OOPSLA

New

Orleans

LA

-LRB-

SIGPLAN

Notices

-LRB-

-RRB-

-RRB-

-LSB-

-RSB-

K.

Yoshida

and

T.

Chikayama

A'UM

a

stream-based

concurrent

object

language

New

Generation

Computing

-LCB-

-LSB-

-RSB-

C.

Zaniolo

Object-oriented

programming

in

Prolog

In

International

Symposium

on

Logic

Programming

pages

-LCB-

Atlantic

City

Atlanta

Feb.