Principles

Kokirhi Futatsugi,

of OBJ21

Joseph A. Goguen, Jean-Pierre Jouannaud3, and Josk Meseguer

SRI Intctnational,

Menlo Park CA 94025

and
Center fnt t.hc Study of Language and Information, Stanford University 94305

1 Introduction

0~12 is a functional programming language with an

underlying formal semantics that is based upon equational
logic, and an oprtationnl semantics that is based upon
rewrite rules. Four clsssrs of design principles for 01352 ate
discussed briefly in this inttoduct,ion, and then in mote
detail brlnw: (1) motlulntizntion and patnmcteriantion; (2)
subsorts; (3) implcmcntnt.ion IcBchniquc>s;and (4) inlrtaction
and flexibility. WC also lrace C)II.l history, current shtus,
and future plans, and give n fairly comp1rl.c OnJ
bibliography. blast rxnmplc codr hns n-ct,unlly bcbcnrun on
out currclnt OI%.JZintcrprc,t (r.

tcquirtlmrnt.s
that actual modules must satisfy before they
can be meaningfully substituted. This can prevent many
subt,lc bugs. An unusual feature of ORJ2 is the commands
that it provides for modifying and combining program
modules; thus, (a form of) program transformation is
ptovidcd wit,hin t,he language itself. A key principle here is
the systemat,ic use of module expressions
for describing
and cresting
compIcx combinations of modules; see Section
2.5. This provides a level above that of conventional
programming
Isngun.ges,
in which previously written code
is dc>sctibrd by theories, and also is manipulated by module
cxprc*ssions
to product new code.

1.X Modules

1.2 Subsorts

and Generics

!I key ORJ? principle is the systclmntic use of pnrnmot.rtizrd

(gcnctic) modules. Encapsulating trlntrd code mnkrs it
more rrusablr, and grnetics at? rvon more tcusablP, since
thry can br tuned for a vnrirty of npplicat.ions by
choosing differcsnt patamrtrr valurs; motrovrt, debugging,
ruain(c*nancc, tradnbilitp and portability nrr nil rnhnnccd.
The interface drclarations of OIL12 genetics arc not purely
syntactic, likr Adas4; .mstcnd, they may cnnt.ain srmant.ic
Supported

OD.IZis strongly typcd5. As in many other languages, users

csn

Government

(Ada

0-89791-l47-4/85/001/0052

some

(tccovety),

pntt.inlly

inheritance

(in

vcty

operations,

Aowevct,

s0rt.s

contain

(or

thus
OBJ2
are

also permits
contained

the

defined
sense

operations,

and

of object-oriented

see Section 3. In addition, it permit.s us to

simple

1.3 Implementation

and

elegant

code

for

standard

ADTs

like

Techniques

Thr current implcmrntation is s Maclisp

intetptcter
rmploying sevrral novrl techniqurs for cffirirnt t,rtm
trwriting, including forms of tnil recursion, hnsh-coded
structure sharing (see S&inn 4.4), a.nd usrt defined buittins (see Section 4.5). The task of implementing OBJ? has
been greatly eased by our Command lntetprct.er Generator
(ClG), essentially a powerful application generator for
interactive mrnu-driven systems; see Section 4.1. The CIG

Joint

Permission
to copy without fee all or part of this material is granted
provided
that the copies are not made or distributed
for direct
commercial
advantage,
the ACM copyright
notice and the title of the
publication
and its date appear, and notice is given that copying
is by
permission
of the Association
for Computing
Machinery.
ho copy
otherwise,
or to republish, requires a fee and/or specific permission.

O1984 ACM

and

Lists, Stacks and Tables, as shown below.

BP 239, 54506 Vandoeuvre-les-Nancy

while on lcavr at SRI and CSI.1.

4Ada is a registered trademark

of the U.S.
Program
Office) and is defined by 171.

that

multiple

programming);

l-1-4 Umtwmo,
Sakura, Niihari,
performed
white on leave at SRI.

GRIN, Campus Scientilique.

Cedex, France; work performed

sorts
ADTs.

handling

wtitx

Laboratory,
work

own

defined

in) othcts. This supports a implc yet powerful fntm of

polymorphism,
as well #asexception (error) definition and

in part by

Elrctrotechnical
lbaraki 305. Japan;

t,hcir
user

USP~S to dcclste

Office of NWR! Ikwarch

Cnntracl
No.
N00014-82-C-0333,
National
Science Foundation
Grant No.
MCS8701380
and a gift from the Syrlcm Development
Foundation.
2

introduce

supporting

5
Hereafter
we gencralty use the word .sort
instead of .lype,
Wing to avoid confusion among Ihe many different
ways that type
has been used (major exceptions
are use or the word typechecking
and of the phrase sbst:act
data type?. abbreviated
ADT).

$00.75

52

allows a strict separation of ODJ2shigh level interactive

syntax from t.he functions that actually do the work, and
also helps bring up prototypes very rapidly, facilitating
experiments with ODJ2ssyntax and semantics without
having to reimplement a complex interactive system. An
interesting methodological point is our use of OBJ to design
the new implementation. We specified the database and
the rewrite rule engine in both OOJl and OBJ2, and we also
specified the interface between these two major
components (but not in OBJ2). It was instructive to debug
our OBJ2 design on a real example. It seems doubtful that
we could have implemented such a complex and novel
system in one year without using such techniques.
1.4 Interaction

2.1 Objects:

and Flexibility

obj BITS is
erhding
NAT .
sorts Bit Bite
ops 0 1 : -> Bit .
.
op nil : -> Bite
_,_
:
Bit
Bits
-> Bite .
OP
op length: Bite -> Nat .

var B : Bit .
vat S : Bite .
eq: length nil = 0 .
eq : length B . S = inc length

Users can define their own abstractions, wit.h any desired

syntax, and then use these abst,ractions as if they were built
in; in fact, users can even give efficient implementations in
the underlying Lisp. OBJs mixfix (or .distfix.) syntax
permits prefix, postfix, infix, outfix. (as in < x 3 or
I A I), and most generally, distributed fix operat,ions with
keywords and arguments in any desired order
(if then-elee-f i is non-trivially mixfix). In addition to
efficient implementation, user definable built-ins can also
provide sophisticated l/O packages, such as window
management, if the underlying hardware supports it.
(Section 4.5 gives more detail on built-ins.)
Modules

and Semantics

olws
basic c*llhly is the object,
which is a module
(possibly psr:~mrt~+cd) c,ncnpsulating cxccutabfe code;
ohjrcts gcnrralfy introdtlcc
new sorts of data and new
opc!rat.ions upon that (131.3.An object. hns three main parts:
(t ) a header, conta.ining its name, parameters, interface
rrquircmcnts, and importctl motl~~lclist.; (2) a signature,
declaring its new sorts, subsort rc*lnt.ionships, and
operations; and (3) a body, containing its code, consisting
of equations and sort constraints (t.hrsc are descrihcd in
Section 3.1). The following BITS object introduces two
new sorts Bit and Bite (for Bit lists) with scme relevant
opcrat.ions; these fists have a S-expression-like syntax with .
and nil. Ot3J2keywords and keysymbols are in italics.

OBJ2 is highly inaeractive and flexible. Program entry is

driven by st*ructured menu choice, rather than by keyword
entry and subsequent pa.rsing. All syntactic a.nd many
semantic errors are detected at pr0gra.m entry time; the
user is then given a diagnostic message and a chance to try
ag3in. The OR.& interpreter provides much more help than
most compilers even attempt. Impfemcnting this principle
is greatly aided by the CIG.

Syntax

S .

endo

Each line in this ex:tmple begins with an OBJ2 keyword.

The first line with keyword obj gives the name BITS of the
object. T11csecond line indicates that the built-in object
NAT (for natural numbers) is imported by BITS. The
keyword ezleuding
indicates that a certain static check
is performed (see Section 2.2 for more detail). The ops tine
declares the two Rit constants, the next op line declares the
empty string nil, the next a #cons operation (it adds a
Dit to some nits) with dot syntax, and the next a length
oprration using the sort Nat from NAT. An operation
de&ration in 01352consists ol: a form, indicating the
dist,rihution of keywords and arguments (underbars indicate
argument ptacc*x);art arity, which lists argument sorts; and
CIcoarity, which is tfle output sort. Iinally, variables of
sorts Bit and Bite arc declared nnd used in equations
which give semantics for the length function.

and Generice

The only t.op level OBJ2 entities are modules (which are
either objects or theories) and views (which relate theories
to modules, see Section 2.4); objects contain executable
code, while theories contain noncxccutabfe assertions.
Thus, executable code and nonexecutable assertions are
both modularized, and are c!osely integrated with each
other. Moreover, the mathematical semantics of theories
and objects is elegantly unified since both are data
theories in the sense of [lS]; there is not space for details
here, but the essential intuition is that the notion of theory
generalizes to permit regarding certain subtheories as
objects (i.e., they have initial interpretations) while others
may have any interpretation.

OnJ?s b,asir user-level naming conventions are as follows:

r~~odulesmust have globally unique names; sort names must
be unique within thrir module, and may be qualified by a
module name for disnmbigua1 ion; a.n operation name
consists of its form, arity and coarity, and (in a future
implementation) may be qualified by a module name; note
t,hat sort names used in n&y and coarity can be qualified
by module.
OJ!JZcode is execut.rd hy intrrprcting equations as rewrite
rules: the fcfthnnd side is rcgardrd as a pattern to be
matched within 311cxprc>ssion(vnriahlfs can match any

53

subexpression of appropriate sort); when a match occurs,

the subexpression matching the lefthand is rcwrhtcn to the
corresponding substit,ution inst.ance of t.he righthand side,
This process continues unt.il there are no more matches;
then t.he expression is said to be reduced or in normal
form. Writing
eval lrngth 329 . 668 . nil ende
at OBJZs top level causes calculation of the reduced form 2
using the rules in BITS.

defined in an imported module do not occur as topmost

symbols on the leftha.nd side of a new equation; it can only
bc used for objects; and it supports separate compilation,
since a given operation is defined once and for all by the
module that declares it, and can therefore be computed
from just the information in that module. musinga does
not guarantee anything, it just copies the imported module.

The Church-Rosser and termination properties imply that

expressions will always have unique reduced forms; we have
found that experienced programmers usually write rules
that satisfy these properties. Term rewriting may seem a
specialized computational paradigm, but in fact it is
completely gcncral: any computable function over any
computable data types can be so realized [I, 21. This
generalizes to operations t.hat are associative, commutative,
idempotent and/or have an identity [35]; then
implcmrntation is by matching modulo the given operation
attributes.

Modules group together the data and operations used for

parbicular problems such a.ssorting, matrix manipulation,
or graphics. Parameterized modules maximize reusability
by permitting .tuning. to fit a variety of applications. For
exa.mple, using (italicized) square brackets to separate the
module name from parameters, SORTIN# might sort lists
over any ordered set X, and MATRIX/n,R] might provide the
usual nxn matrix operations for scalars from R. The
parameter X of SORTINGranges over (partially) ordered
sets, i.e., sets with an irreflcxive (i.e., X < X is false)
transitive rclsbion. The parameter n of MATRIX ranges over
natural numbers, while R ranges over rings6 . Thus, OBJ2
supports semnntic interface requirements, whereas Adas
purely synt,actic interfaces cannot exclude actuals that
would produce unexpected or bizarre behavior. An OBJ2
module interface is described by a requirement
theory,
giving both syntax and axioms for the interface, with an
object being an admissible actual only if it satisfies the
axioms. The requirement theory for SORTINGis given by

2.3

mathematical semantics is socalled initial algebra

semant.ics (L4S) 128). IAS provides a standard
interpretation characterized by the properties of: (1) having
,no junk, meaning that all data values are denoted by
terms in the available operat,ion symbols; and (2) having
*no confusion., meaning that two terms denote the same
data value if and only if they can be proved equal (with
standard equational reasoning) from the given equations 151.
ODJ2s

Parameterleed

th POSET is
BOOL .

protecting

2.2 Hierarchy

Objects and Theories

sort Elt

of Modules

op
c
: Elt Elt -> Baa1 .
var;EF.'
E" : Elt .
eq : E < E = false
.
ceq : E < E" = true
if(EcEmdE
<Egg)

OBJZmodules can import othrr modules in three different

ways, usingm ) l protecting
and ezlendingm.
These
define three different restrictions on prcservcd properties of
imported modules, and thus define t.hrcc corresponding
partial orders (i.e., hierarchies) among modules. The using
hierarchy is the most gcncral, and embeds the other two.

endth

code for SORTINGis given in Section 2.5 below.)

More simply, here is the requirement theory for an
interface that only requires designating a sort from an
actual (with no axioms):
(08J2

An importation may fail to preserve the .no confusion*

property for the data clemcnts of the imported module.
For example, if we define the integers modulo 3 by
importing the integers (defined with 0 and succrsior e) by
adding the equation B I a 0 = 0, then the integer data
elements become confused. Similarly, the #no junk
property may be violated by operations that create new
data elements of imported sorts. For example, a
Bool-valued operation p can create .Boolean junk like
pf97) if a user gives incomplete equations for p.
Protecting. is the most restrictive relation, indicating that
both the .no confusion and .no junk properties are
preserved, and thus the imported module remains
unchanged. gEztcndingg is an easy-tocheck sufficient
condition for .no confusion*, requiring that the operations

Ih TRIV is

aoft Elt

endth

A parameterized object may have one or more requirement

theories; these are given in (italicized) square brackets after
its name. Since more than one parameter may be subject
to the sa.merequirements, different instances of the same

*Values witb addition, difference, multiplication, and constants 0, I,

such tbat addition and multiplication are associative and commutative
witb identities 0, 1 respectively, difference is inverse to addition, and
multiplication distributes over addition.

54

theory may be needed. For example, the following TABLE

object has two TRIV requirement theories, INDEX and VAL,
with Elt. INDEX and Elt .VAL their corresponding sorts,
thus illustrat,ing OBJzs qualified sort name convention:

scrond l <. is Iron) INT. lnstnnt.iating a paramctcrized

object with a view is indicnbcd by replacing the parameter
part with the view name. Thus, instantiating SORTINCP :;
POSET/t.o sort. intcgcrs in drscrnding order is indicated by
SORTINGPNT-DESC]. Not,e that there CM be more than one
view from n t.hcory to an actual; for example, another
instant.iation of SORTINGwith INT usrs a view tbat maps
l C. in POSETto the (irrcflrxivc) divisibility relation in INT.

obj TABLEPNDEX :: TRIV, VAL :: TRIV] ie

protecting
BOOL .
eorts Table ErrVol .
subsorts Elt .VAL < ErrVol .
OP emPt7 : -, Table .
op put : Elt .VAL Elt . INDEX Table -> Tablr .
op [ 1 : Table Elt. INDEX -> ErrVal .
op Gndyf : Elt.INDEX -> ErrVal
.
uars I 1 : Elt. INDEX .
zIar V : Elt.VAL .
rot T : Table .
eq: put(V.I,T)
[ I 1 =
if I == I then V else T C I I ii .
eq : empty [ I ] = undef (I) .

Sornc+imrs a view can ho inferred from a partial

dcsrript.ion, using syntactic similarities between the Cheery
and the object.. We call such a view description an
abbreviated view; it is a default view if abbreviated to
nothing 1171.For example, there is a default view of INT as
POSETthat maps Elt to INT and -- < .- Elt Elt -> Boo1
to the usual ordering on integers. To instantiate a
parameterized object with a default view, it suffices to

jbo

place t,he actual in the parameter part. Thus SORTINC/tNT]

sorts integers in ascending order; at the top level of OBJ2,
one might write
make SORTING-INT is SORTINC[INT/ endm
to create SORTING-INT. Intuitively, applying a
parnmctcrizcd object corresponds to editing its text
according to a view; but this is highly disciplined edit, with
a formal semantics like that of Clear [3, 4. In this
semantics, views correspond to theory morphisms, and
parameterized 0bject.s have an a.ssociatedtheory inclusion
from their requirement theory to their body. The pushout
of t.hat t,hcory inclusion along the view gives a new theory
whosc~initial algebra is the dcsircd instantiation (see (381
or 1181for the definition of pushout and 1181for more detail
on instanbiating parameterized objects).

In the first equation, .==, is a built-in equality such that

for two terms t, t of the same sort, t == t is true if they
have the same reduced form, and is f also otherwise. ==
implements the decision procedure for equality that is
associated with every object, and if-thrn_rlro_ii
is a
polymorphic conditional; both these are provided for every
sort by the built-in BOOLobject. The supersort ErrVal of
Elt . VAL accomodates error messagesfor Iookups of an
index where no value is stored (Section 3 explains sub- and
super- sorts). The form of the operation put has no
underbars, and therefore gets a standard parentheses-withcommas syntax, e.g., put(trur.13.Tl)
for
TABLE/INT,BOOL].
2.4 Views

2.6 Module

Instantiating a parameterized object means providing

actual objects satisfying each of its requirement theories.
In OBJ?, the actual objects are provided through viewa,
which bind required sorts and operations to those actually
provided (i.e., views map the sort and operation symbols in
the formal requirement theory to those in the actual
object) in such a way that all axioms of the requirement
theory are satisfied. For example,

Psramcterized programming permits building complex

modules from simple onc*sby applying parameterized
objects to actuals that are themselves instantiations of
other parameterized object.s and so on recursively; a similar
approach using module const.ruction operations occurs in
ODJT, OBJl and Ihe llisp specification language [lo, s].
OUJZmodule expressions arc like ordinary arithmetic
expressions, excrpt that t.heir arguments are modules rather
than numbers. For example, if ID is a built-in identifier
object, and if our library contains LEXp :: POSETj
providing lexicographic ordering for lists of elements from
an ordered set X, and also contains a parameterized sorting
ohjpct SORTINGP :: POSET/,t,hcn the module expression
SORTINGbEX/ID]] Icxicographically sorts lists of phrases
(i.e., lists of lists of identifiers). This expression uses several
default conventions. In LEX/ID/, a default view maps the
sort of Ws requirement theory to the sort Id and maps
its ordering to the builtin ordering for identifiers. Another
default view maps the sort Elt of SORTINGsrequirement
theory to the List sort of LEXDD], and maps its ordering to

view INT-DESC of INT as POSET ie

SOPSElt to Int .
vats X Y : Elt .
op : x < Y to : Y < x
endview

views INT with descending order 89 a poset; in op : X < Y

to : Y < X the first .<* is the one from POSETwhile the
Parameterized

Expressions

objects can also be seen aa object ger~eratom.*

%I ore generally,a view can map an operationin tbe tormal to an

cxptessionin the actual, M illustrated in the lollowing example.

55

framework of a.n initial algebra semantics:

1. Such ovcrloadcd operations provide a simple but
powerful polymurphism (see Sections 3.2 and 4.2).
2. Multiple inheritance in t,he sense of object-oriented
programming permits one sort to be a subsorl of two (or
more) others, cnch having various defined operations;
thrn all thtasc operations n.re inherited by the subsort.
For rxampl(a, WPmight have RsgiateredVehiclr
<
Vehicle n.nd RegieteredVehicle
< TaxedObject,
with say a speed operation on Vehicles and a taxamount opcrn.tion on TaxrdObj rcts; both these
operations a.rc inherited by items of sort,
RegieteredVehicle.
3. The familiar difficult.& for AnTs with operations
that are Wpnrt.in.l (such as tail for lists and pueh for
bounded stacks) disappear by viewing the operations as
t.otnl on t,hc right subsorts (see Scctzions3.1 and 3.2).
4. Errors can be treated in several styles, without need
for special syntactic or semantic error handling.
mcchn.nisms (see Sections 3.3 a.nd 3.1).

the lexicographic ordering from LEX/IDJ Here is the code

for SORTING(the parameterized LIST module is given in
Section 3.1):
obj SORTING BT :: POSET]is
eziending
LISTDT]
.
op sorted
: List -> Boo1 .
op eort : Liet
-> List .
.uurs E E : Elt .
Yar L L L : Liet .
eg : eorted(ni1)
= true .
eg : sorted(E)
= true .
c9 : eorted(E E L) =
(E == E or E < E) and eortsd(E
ceq : eort(L E L E L ) =
eort(L E L E L ) if E < E .
ceg : eort (L) = L i / eorted(L)
.

L) .

jbo

(At the time of writ.ing, OBJZs module instantiation facility

was not. quite up t,o this and the following example; but we
expect it will he by the time the pnpcr is presented.)
If M is a module expression, then M * (.,.) is another, with
sorts and operations renamed according t,o (...I. For
example, we rename the oprration sort of SORTINGto
lex-sort
in the module expression SORTINGMPD]] * (op
sort to lex-eort
1. hlndulc exprc&ons also occur in
definitions inside of modules, wit.11the effect of renaming
the principal sort of the module cxprcssion, as in
obj

3.1 Partial

Operationa

and Sort

Constraints

The following spcrification for a parameterized LIST object

introduces a subsort, NeLiet of nonempty lists to make the
(traditionally partial) head and tail operations total. Here
.assoc indicates that an operation is associative, and id:
nil' indicates that it has nil as an identity.

SYMROLTARLEia
ID .
INT .
:= STACKpmLE/ID, INT] +
(sort Int to Lot, serf Table to Layer)].

eztending
ezfending
dfn Env

LIST/% :: TRIV] ie
sorts NeLiet List .
subsorts
Elt < Nstist < List .
op nil
: -, List *
op
: NoList NeList -> NeList [assoc]
op--:
Liet Liet -> List [t18soc id: nil]
op 62
: NeLiet -> Elt .
op tail
: NeList -> Lirt
.
zrar L : NeList .
zInr E : Elt .
e9 : hradQ L) = E .
e9: tailCELl
=L
.

obj

jbo

sort of a module is the first new sort

introduced in it; or if there is none, the principal sort of its
first imported module, and so on rrcursivrly.) Replacing
the d/n
by ezfending
and renaming of sort Stack to
Env would yield the same operational semantics and
hierarchy of modules.
(The principal

jbo

3 Subeorta

A more subtle kind of part.ial operation is illustrated by

push in a hounded stack. Unlike LIST, where nonempty
list,s are genrrnted by concatenation, the stacks for which
pueh is ok have no natural expression as a set generated
by constructors (e.g., by pueh itself); but they can be
chn.ractcrizcd by the equational condition of having a
Iengt,h not exceeding the bound. Such characterizations are
called sort constraints in 0852 (the word declarations
ww used in 1151for the unconditional case) and have the
general form
as <Sort> : f (Xl,. . . ,Xn) if <Condition>
.

One sort of data is often contained in (or contains) another,

e.g., the natural numbers are contained in the integers,
which are contained in the rationals; then the sort Nat is a
subsort of Int, and Int is a subsort of Rat (or Int is a
supersort
of Nat, etc.), written Nat < Int < Rat.
hloreover, an operation may restrict to subsorts of its arity
and coarity and still be *the same. operation. For
example, each addition operation + : Rat Rat -> Rat,
-- +
.. Int Int -> Int, -+- : N&-Nat -> Nat is a
restriction of the preceding one. OBJ2s very flexible
subsort mechanism provides the following, all within the

9Parameterized objects provide yet another polymophism,

generic objects operations are available to all its instances.
56

since a

lhis defines a t r:msl:rtion

An initial algebra semantics for sort constraints k giVVn

in 1221and an operat.ional semantics is given in [26].
BOUNDED-STACK
uses the foliowing requirement theory
th NAT* is
proteclirq NAT .
op bound : -> Nat .
endfh

NAT.+is a somewhat subMe t.heory especially constructed so

that giving an interpretation of it corresponds exactly to
giving a nat,urnl number as interpretation of the constant
bound. Now the example:
obj BOUNDED-STACK/%
:: TRIV. Y :: NAT*] i8
8Ott8
N&tack
Stack ErrStack .
subsorts N&tack < Stack < ErrStrck
.
op empty : -> Stack
.
op pueh : Elt ErrStack
-> ErrStwk
.
-> Elt .
op top- : N&tack
OP POP- *. NeStack -> Stack .
op length : Stack -> Nat .
vat E : Elt ,
VW S : Stack

Assuming that the order-sorted equations in E are ChurchDossrr, it, turns out that new cquat.ions may have to be
ntldcd to E* in order to gctt an equivalent set of ChurchRossrr standard c~quations [2G]. Thus OBJ2 performs a
spcrializrd Knufh-Ucndix completion 10 on the equations
E*. ISvrn whcbnan operation hns hern declared associative
(or .zssoriat.ivc-ronlmutativo) for both a subsort s and a
supcrsort s, we can shill do rewriting modulo associativity
(or asso~iativily-comt~1~~tn.t.ivit.y)with the completed E+
using a st.andnrd associative (or associative-commutative)
rnat,ching algorithm 1261. Ilowevcr, the correctness of this
last. reduction is rather subtle, since the associativity
axioms at t,he two levels in&act with morphism equations
to grnrrnte additional equations having an associative
flavour.

us NeStack :
pu8hCE.S) i/ length(S)
< bound .
eq : lsngth(empty)
= 0 .
eq : length(push(E,S))
= inc length(S)
cq : top purh(E, S> = E .
eq : pop pueh(E, S) = S .

from 01~~s ordrr-sorted

algebra notation \15] to standard equational notation. In

PartiCUlar, if I< is a set of equations defining an OBJ2
object, we obtain a translation E* to which the above
equations have been added. There is an equivaIence
br~~wcrn Ulc class of order-sorted algebras satisfying E and
(1~ cl:lss of standard alg!+ras satisfying E* under which
the ir&ial algrbras of each class correspond 122). Thus we
can t.rnnslnte back and fort01 without losing information.
This translation involves mapping an overloaded operation
in t.h(sorder-sorted algebra (such as + above) to one of its
forms in the standard algrbrn (c.g., +e or +a). This
translat.ion is done by choosing the operation with the
smnllrst coarity such that the resulting expression, called
the lowest parse, is well-formed. Simple syntactic
conditions on signs.tures ensure uniqueness of lowest
parse 1261.

jbo

(This example has not been run since sort constraints

require subtleties in the parser that are not yet
implemented.) Overflow of such a stack during
computation produces a runtime parse error (see Section
3.3).

3.3 Error

3.2 Logic of Subsorte

Handling

and Recovery

It is witfcly atlmit.t.ecl that. handling crronrous and

mcaninglrss rxl>rrssiorls in an nlg&raic setting reduces to
hnrldling sl1bsort.sand partial operat.ions. However, quite a
numhcr of different approaches have been taken, including
the following:
1. Error Sorts -- providing special sorts in which to put
special error values:
a. Error Algebras -- our original approach [ 141involved
disjoint ok. and .error. sorts for each standard sort;
we have abandoned this approach and do not discuss it
further here, except. to note that it was implemented in
OBJT and OE3Ji.
b. Explicit Error Supersorts -- this is one of several
approaches supported by 0852; it involves a new
supersort of each standard sort; for example, Lirt (
ErrLitrt with tail : List -) ErrList and
tail(ni1)
= tailees where tailess is an error
messageof sort ErrLiet not of sort List.

Although subsorts are very expressive, their logic is very

simple, and indeed can be reduced to standard equational
logic (22, 261. This is both theoretirzdly and practically
important, since both standard algorithms for term
rewrit,ing and theorem-proving (e.g., the Knuth-Bendix
algorithm) and the large literature on algebraic data types
ran be applied without modification. In the OR52 system,
subsort notation is available at the user Icvcf, but is
translated into (lengthier) internal standard equational
forms. The key idea is to view a subsort pair s<s as a
unary opcrat,ion c8 s, : s-+s called a coercion from s to d.
Appropriate equations ensure that C~2 is injcctivc and that
the subsort relation is transitive. Also, whenever an
operation symbol (such as +*) is defined for both s and s
wit,h s<s, the following morphism equation expresses
that t,he results must be t,he same at, both levels,
c(J4 +s C,,J(Y) = CJX +s Y)
(.+s. and +s are new operation symbols for the two
levels.)

10

The usual problemsof orienting rules and ol non-termination do

no1 arise here.

57

2. Partial Operations - here operations are defined on

only part of what is normally considered their domain;
for example, toil is only defined for non-empty lists:
a. Partial Algebras -- here one attempts to generalize the
theory of abstract data types to algebras involving
partially defined operations; it has been found that the
mathematical theory is far more complex than one
would like, and we will not discuss this approach
further here.
b.Domain Subsorts - here one restricts operations to the
domain on which they are meaningful by defining a
subsort for this domain; for example, in OAJ? we could
define NsLiet < List to be the sort of non-empty
lists and then have tail : NeList -> List; 01352
also has sort constraints.
c. Sort Constraints -- th ese give the effect of partial
operations with domain defined by a condition, 89 in
the BOUNDED-STACK
example.
3. Recovery Operations -- these are operations from a
sort that, may contain errors to one that doesnt:
a. Retracts -- these are left inverses to coercions,
permitting contingent parsing of expressions which
would otherwise be ill-formed, IIS described below.
b. Error Handlers - more general recovery operations
than retracts are possible in OBJ2, but are not
discussed here.
The choice among the options supported by OBJ2 is largely
a matter of style and taste; moreover, certain of these
choices are very closely related to one another. For
example, OBJ2 automatically provides both a coercion and
a retract for every subsort pair; thus, both error supersorts
and domain subsorts have associated retracts. One
consideration in making a choice is what kind of explicit
error messagesare desired.

vindicated after reduction. On the other hand, the

expression
put (put (trur , 1, empty) t 2 I, 6.
put(falre,2,rmpty))
is also temporarily accepted by the parser as the term
put (fErna .nt .VIl undef (2) ,6, put (false, 2, empty) )
but since this is already reduced, it is returned 8s is, with
the retract operation serving as a very informative error
message. This kind of runtime typechecking, together with
the polymorphism provided by subsorts and parameterization, gives much of the syntactic flexibility of untyped
languages with all the advantages of strong typing.
4 Implementation

Principles

In trying to make OBJ2 convenient t0 use, easy to

implement, and fairly efficient, we have developed several
new implementation techniques.
4.1 Command

Interpreter

Generator

Given two files, one specifying command syntax and the

other containing basic system functions, the Command
Interpreter Generator (CIG) compiles a system interpreter.
The command specification is in effect a graph of menu
choices, given aa S-expressions that describe the command
hierarchy with associated function calls. Each command
has four pa.rts: open key, body, subcommand part, and
close key. For the POSETtheory in Section 2.3, the open
key Ih starts the theory creat#ion command, and en&h
closes it; its body is l POSET is; and its subcommand part
is a sequence of commands one level lower, given by the six
lines starting with protecting BOOL . . . For example, the
fourth of thrsc lines defines a new operation, with mop. as
its open key and < : Elt Elt -> Boo1 . . 8s its body;
both it(s subcommidpart
and its close key are empty.
The top level of OBJ2 can be seen as a single command
whose subcommand set contains object, theory, and view
commands; without using italics for keywords, this might
look as follows:

Let us now discuss retracts in more detail. Ill-formed terms

of the order-sorted algebra are translated to well-formed
terms of an extended standard algebra having new
operation symbols rs B called retracts that are associated

;;;OBJ2 top levrl

(0
0
0
(th-obj -vierkc>
0)

with each subsort pair s<s. The semantics of retracts is

given by new equations in ES expressing that coercions are
right inverses of retracts. Ill-formed order-sorted terms
that l might become well-formed after reduction get the
benefit of the doubt at parse time by using retracts to fill
gaps between actual sorts and required sorts. For example,
in the object TABLE/INT,BOOL/,the expression
put(put(true.l,empty)
C 1 1,6,
put(folee.2,rmpt~))
is temporarily accepted by the parser as the term
put(r Errval , Elt .val (put (true, 1, empty) C 1 31,
6,put(folse,2,empty))
.
Doubt arises since put (true, 1, empty) I 1 3 can be an
ErrVal value that is not an Elt.Val, but the expression is

command specification
;open keys
,*cl080 keys
;body part
;rubcommand procraring
;exit function

fa

;;;dubconunand specification
for top lrvrl
(th-obj -view&
;fn name for subcommand
0
;init
in for rubcommand
(prompt)
;prompt aprc
(* ((th theory)
;opm key8 for th coamand
(endt sndth ht) ;closr key8 for th command
The real OB2 syntax is more complex, since communication with
the reduction engine, file system, editor (Emacs),and Mac&p
evaluator also occur at the top level.

58

;theorJ name procseeing in

;eubcommand procrssing
in
;for thsory co-d
issit in for th conunand
(throry%er) 1
((obj ob object) ;opra keye for obj command
(ado jbo bo mdobj)
(th-name%c)
(th-perte%c IO

;close key for obj command

(obj-name-pm%) ;obj XIUfie/parUh procersng fB
(obj-part&
*) ;rubcommmd procerring
in
;for obj command
(obj rct%ex) 1
;rxit
in for obj command
((virr
~1)
;opon kayo for view command
(rndv rndvier
WV eodwv)
;cloee keys for virr command
(view-name-part&)
;visr nome part procrseng in
(View-part&
*);subcommand ptocesring
fn
;for

(vielw%rx) 1)
0)

; OIit
;fioal

view

in for
in for

command

Command
rubcommand

View

;;;subcormnand eprc for obj commando

(ob j -part&z
;fn name for thir
0
(prompt9
;prompt rprc
(* I..
((sort
rorttr 60) ;opm key for sort
0
* *.1
...
(fop operator operetion)
;open kryr for op
0
. . 11
( (VW vare)
;open keys for var
0
. . ,)
((09 equation)
;oprn krye for rq
0
. . .1
.I
0)

rubcommand

co-d

command
command
command

The first S-expression specifies the top level command,

while subsequent S-expressions specify its subcommand
parts. The GIG generates one Lisp function for each Sexpression in this sequence. The generated functions
combine with the basic functions that process body parts to
give a highly interactive interpreter. The system generates
an informative prompt and the user should then supply a
body or keyword. At each point in the interaction, the
menu of possible commands is automatically available.
The GIG also supports inputing bodies through
.prompt/reply.
interaction. (Unfortunately, there is not
room here for a detailed explanation of CIG syntax.)
12oBJ2 prompt8 with the scqucncc of previous open keys.

The prcsctnt OILI command structure only requires

choosing an arbit.rary sequence of subcommands from the
fixed subcommand srt of each command. However, a GIG
can in principle hnndle many other kinds of commandsubcommand control; in particular, t,he present CIG also
supports choosing just one subcommand from the
subcommand sot of a command. hote that there are
natural t,ranslnt.ions between the GIGs syntactic formalism
and more familiar BNF. The Appendix gives BNF synt.ax
for WJ?. Our GIG runs in Ma&p, but Thierry Billoir has
also implrmcnted it on the Symbolics 3600, providing
mousr-srnsitivc pop-up mrnus for command choice.
4.2 Parser
The 01152parser translates order-sorted expressions (the
Icft- and right-hand sides and conditions of equations, sort
expressions in sort const.raint.s, intcrmediat,e terms from the
rcduct.ion engine, and user queries) int,o sorted expressions
in standard We form, more specifically into S-expressions
of int,ernnl oprrnt.ion symhnls. For example, consider the
following
8orla Int Rat .
stlbaorls
Int < Rat .
OP-_ : Int Int -> Int
oP --.* . Int Int -> Int
op - : Xnt Int -> Int
op ;;cdOf_ond: Int Xnt
oP --*+ - Rat Rat -> Rat
oP --I* * Rat Rat -> Rat
oP -/_ : Int Int -> Rat
uurs A B C D : IBt .
var.3 X Y 2 : Rat .

[assoc comm/
[assoc comm 11
a
-> Int .
[aesoc comm]
[asaoc comm l]
.

where comm in italic brackets indicates that the operation

is commutative, and a number in italic brackets gives the
parsing precedence (operations without numbers have
prcccdrnce 0). The parser distinguishes + on Int from + on
Rat by decorating the operation with the sort, and we will
write +i and +r respectively (internal names for operations
are a bit more coinplex in the real implementation). The
coercion from Int to Rot and the retract from Rat to Int
are reprrscnted
by c\i\r and r\r\i
respectively; this
retract permits parsing a term with an Int operation
applied t,o a Rat expression. Then we have the foilowing
sample lowest parses:
1. A + B + C => (+i A (+i B C));
2.X+Y+Z=>
(+rX
(+rYZ));
(-BC))or((-hB)
0,
3. A - B - C=> (-A
a parse error since it is ambiguous;
4. A + B * C => (+i A (*i B C));
5. A + B + X => (+r (c\i\r
(+i A 8)) X); and
6. gcdOf A + B snd C / D
=> (gcdOf (+i A B) (r\r\i
U C D))).

A binary associat.ivc opcrntion is pnrscd as right

associative, where,as a similar nonassociative operation
would have an a.mbiguous parse, c.g., (l), (2), (3);
commutative declarations have no cffpct on parsing;
see [SS] for more detail. Operations of lowest precedence
are tried first at the top level of an expression (see (4)), and
t.he parser gives expressions t.hc lowest possible sort; thus, A
+ B is (+i A B) rather t.han (+r (c\i\r
A) (c\i\r
B)).
Possible retracts must he considrrcd in parsing exprrssions
to be reduced, e.g. (6) (see Section 3.2).

The OBJ2 database supports reusability of modules, Thus,

a parameterized module is reused by instantiating its
parameter theories with appropriate views, without
affecting the original module. A new module can also be
created by renaming, thus giving different names to sorts
and operations, and reusing most other parts of the old
module. Evaluating a module expression often requires
creating new modules with different sort names, operation
forms or parameter values. This is implemented by
representing modules as lambda expressions with their sort
names, operation forms, and parameter modules as
nrguments. By applying such lambda expressions, new
modules are efficiently created in the database. This
method is a.lso used to store already constructed modules
into files so that whole systems can later be reused.

The parser uses recursive descent backtracking, since it

may be necessary to try all possibilities in checking that
there is exactly one meaningful lowest parse; thus, parsing
can be expensive for complex expressions. The parser
stores partial results in tables to avoid redoing work. For
example, in parsing A + B l A + B * A + B, the parse of
B * A is stored and later looked up. This has a large effect
for expressions like A - A - A - A. The parser also stores
ambiguous expressions (those with several parses) and all
their parses in a table; it can then return a single result
indicating ambiguity, such as (*error*
A - A - A - A);
thus, we get
(1) (*error*
((((2) (*error*
((4.3 Database

A - A - A - A1
A (*error*
A - A
(-AA)
(-AA))
(*error*
A - A A - A - A) with
A (- A A))
(- A A) A)
and Module

4.4 Rewrite

ODJ2uses equations as rewrite rules, assuming that they

terminate and are Church-Rosser. Since rewriting can use
any combinat,ion of associative, commutative, identity and
idempotent pattern matching, the rewrite engine is
parameterized by the kind of rewriting used, by attaching
properties to both sides of each equation; then (for
example) commutative matching is used when a lefthand
side has a commutative operation. When a righthand side
is (for example) associative, its instances are put in normal
form, i.e., flattened. Each property has such a .normalizabion; systematic use of which greatly speeds up the
01351matching process implement,ed by Plaisted. OBJ2
rewriting is also parameterized by the Estrategy
of each
operation, a list of natural numbers telling the order to try
reductions. For example, if_thsn-alar-f
i has strategy
(1 0); the inil.ia.l 1 means first reduce the first subterm;
the following 0 means reduce at the top as long aa possible
aftcr that.

with parses
- A>)
A) A)
parses

Expression

Rule Engine

Evaluator

The OB.JZdat.abase has four kinds of identifiers: module

(theory or object) and view idcnt.ifirrs, sort identifiers,
operation identifiers, and equation identifiers. Modules and
views are basic units manipulated by the OBJZ language;
but sorts, operat,ions and equat.ions cannot be manipulated
without affecting modulrs since cvcry sort, operation and
equation belongs to some module. Since module and view
names are unique (Section 2.1), t,hcy can be used as
identifiers in the database. A modules parameter names
arc local, and are idcntifictl by internally created global
names. Since the sort names given by users are also local,
database sort idcnt,ificrs annotate the user sort name with
the module name. An operation identifier is annotated by
its form, its rank (t,he list of arity and coarity sorts), and
its module. Equation identifiers arc created from the top
operation of the lefthand side and a key to distinguish
equations having the same such operation. All information
that ma.y be needed later is retained in properties of these
identifiers. For example, all opcrat.ions belonging to a
module are retained as a property of t,he module identifier
under .m!ops , and the rxtend-hirrarchy structure of
modules is retained in a list of module identifiers on
m!extends. and m!extcnded. properties.

The rewrite engines top level function, Objval, determines

if a given term is already reduced by checking its
representation. If it is not, Objval checks if another
occurrence of the same term has already been computed
and stored in a hash table (used for results of computations
with top symbol having the l ~avcrun~ attribute, which
can be set by users). Of course, there may be collisions in
the hash table, in which case only the most recent
computation is retained. Finally, if the term must be
computed from scratch, Reduce is called by Objval with
the Estrategy of the top operation, and the starting term
is overwritten by the reduced one, to avoid recomputing
shared subterms. Depending on the Estraiegy, Reduce
splits into the following cases:
1. If the strategy is empty, then Reduce is called again
with the remaining occurrences where reductions must be
performed, as indicated in 3.d. If there are no such
occurrences, then Reduce returns that result.

60

2. For bon-empty Estrategies, the first ocurrence of the

strategy is processed and if it is not 0, then Objval is
called wit.h the corresponding subterm 8s argument
before reducing the whole term with the remaining part
of the strategy.
3. Finally, if the first occurrence is 0, then reduction
st,arts at the top, and the following are tried successively:
a. Coercion and coercion-retract rules, to keep terms in
normal form; e.g., terms to be reduced must be lowest
parses of some OBJ2 expression for the Church-Rosser
property to hold. These rules are not in the database,
but the rewrite engine knows their form and uses
them. The rewritten term will be in normal form
because coercions and retracts first reduce their
argument,s; hence, no recursive call is needed here.
b. Morphism rules, as discussed in Section 3.2, are also
used to keep terms in normal form, and are built into
the rewrite engine. If one applies, then Objval must
be called recursively, since a new operation is on top.
c. Built-in operations, defined by equations whose
righthand side is Maclisp code; see Section 4.5. The
result of a built-in operation is either a built-in
constant or else an OBJ2 expression that must be
parsed snd then evaluated recursively by Objval.
d. Finally, standard rules are attempted according to
their topmost lefthand side operation. Actually, these
rules are stored into two different data structures:
those that dont change the top operation are tried
first until none can be applied, using a ring that is
searched for new rules to apply aa soon as the current
rule fails. This efficiently implements tail recursive
calls; for example, the second rule of
eq : x+0=x.
eq : x + 6 Y =

2. JGstratcgirs need not he given by the user, but instead

can be automatically gcbncratcd at parse time using
simple heuristics t.hat try to avoid useless computations:
for example, + in the nhove cxnrnplc has strategy (2 o
11, using tho heuristic that a binary operation with no
rules t,hat look inside its first argument should begin by
cvalunting its second argument, and then reduce at the
top; the final 1 causes comp1ct.ereduction of non-ground
terms with + remaining on top; note that left reducing a
ground t,c?rmwith + on fop is usrlcss, since + is
completely defined with respect to a set of constructors.
On the other hand, retracts, coercions and most built-in
operations (the exception being cont.rol structure built-ins
like if-then-elee-fi)
have a call-by-value strategy that
reduces their subterms before trying to reduce at the top.
3. Estrategies do not implement an optimal strategy, if
one exists, but they are very efficient in practice: the
ratio between attempted matches and sucessful matches
is usually around 2/3, which is really impressive. In
particular, use of Estrategies and the tail recursion rinrr
makes a much larger difference in the efficiency of term
rewriting than dors the choice among data structures as
discussed in [32].
4. As an apphati(Jn
of theory in 1261,we can reduce
expressions that are not well-formed at parse time but
may have a well-formed normal form. This occurs, for
example, if WCtry to 11s~e 8 e 8 0 / a 0 0 as an
integcbr (0 is z(ro and o is the successor function)
somcwhcre in a term. It is apparent.ly a rational, but
since integers are a subsort of rationals, it may really be
an intcgcr after reduction. This problem is handled by
the retract operations mentioned in Section 3.3 as
follows: a retract from rat,ionals to integers is put on top
of the above subtcrm to indicnt.e t,he hoped-for sort.
Then, at reduction time the subt,erm reduces to a B 0
with a coercion to the rationals since the result is
supposed to be rational. Thrn a retract-coercion rule is
applied to delet,e these two extra operations, permitting
the rest of t,lrc computation to proceed. (261prr~~es
soundness and completeness of this techniqllr: if the
starting term cannot be parsed correctly but it.s
equivalence class contnins CI correct term, then the
normal form will be computed, assuming that the initial
rules are Church-Rosspr.
5. Last, but not le.?st, all this w.zs easy to implement and
provides well-!;trurturcd code, since choice of the next
subterm t,o reduce is not part of f hc rewrite engine itself.

(I X) + Y .

has + on top of both sides; so an expression with + on

top is repeatedly matched with the second rule until it
fails. When the ring has been searched without
finding a rule that applies, the remaining rules are
applied until one is found (or fails). If there is a
match, then a new operation is on top, and Objval is
called again; otherwise, the term cannot be reduced
any more on top. However, reduction may now be
possible on some immediate subterms because of
reductions by rules in the ring: these are the new
reductions that must be tried once the current strategy
has been exhausted.
Let us emphasize some points:
1. Estrat.pgies may lead to a complex search of the tree,
very much like what happens with evaluation of parse
trees by attribute grammars.

4..6 User Defined Built-Ins

A difficult problem for logic programming is to maintain
purity and yet provide cfficicncy and input/output; most

61

languages simply compromise purity. OB.12 adopts an

approach in which logical purity can be maintained (at
some cost in specification and theorem proving) or can be
compromised (if needed to satisfy the practical
requirements of a programming project). This approach
permits users to create new built-in functions or objects,
by implementing them in the underlying Lisp; they are also
documented with OBJ2 syntax and (optionally, but
encouraged) with equations. This approach provides OBJ2s
built-in objects for Booleans, integers, natural numbers,
identifiers, lists, arrays, etc. Thus, we get the efficiency of
compiled Lisp along with a precise mathematical
desrript.ion of what these data types do. Although the
algebraic specification is not executed, it can be useful for
documentation and theorem proving. Built-ins are also
useful for implementing I/O, including graphics. Built-ins
will later permit compiling9 operations defined by
equations into Lisp functions (as in Rope and ML) without
changing the rewrite engine, since these operations can be
seen as .built-in once their Lisp code is generated. Note
that a built-in operation may produce a built-in constant or
an OBJ2 expression. Thus, built-in definitions must
combine 0852 and Lisp syntax.

semantics. In 1972, the basic principle of .initial algebra

semantics (IAS) was developed, and in 1973 appIied to the
denotation4 (or .attribute) semantics of context-free
languages [13]; this was later [29] related to abstract
syntax, the Scott-Strachey approach, and structural
induction. By 1973 we realized that concrete data types
could usefully be viewed as many-sorted algebras [12]. In
1974, IAS was applied to ADTs by ADJ [28]. Two
awkward limitations of this first approach were addresed
by subsequent work: parameterization and errors
(including partial operations). In 1977, the Clear
specificntion language [3] was introduced as a way of
structuring complex specifications into simpler parts; a
major principle here is the use of so-called colimits. of
specifications, following earlier work on structuring genera1
systems [ll, 191. Clears powerful and precise mechanism
for parameterized specifications inspired OBJ2s generic
module mechanism. 1977 a.lso saw the first draft of OBJ, in
connection wit,h a proposed algebraic semantics for
errors [14]. This language was subsequently implemented
by Joseph Tardo, first as OBJO and later as OBJT [25]. The
original motivation for this work was the observation that
algebraic specifications published in the literature were
very often wrong, so that some way of testing them was
needed. The theorem that links rewrite rules with
equat,ional ADT specifications using IAS is that the normal
forms of a set of terminat.ing Church-Rosser rewrite rules
give the initial algebra of the rules viewed as a set of
ejua.tions; this result is the theoretical basis for OBJ and
appears for example in [16]. David Plaisteds OBJl [27] is a
significant improvement of OBJT, including his clever
efficient implemcnt,ation of associative-commutative
rewriting, and many powerful and convenient interactive
features, such as a spelling checker. The current OBJ2
implementation has profited from all of this.

In order to verify t,bat a given Lisp implementation of a

built-in does in fact satisfy its specification (a standard
OBJ2 object), we need a precise not.ion of implementation. The literature includes a number of these 128,81,
and the following seems adequat.c for the present purpose
(it dqes not take account of states, for which see 139, 20);
bowmer, the current OBJ2 does not have objects with
states). Let A and B be objects with signatures C and C,
reachable over t,heir respective signatures. Then an
implementation
of A by B is a view v from the theory
with signature C and no equat,ions to the theory with
signature C and no equations (in the general sense
mentioned previously, that mnps C-opera.t.ions to Cexpressions) such that there is a (necessarily unique and
surjective) C-homomorphism t,o A from the C-reachable
part of B viewed by v as a C-algebra; in symbols,
reacbC(BV)dA. It can be proved that implementations in
this sense compose.
5 Pa&,
OBJ2

Present

Two improvements of OBJ2 to be implemented soon are: a

.univcrsal. sort U -- this will give a tremendous flexibility
in programming style, since it supports arbitrary mixtures
of typed and untyped code; and a new value * for E
strategies, indicating lazy evaluation -- this will support
infinite data structures and processes. A more distant
improvement will permit states in objects, following the
theory in [ZO].

and Future

is a fruition of fifteen years research in algebraic

13This paragraph is not intended to survey all work related to OBJ
or even all work contributing directly to OBJ;instead, it only sketches
the direct line of development. Any survey of closely related work
would have to include the important work OCZilles 1421and
Guttag 1301on ADTs, the work on Hope by Burstall, MacQueen,
Sanella and others IS], the work of Hoffman and ODonnell 1311on
rewrite rule languages, and the survey of Huet and Oppeo 1341on
rewrite rule theory. (391 surveys a good deal of relevant work in
algebraic semantics.

62

Although we originally thought of OUJ = a vehicle for

testing algebraic ADT specifications, we soon came to think
of it as a general purpose executable specification language,
suitable for rapid prototyping [Zl] and for programming
language semantics [24]. However, our recent more
efficient implementations and the expected arrival of
parallel machines Iead us to regsrd OBJ as an ultra high
level programming language that can be executed
extremely rapidly on suitable a.rchitectures, and that is
especially suitable for fifth generation. applications (such
as expert systems). OBJ is a logic programming language
in the sense that its basic statements are equations, and the
interpretation of those equations (in a,lgebras representing
the underlying data types) agrees with the logic of
equations plus the initiality principle. Moreover, a basic
assumption of the rewrite rule implementation (rmmely, the
Church-Rosser property) implies that multiple processors
can be set to work concurrently, without the user having to
explicitly schedule them or their interactions, with the final
result guaranteed independent of the order of execution;
also any available nonoverlapping rewrites can bc carried
out simultaneously. Recent work 1231on Eqlog explores
combining the equational logic (and other powerful
features) of OBJ with the Horn clause logic (and other
powerful features) of Prolog. Two other research directions
that we hope to pursue for rewrite rule languages are
graphical programming methods and parallel architectures.

2. Bprgstra, J. A., and Tuckrr, .I. V. Algebraic

Specifications of Computable and Semicomputahle Dat.a
Structurcls. To appear in Theoreticnl Computer Science;
24~~.

3. Burstall, R. M. and Gogucn, J. A. Putting Theories

togc>t.hcrto Make Specificat,ions. froceedinga, Fi/lh
International
Join.t Conference on Artificial
Intelligence
5 (1877), 1045-1058.
4. Burstall, R. M., and Goguen, J. A. The Semantics of
Clear, a Specification Language. In Proceedinga of the
1979 Copenhagen 1Vinter School on Abetract Software
Specification,
Springer-Verlag, 1980, pp. 282-332.
6. Burstall, R. M. and Goguen, J. A. Algebras, Theories
and Freeness: An Introduction for Computer Scientists. In
fioceedings,

NATO

Summer

School,

6. Burstall, R. M., MacQueen, D. and Sanelia, D. HOPE:

an Experimental Applicative Language. In Conference
Record of the 1980 LISP Conference, Stanford University,
1080, pp. 138143.
7. United States Department of Defense. Reference
Manual for the Ada Programming Language. ANSI/MILSTD-1815 A.
8. Ehrich, H.-D. On the Theory of Specification,
Implementation and Parameterization of Abstract Data
Types. Journal of the Association for Computing
Machinery
29 (1982), 206227.

Future work will also explore integration with the theorem

proving capabilities of the REVE system [37], and
compilation techniques for rewrite rule based languages.
Integration with REVE will permit OBJ2 to perform many
validation checks on objects, including completeness checks
using Thiels algorithm 1411and consistency checks using
the socalled inductive completion algorithm [33]. On the
other hand, 0852 will provide REVE with a powerful
language for specifying complex hierarchical theories,
supporting the hierarchical inductive completion
algorithm. of [36]. In turn, this algorithm will permit
checking OBJZS protecting property. These techniques can
be used to prove that actuals satisfy the requirement
theories of parameterized modules. Thus, OBJ and REVE
together constitute a very powerful environment that
integrates programming, specification and verification.
There is little doubt that this will raise interesting new
issues in each of these fields.

9. Futatsugi, K. and Okada, K. Specification Writing as

Construction of llierarchically Structured Clusters of
Operators. In Proceedings, IFIP Congress 80, IFIP Press,
1980, pp. 287-282.
10. Futatsugi, K. and Okada, K. A Hierarchical
Structuring Method for Functional Software Systems. In
Proceeding8,
Engineering,

6th International

Conference

on Software

IEEE Press, 1982, pp. 393402.

11. Goguen, J. Mathematical Foundations of

Hierarchically Organized Systems. In Gfobal System8
Dynamics, E. Att,ingcr, Ed.,!% Karger, 1971, pp. 112-128.
12. Goguen, J. A. Some Remarks on Data Structures.
Abstract of 1973 Lectures at Eidgenoschiche Technische
Ilochschule, Zurich.
13. Goguen, J. A. Semantics of Computation. In
Proceedinga, First International
Symposium on Category
Theory Applied to Computalion
and Control, University of
Massachusetts at Amherst, 1974, pp. 234249.

6 References

14. Goguen, J. A. Abstract Errors for Abstract Data

Types. In IFIP Working Conference on Formal

1. Bergstra, J. A., and Tucker, J. V. A Characterization

of Computable Data Types by Means of a finite equational
specification method. In Automata, Languages and
Programming,
Seventh Colloquium,
J. W. de Bakker and
J. van Leeuwen, Eds., Springer-Verlag, 1980, pp. 76-90.
%tt

1981 Marktoberdorj

Reidel, 1982.

Description

of Programming

Concepts, MIT,

1877.

15. Goguen, J. A. Order Sorted Algebra. UCLA

Computer Science Department,1978.Semantics and Theory
of Computation Report No. 14.

alsotbe IotaSystcm 1401.

63

26. Goguen, J., Jouannaud, J.-P. and Meseguer, J.

Operational Semantics of Order-Sorted Algebra. Summary
presented at JFIP WG2.2, Boston, June 1984. Submitted
for publication.

16. Goguen, J. A. How to Prove Algebraic Inductive

Hypotheses without Induction: with applications to the
correctness of data type representations. In Rrxeeding~,
5th Conference on Automated Deduction, W. Bibel and
R. Kowalski, Eds., Springer-Verlag, Lecture Notes in
Computer Science, Volume 87, 1980, pp. 356373.

27. Gogurn, J. A., Meseguer, J., and Plaisted, D.

Progra.mming with Parameterized Abtract Objects in OBJ.
In Theory and fiactice of Soffware Technology, D. Ferrari,
M. Bolognani and J. Goguen, Eds., North-Holland, 1983,
pp. 163-193.

17. Goguen, J. A. Parameterized Programming:

Transactions
on Software Engineering
SE-IO, 5
(Sept.ember 1984), 5!28-543.0riginally appeared,
Proceedings, Workshop on Reusability
in Programming,

28. Goguen, J. A., Thatcher, J. W. and Wagner, E. .Au

Initial Algahra Approach to the Specificat,ion, Correctness
and Implemrnte.tion of Abstract Data Types. Current
Trends in Progrnmming Methodology N (1978),
80-149.Origind version, IBM T. J. Watson Research
Center Technics1 Report RC 6487, October 1976.

edited by Biggerstaff, T. a.nd Cheatham, T., ITT, pages

138-150, 1983; also, revised version as Technical Report
CSLI-84-9, Center for the Study of Language and
Information, Stanford University, September 1984.
18. Goguen, J. A. and Burstall, R. M. Introducing
Institutions. In Proceedings, Logics of Programming
Workshop, E. Clarke and D. Kozen, Ed.,Springer-Verlag,
1984, pp. 221-256.

29. Gogucn, J. A. , Thatcher, J. W., Wagner, I;. and

Wright, J. B. Initial Algebra Semantics and Continuous
Algebras. Journal of the Association for Computing
Machinery
24, 1 (January 1977).

19. Goguen, J. A. and Ginali, S. A Categorical Approach

to Genrral Syst.emsTheory. In Applied General Systems
Research, G. Klir, Ed.,Plrnum, 1978, pp. 257-270.

30. Gutta.g, J. V. The Specification and Application

to
Programming
of Abstract Data Types. Ph.D. Th.,
University of Toronto,1975.Computer Science Department,
Report CSR.G-59.

20. Gogucn, 1. A. and Mcsrgurr, .J. (Jniversal

Realization, Persistrnt Interconnection and Implcmcntation
of Abstract Modules. In Proceedings, 0fh International
Colloquium on Automata, Languages and Programming,
Springer-Verlag, 1982.

31. Iloffman, C. M. and ODonnell, M. J. .Programming

wit.b Equations. ACM Transactions on Programming
Languages and Systems 1, 4 (1982), 83-112.

21. Goguen, J. and Mesrguer, J. l R,npid Prototyping in

the OBJ Exccut.able Specification Lnngu:lge: Software
Engineering
Notes 7, 5 (1982), 75-84Procccdings of Rapid
Prot.otyping Workshop.

32. Hnffmnn, C. and ODonnell, M. .Pattern Matching

in Trees.. Journal of the Association for Computing
Machinery
20, 1 (1984), 68-95.
33. IIuet, G., Hullot, J.M. .Proofs by Induction in
Equational Theories with Constructors.. Journal of the
Association
for Computing Machinery 25, 2 (1982),

22. Goguen, J. and Mescgorr, J. Order-Sorted Algebra:

Partial and Overloaded Operations, Errors and Inheritance.
SRI International, Computer Scicncc Lab,l984.Given as
lecture Logic of Subsorts and Polymorphism at Seminar
on Types, Carnegie-Mellon Univcrsit.y, June 1983.

239-266.
34. Huet, G. and Oppen, D. Equations and Rewrite
Rules: A Survey. In Formal Language Theory:
Perspectives and Open Problems, R. Book., Ed.,Academic
Press, 1980.

23. Gogucn, J. a.nd Mescguer, .J. Equality, Types,

Modules and (Why Not?) Generics for Logic
Programming.. The Jovrnal of Logic Programming
I, 2
(1984), 179-21O.Also appears in froceeriings, 1984 Logic
Programming
Symposium, Upsala, Sweden, pp. 115-125;
and Report CSLI-845, Center for the Study of Language
and Information, Stanford University, March 1984.

35. Jouannaud, J.P. and Kirchner, H. Completion of a

Set of Rules Modulo a Set of Equations, In Roceedings,
f Ith Symposium on Rinciples of Bogramming
Languages, ACM, 1984, pp. 83-92.

24. Goguen, J. A. and Parsaye-Ghomi, K. Algebraic

Denotational Semantics using Parameterized Abstract
Modules. In Formalizing
Programming
Concepts, J. Diaz
and I. Ramos, Eds., Springer-Verlag, Peniscota, Spain,
1981, pp. 292-309.

36. Kirchner, H. A Genera1 Inductive Completion

Algorit,hm and Application to Abstract Data Types. In
Proceedings,

7th Conference

on Au tomated Deduction,

Springer-Verlng, 1984, pp. 282-302.

37. I,c~scn.nnr,P. Computer Experiments with the REVE
Term Rewriting Systems Generator. In Proceedings,
Symposium on Principles of Rogramming Languages,
ACM, 1983.

25. Goguen, J. A. and Tardo, J. An Introduction to OBJ:

A Language for Writing and Testing Software
Spcncifications. In SpeciJiration of Reliable Software,
IEEE Press, 1979, pp. 179-189.

38. Mac Lanp, S.. Categories for the Working

Mathematician.
Springer-Verlag, 1971.

64

<DefineCmd> ::= (df,dfn,define)

<SortKey>
:= <ModExp> .
--- the principal
eort of the module <ModExp>
--- ie renamed to <SortKey>, i.e.
--df SortKey := ModExp
--- ie equivalent
to
--a
extending <ModExp> *
--to <SortKey> ).
.( sort <PrincipalSort>

40. Nakajimn, R. and Yuasa, T.. The IOTA

Progrumming
Syslem. Springer-Vcrlag, 1083. Lecture
Notes in Computer Science, Volume 160.
41. Thicl, J.J. St.op Losing Slwp over 1ncornplct.c Dat,n
Type Spccificalioo. In Proceedinga, 1 (th Symposium on
Principles of frogramming
Lungangerc, ACM, lf184.

GortsCmd?

<>SortKsy>...-3

OBJ2

copcmd> ::= ~op.operator.operation)

-> <sort>
<OpForm> : {{<Arity>))
cDpCloee~
<OpsCmd> ::= ~ope,operatore,operations~
->
<OpForm>. . . : {{<Arity>3)
<sort> <OpCloee>
<Arity> ::= <Sort>...
<OpClose> : := . 1 <[,at,attr,attribute)
<Attribute>...
CI,ta,enda,endat,rttaI
<Attribute>
::= assoc
1 aseociative
I comm I commutative
I identity:
<OpForm>
I id: <OpForm>
1 idmpt I idcm I idempotent
I <Strategy> I <Precedence>
I saveruns I t3r
<strategy>
: := (I <NatNum> . . . ) D
<Precedence> ::= <IntNum>
<NatNumB ::= --- 0 12 3 .
<IntNum> ::= --- 0 1 -1 2 -2 3 . . .

BNF

This appendix does not use italics for keywords, nor tloc~sit
give syot,ax for cvnluation, file m;~nipul:r.t.ion, etc.
Syntactic

Conventions

nonterminal
symbole
alternative
separator
exp.. .
one or more expll
one or more exps separated by .;
:&;
zero or one exp. except that {{.)3
indicates
either period or <cr>
choice of exactly one of el,...,en
631 ,...,sn3
exp in one line; i.e.,
no <cr>
{-wt..3
parentheses for syntactic
grouping
(sxp)
of expressions
.(. .).
parentheses ae terminal symbols
--- text <cr> comment
<Name>
I

Theory

and Object

<<.33

<SubsorteCmd> ::= Gwbsorte.se)

(<Sort>. . . <) . . _
f <Sort>...->
<<.33
<Sort> : := <SortKey> I <SortKey>.<ModName>
<ModName> ::= <ThName> 1 <ObjName>

42. Zillcs, S. Absbact Specification of D&a Typrs.

Report 1IQ, Computation Structurw Croup, MIT,lQ74.

7 Appendix:

::= {sort,eorts,so)

Commands

<ThCmd> : := {th,theorv> - UhNamO is

Cendt,endth,ht)
<ThPart>...
<ProtectingCmd> I GxtendingCmd>
<ThPart> :
cUeingCmd> I <DsfineCmd>
<Sort&W
I <SubsortsCmd>
<VariableaCmd> I <SortConetrCmd>
<OpCmd> 1 <OpsCmd> 1 <EqCmd>
<CondEqCmd>

<VariableeCmd>

::=

{var,vare>

<VarName>...

: <Sort> {{.I>

<SortConetrCmd>

::= as <Sort> :
<SortExp> if cCondition>
<SortExp> ::= <SimpleTerm>
--- <SimpleTerm> is an expression composed Only
--- of one operator symbol and variable8
(e.g..
--- push Elm to Stack, add Elm to Set, etc.)
<Condition> ::= <Term>

<ObjCmd> ::= {obj,ob,object)

<ObjName>
{(<ParameterDecl>))
is
<ObjPart>. . . Cendo,jbo,bo.endobj)
<ParameterDecl> : := [ (<ParameterKey>
: : <ThName>), . . . 1
<ObjPart> ::= <ThPart> I <BuiltinEqCmd>

<EqCmd> ::= {eq,equation)

{{<Sort>))
:
<Lb> = <Rhs>
ii<Sort>))
<BuiltinEqCmd> ::= {beq.bq,builtineq)
: <Lhe> = <Sexp>
<CondEqCmd> ::= Ccq,ceq,condeq) {{<Sort>))
:
cLhs> = <Rhe> if <Condition> .
cLhs> : := <Term>
<Rhe> : := <Term>

<ModExp> .
<ProtectingCmd> ::= {protecting,pr)
cModExp> .
<ExtendingCmd> ::= {rxtsnding,rx)
<UeingCmd> ::= GW.ng,us) <ModExp> .

65

aakecmd> : := bke,mk3
-------

cObjNams> la

<ModExp> Iendm, endmk, km, okam)

make CObjNameB ir <Mod&p> l ndm

ir squvolent to
obj CObjNames ir wing

<ModExp> . rndo

View Commands
<ViewName> of cObjName>
<ViewCmd> ::= <vr,vier3
a8 <ThName> ie CVierPartCmd>...
~endv,endvier,endvr,wv3
<VierPartCmd> ::= <SortPairCmd> I <VariablerCmd>
I <OpExpCmd>
<Sort> to <Sort>
<SortPairCmd> ::= <ro,eort3
<OpExPairCmd> ::= ~op,operator,operation3
{<<Sort>33 : <opExp> to
<<<Sort>33 : <Term> .
copFxp> : ;= <SimpleTerm>
Module

Expressions

QdodExp, : := <ModName>
I <ModName> [ <ModExp>, . . . ]
I <ModExp> <Rename>
I (04odExp> +) . . . <ModExp>
<Rename> ::= * . ( (<RenamePartCmd><{. 33) . . . 1
--- Ml + M2 * (op f to g)
--- should be parsed as
--- Ml + 042 * cop f to g))
CRenamePartCmd> ::= <SortPsirCmd> I <OpPairCmd>
<SortRenameCmd> ::= {so,rort3
<Sort> to <SortKey>
<OpRenameC!md>::= Cop,operator,opsration~
<Operator> to (~<OpF~rm>)~
<Operator> : := (<OpForm>) l
I l (.. (.<OpForm>) :
<(<Arity>33
-> <CoArity>8)
---------

Note that the following

nanterminals
are not
defined here: <ThName> <ObjName> <VienName>
<ParameterKey> <SortKey> <OpForm> <Term>
<SimpleTerm>

66