cunniff%hpda@hplabs.HP.COM (08/05/87)
Submitted by: cunniff%hpda@hplabs.HP.COM (Ross Cunniff)
Comp.sources.games: Volume 2, Issue 18
Archive-name: adl/Part01
[The following note is from the author. -br]
[[This posting and the ten following are the first netwide
distribution of ADL. ADL stands for Adventure Definition Language,
and consists of a compiler, an interpreter, and several sample
games.
ADL is being released as free software - NOT as shareware or
as public domain software. We are granting the right to freely
redistribute ADL as long as no profits are realized by such
distribution.
Please let me know how you like ADL!
- Ross Cunniff
...{hplabs,ucbvax}!hpda!cunniff
cunniff%hpda@hplabs.HP.COM
cunniff%hpda@hplabs.arpa
]]
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of archive 1 (of 11)."
# Contents: README MANIFEST adlcomp adlrun adlrun/Makefile include man
# man/doc.aa misc samples samples/aard samples/demos samples/mpu
# util
# Wrapped by billr@tekred on Tue Aug 4 16:27:34 1987
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f README -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"README\"
else
echo shar: Extracting \"README\" \(1364 characters\)
sed "s/^X//" >README <<'END_OF_README'
XThis directory contains the sources to ADL, including some sample games.
XAll sources in this directory and subdirectories are:
X
X Copyright 1987 by Ross Cunniff
X All Rights Reserved
X
XYou may distribute the UNMODIFIED sources to ADL, provided that this
Xnotice is retained. Send modifications to:
X
X UUCP: ...{hplabs,ucbvax}!hpda!cunniff
X ARPA: cunniff%hpda@hplabs.ARPA
X USMAIL: Ross Cunniff
X 636 La Grande, #7
X Sunnyvale, CA 94087
X
XAcceptable modifications may be included in future releases.
X
X
XADL stands for Adventure Definition Language. It is a superset,
Xwith greatly enhanced capabilities, of an older language named DDL.
XDDL was originally written in 1981 by Michael Urban, Chris Kostanick,
XMichael Stein, Bruce Adler, and Warren Usui, all of the UCLA Computer Club.
XFor documentation, consult the ADL Programmer's Reference (which may
Xbe obtained by sending a self-addressed 9x12 manila envelope and $1.00
Xto cover postage to the above USMAIL address).
X
XThis directory contains the following files and subdirectories:
X
X adlcomp -- sources for adlcomp
X adlrun -- sources for adlrun
X include -- include files for ADL
X man -- Man pages for ADL
X misc -- sources for adldebug and adltouch
X samples -- some sample ADL specifications
X util -- utility routines for ADL
X
XIn order to make the executable programs, simply type "make" in this
Xdirectory.
END_OF_README
if test 1364 -ne `wc -c <README`; then
echo shar: \"README\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f MANIFEST -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"MANIFEST\"
else
echo shar: Extracting \"MANIFEST\" \(3740 characters\)
sed "s/^X//" >MANIFEST <<'END_OF_MANIFEST'
X File Name Archive # Description
X-----------------------------------------------------------
X COPYRIGHT 11 Copyright notice
X MANIFEST 1 This shipping list
X Makefile 10
X PORTING 10 General compilation and porting info
X README 1
X adlcomp 1 sources for adlcomp
X adlcomp/COPYRIGHT 11
X adlcomp/Makefile 10
X adlcomp/README 11
X adlcomp/adlcomp.c 4
X adlcomp/adlglob.c 11
X adlcomp/adllex.c 7
X adlcomp/adlmisc.c 2
X adlcomp/adlmsg.c 9
X adlcomp/adlobj.c 8
X adlcomp/codegen.c 10
X adlcomp/compdict.c 9
X adlcomp/predef.c 8
X adlcomp/routcomp.c 8
X adlrun 1 sources for adlrun
X adlrun/COPYRIGHT 11
X adlrun/Makefile 10
X adlrun/README 11
X adlrun/adlarith.c 11
X adlrun/adldwim.c 9
X adlrun/adlerr.c 10
X adlrun/adlfuncs.c 6
X adlrun/adlintrn.c 10
X adlrun/adlmach.c 1
X adlrun/adlmacro.c 10
X adlrun/adlmiscr.c 11
X adlrun/adlobjr.c 10
X adlrun/adlrun.c 8
X adlrun/adlscrn.c 9
X adlrun/adlspec.c 8
X adlrun/adlstr.c 9
X adlrun/adltrans.c 2
X adlrun/rtdict.c 5
X adlrun/rtglob.c 11
X adlrun/rtlex.c 8
X adlrun/rtparse.c 7
X include 1 include files for ADL
X include/COPYRIGHT 11
X include/Makefile 11
X include/README 11
X include/adlcomp.h 10
X include/adldef.h 10
X include/adlprog.h 9
X include/adlrun.h 9
X include/adltypes.h 10 edit this for your os and compiler
X include/builtins.h 9
X include/virtmem.h 11
X include/vstring.h 11
X man 1 documentation and man pages for ADL
X man/adlcomp.6 10
X man/adldebug.6 3
X man/adlrun.6 10
X man/doc.aa 1 adl.doc part 1
X man/doc.ab 3 adl.doc part 2
X man/doc.ac 2 adl.doc part 3
X misc 1 sources for adldebug and adltouch
X misc/COPYRIGHT 11
X misc/Makefile 11
X misc/README 11
X misc/adldebug.c 6
X misc/adltouch.c 11
X samples 1 sample ADL specifications
X samples/COPYRIGHT 11
X samples/Makefile 11
X samples/README 11
X samples/aard 1
X samples/aard/COPYRIGHT 11
X samples/aard/Makefile 11
X samples/aard/README 11
X samples/aard/aard.adl 11
X samples/aard/constant.adl11
X samples/aard/locales.adl 5
X samples/aard/locnames.adl10
X samples/aard/objects.adl 8
X samples/aard/objrouts.adl 6
X samples/aard/routines.adl10
X samples/aard/transit.adl 7
X samples/aard/verbs.adl 9
X samples/demos 1
X samples/demos/COPYRIGHT 11
X samples/demos/Makefile 6
X samples/demos/README 11
X samples/demos/actdemo.adl 6
X samples/demos/baby.adl 9
X samples/demos/multi.adl 7
X samples/demos/tiny.adl 10
X samples/mpu 1
X samples/mpu/COPYRIGHT 11
X samples/mpu/Makefile 11
X samples/mpu/README 11
X samples/mpu/constant.adl 10
X samples/mpu/locales.adl 3
X samples/mpu/locnames.adl 10
X samples/mpu/mpu.adl 11
X samples/mpu/objects.adl 4
X samples/mpu/routines.adl 7
X samples/mpu/transit.adl 7
X samples/mpu/verbs.adl 4
X samples/standard.adl 5
X util 1 utilities for ADL
X util/COPYRIGHT 11
X util/Makefile 11
X util/README 11
X util/mytime.c 10
X util/virtmem.c 9
X util/vstring.c 10
END_OF_MANIFEST
if test 3740 -ne `wc -c <MANIFEST`; then
echo shar: \"MANIFEST\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test ! -d adlcomp ; then
echo shar: Creating directory \"adlcomp\"
mkdir adlcomp
fi
if test ! -d adlrun ; then
echo shar: Creating directory \"adlrun\"
mkdir adlrun
fi
if test -f adlrun/Makefile -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"adlrun/Makefile\"
else
echo shar: Extracting \"adlrun/Makefile\" \(2560 characters\)
sed "s/^X//" >adlrun/Makefile <<'END_OF_adlrun/Makefile'
X# The include directory
XINC = ../include
X
X# The utilities directory
XUTL = ../util
X
X# Places relating to the shar command; B is the base from which to unpack;
X# D is the directory into which to unpack.
X# AR = shar -c -v
XAR1 = post -c -v -p 4 17
XAR2 = post -c -v -p 5 17
XB = ..
XD = adlrun/
X
X# Where adlrun will reside, after make install
XBIN = /users/cunniff/bin
X
X# Flags for CC
XCFLAGS = -I${INC} -O
X
X# Flags for the linker - you may need to change -lcurses to -ltermcap
X# or -ltermlib.
XLIBS = -lcurses
X
X# Flags for lint.
XLFLAGS = ${DFLAGS} -DLINT -I${INC} -C
X
X
X# Utilities used by adlrun
XUTIL = ${UTL}/virtmem.o ${UTL}/vstring.o ${UTL}/mytime.o
X
X# Headers used in all adlrun source files
XHDRS = ${INC}/adltypes.h ${INC}/adlprog.h ${INC}/adldef.h \
X ${INC}/adlrun.h ${INC}/builtins.h ${INC}/virtmem.h \
X ${INC}/vstring.h
X
X# The adlrun object files
XOBJS = adlarith.o adldwim.o adlfuncs.o adlintrn.o \
X adlmach.o adlmacro.o adlmiscr.o adlobjr.o \
X adlrun.o adlspec.o adlstr.o adltrans.o \
X rtlex.o rtparse.o adlerr.o adlscrn.o \
X rtdict.o rtglob.o
X
Xall : adlrun
X
Xshar : adlrun1.shar adlrun2.shar
X
Xadlrun1.shar : README COPYRIGHT Makefile adlarith.c \
X adldwim.c adlerr.c adlfuncs.c adlintrn.c \
X adlmach.c adlmacro.c adlmiscr.c adlobjr.c \
X adlrun.c
X ( cd ${B} ; ${AR1} \
X ${D}README ${D}COPYRIGHT ${D}Makefile ${D}adlarith.c \
X ${D}adldwim.c ${D}adlerr.c ${D}adlfuncs.c ${D}adlintrn.c \
X ${D}adlmach.c ${D}adlmacro.c ${D}adlmiscr.c ${D}adlobjr.c \
X ${D}adlrun.c \
X > ${D}adlrun1.shar )
X
Xadlrun2.shar : adlscrn.c adlspec.c adlstr.c adltrans.c \
X rtdict.c rtglob.c rtlex.c rtparse.c
X ( cd ${B} ; ${AR2} \
X ${D}adlscrn.c ${D}adlspec.c ${D}adlstr.c ${D}adltrans.c \
X ${D}rtdict.c ${D}rtglob.c ${D}rtlex.c ${D}rtparse.c \
X > ${D}adlrun2.shar )
X
Xinstall : adlrun
X strip adlrun
X cp adlrun ${BIN}
X chmod 755 ${BIN}/adlrun
X
Xlint :
X lint ${LFLAGS} *.c ${UTL}*.c
X
Xclean :
X rm -f ${OBJS} core adlrun1.shar adlrun2.shar adlrun
X
Xadlrun : ${OBJS} ${UTIL}
X cc -o adlrun ${OBJS} ${UTIL} ${LIBS}
X
Xadlerr.o : adlerr.c ${HDRS}
X
Xadlarith.o : adlarith.c ${HDRS}
X
Xadldwim.o : adldwim.c ${HDRS}
X
Xadlfuncs.o : adlfuncs.c ${HDRS}
X
Xadlintrn.o : adlintrn.c ${HDRS}
X
Xadlmach.o : adlmach.c ${HDRS}
X
Xadlmacro.o : adlmacro.c ${HDRS}
X
Xadlmiscr.o : adlmiscr.c ${HDRS}
X
Xadlobjr.o : adlobjr.c ${HDRS}
X
Xadlrun.o : adlrun.c ${HDRS}
X
Xadlscrn.o : adlscrn.c ${HDRS}
X
Xadlspec.o : adlspec.c ${HDRS}
X
Xadlstr.o : adlstr.c ${HDRS}
X
Xadltrans.o : adltrans.c ${HDRS}
X
Xrtlex.o : rtlex.c ${HDRS}
X
Xrtparse.o : rtparse.c ${HDRS}
X
Xrtdict.o : rtdict.c ${HDRS}
X
Xrtglob.o : rtglob.c ${HDRS}
END_OF_adlrun/Makefile
if test 2560 -ne `wc -c <adlrun/Makefile`; then
echo shar: \"adlrun/Makefile\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test ! -d include ; then
echo shar: Creating directory \"include\"
mkdir include
fi
if test ! -d man ; then
echo shar: Creating directory \"man\"
mkdir man
fi
if test -f man/doc.aa -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"man/doc.aa\"
else
echo shar: Extracting \"man/doc.aa\" \(42626 characters\)
sed "s/^X//" >man/doc.aa <<'END_OF_man/doc.aa'
X
X
X
X
X
X
X
X
X
X The ADL Programmer's Reference Manual
X
X
X Tim Brengle
X Ross Cunniff
X
X Hewlett-Packard Company
X Cupertino, California 95014
X
X
X
X ABSTRACT
X
X ADL (which stands for "Adventure Definition
X Language") is a programming language and run-time
X environment designed for the convenient implemen-
X tation of Adventure-like games. This document
X describes ADL and is intended for the use of a
X programmer who wishes to create such a game.
X
X The authors would like to acknowledge the
X tremendous influence of the earlier language DDL
X from which ADL was derived. DDL was created in
X 1981 by Bruce Adler, Chris Kostanick, Michael
X Stein, Michael Urban, and Warren Usui, then
X members of the UCLA Computer Club. For informa-
X tion on DDL, please consult the document "A Brief
X Description of UCLA Dungeon Definition Language
X (DDL)" written by the creators of DDL and avail-
X able from the University of California.
X
X
X
XJune 19, 1987
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X
X
X
X
X
X
X The ADL Programmer's Reference Manual
X
X
X Tim Brengle
X Ross Cunniff
X
X Hewlett-Packard Company
X Cupertino, California 95014
X
X
X
X1. Introduction
X
X Computer games have existed for nearly as long as com-
Xputers have existed. One of the most popular computer pro-
Xgrams of all time is Adventure. In Adventure, the player is
Xplaced inside a world which exists only in the memory of the
Xcomputer (and the mind of the player). The player interacts
Xwith this world by means of English-like sentences. Objects
Xthat the player finds may be taken, opened, closed, tasted,
Xthrown, and otherwise manipulated.
X
X Previously, most programmers attempting to write their
Xown Adventure-like game have been bogged down by such
Xtrivial details as implementing a parser for player input,
Xproperly responding to the player's commands, and dealing
Xwith the passage of time. ADL is intended to relieve the
Xprogrammer of such worries and to allow the programmer to
Xconcentrate on the important details of the imaginary world.
XThe following is a short excerpt from the play of a game
Xwhich was written in ADL:
X
X Red room.
X You are in a large room which is illuminated by a bright red glow.
X Exits lie to the east and south.
X > Go east.
X Green room.
X You are in a smallish room which is illuminated by a pleasant green
X glow. The only exit is to the west.
X There is a robot here.
X > west
X Red room.
X > s
X Blue room.
X You are in a tiny room which is barely illuminated by a dim blue
X glow. There is an exit to the north, and you seem to make out
X something on the floor. There is a button on the wall. Above the
X button is a sign that reads:
X
X DANGER!
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 2 -
X
X
X HIGH VOLTAGE!
X
X > n
X Red room.
X > e
X Green room.
X You can see:
X a robot
X > Tell the robot "Go west then south. Push the button then go north."
X "Sure thing, Boss."
X The robot exits to the west.
X
X Notice that this script demonstrates powerful features
Xnot present in many other Adventure-like games. This docu-
Xment will describe the utilities and "tricks" necessary to
Xwrite games such as the above.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 3 -
X
X
X2. ADL Data types
X
X Structured data types are the heart of any structured
Xlanguage. ADL is not lacking in structured data types. It
Xis through the proper definition of specific instances of
Xthese data types that the ADL programmer defines a scenario.
XNote that all data types in ADL are represented by sixteen-
Xbit integer IDs. Although there is little facility for pro-
Xducing user-defined data types, the power of the existing
Xset makes it unlikely that such would be required for any
Xreasonable scenario.
X
X2.1. Objects
X
X As in most Adventure-like games, the most important
Xdata type in ADL is the Object. An object in real life can
Xbe a person, place, or thing. ADL models the world in the
Xsame way. Any Object encountered by the player is
Xrepresented by this type, as are all locations in the
Xscenario. Indeed, there can be Objects associated with peo-
Xple (more on that later). Notice that ADL treats all
XObjects uniformly and so it is possible to write a scenario
Xin which a player picks up an Object (a tent, say), carries
Xit around, and later enters it.
X
X All Objects are represented by (unique) sixteen-bit
Xintegers. This number is known as the "Object ID" of the
XObject. Objects are (essentially) record structures with
Xthe following elements:
X
XLocation The Object ID of the Object which contains
X this Object.
X
XContents The Object ID of the first Object which is
X contained in this Object, or zero if there is
X no such Object.
X
XLink The Object ID of the next Object which is
X located in the same place as this Object or
X zero if there is no such Object.
X
XModifier The ID of the modifier of this Object or zero
X if the Object has no modifier. For example,
X the Object "blue streak" would have a modifier
X ID which is the adjective "blue". Modifiers
X are explained further in Section 2.9.
X
XProperties Associated with each Object are 32 properties.
X While all of the above elements are maintained
X directly or indirectly by the ADL system, the
X values and meanings of properties are the
X responsibility of the programmer. The first
X 16 of these properties may only hold the value
X 0 or 1 (hence they are usually called
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 4 -
X
X
X "boolean" properties). Properties 17 through
X 32 may hold any value between -32768 and
X 32767. The last three of these properties
X have special meaning to ADL:
X
X LDESC (30) This is the ID of a routine
X which prints a "long" descrip-
X tion of the Object. Routines
X are defined in Chapter 6.
X
X SDESC (31) This is the ID of a routine
X which prints a "short" descrip-
X tion of the Object.
X
X ACTION (32) This is the ID of a routine
X which is called under the cir-
X cumstances detailed in Chapter
X 4.
X
X All Objects in ADL are stored in a tree. The root node
Xof the tree is predeclared and is named ".ALL". Its Object
XID is always zero. All other Objects are ultimately located
Xin .ALL.
X
X Two other predeclared Objects exist. One is named
X"STRING" and the other is named ".ME". .ME is not truly an
XObject -- it is more like a variable which represents the
Xcurrent Actor during the execution of an ADL program (more
Xon Actors in Section 3.1). It is illegal to use .ME outside
Xof the context of a routine. STRING is the Object which is
Xseen by the ADL program when the run-time sentence parser
Xencounters a string. Note that although STRING is prede-
Xclared by ADL, the properties of STRING must be defined by
Xthe ADL programmer. See Chapter 9 for more information on
XSTRING.
X
X2.2. Verbs
X
X Verbs are the means whereby a player manipulates the
Xenvironment. Verbs can denote motion, investigation, mani-
Xpulation, and any other action the ADL programmer can ima-
Xgine. A Verb is represented by a sixteen-bit integer known
Xas the Verb ID. Like Objects, Verbs are record structures.
XThey have the following elements:
X
XPREACT The ID of a routine to be called when this
X Verb is typed by the player. The routine is
X called before the ACTION routines of the
X Objects in the sentence. See Chapter 4 for
X more information.
X
XACTION The ID of a routine to be called when this
X Verb is typed by the player. This routine is
X called after the ACTION routines of the
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 5 -
X
X
X Objects in the sentence. Again, see Chapter 4
X for more information.
X
X Verbs may also be used as modifiers to nouns. This is
Xto allow easy implementation of Objects like the "north
Xwall" or "go north" (where "north" is normally a verb of
Xmotion).
X
X ADL predeclares the two Verbs "TELLER" and "NOVERB"
Xwhich are returned by the parser under circumstances shown
Xin Chapter 9. Although TELLER and NOVERB are predeclared,
Xtheir properties must be defined by the ADL programmer.
X
X2.3. Adjectives
X
X Adjectives serve only one purpose: to disambiguate oth-
Xerwise identical nouns (such as a "red ball" and a "blue
Xball"). Adjectives have no structure and exist only as
Xsixteen-bit Adjective IDs.
X
X2.4. Strings
X
X There are two forms of strings in ADL: compile-time
Xstrings and run-time strings. Compile-time strings are
Xthose which appear in the ADL source code for the scenario.
XThey are delimited by double quotes and are transformed into
Xpositive sixteen-bit String IDs by the compiler. These
Xstrings are free-form in that a carriage return may appear
Xin them at any point. This sort of carriage return is
Xtransformed into a blank. Should the ADL programmer desire
Xa true carriage return, the sequence \n should be embedded
Xin the string at the appropriate point. Compile-time
Xstrings may be limited to 255 characters in length in some
Ximplementations.
X
X Run-time strings are those which are typed by the
Xplayer and those which are generated by the built-in string
Xmanipulation routines. Strings in player input may be del-
Ximited by appropriately nested single or double quotes. All
Xrun-time strings are represented as NEGATIVE sixteen-bit
Xstring IDs.
X
X2.5. Numbers
X
X There are two forms of numbers in ADL: compile-time
Xnumbers and run-time numbers. Compile-time numbers exist in
Xthe ADL source code for the scenario and may be any integer
Xin the range of -32768 to 32767 inclusive. Run-time numbers
Xare those which are typed by the player. Run-time numbers
Xare transformed into a string consisting of the ASCII
Xrepresentation of their digits. A negative string ID is
Xthen returned for eventual use by the ADL program.
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 6 -
X
X
X2.6. Routines
X
X Routines in ADL are represented by (what else?) sixteen
Xbit Routine IDs. The only operations allowed on routines
Xare calling them and passing them to other routines as
Xparameters. The syntax of ADL routines is described in
XChapter 6. The routine "START" is predeclared by ADL and
Xmust be defined by the programmer or execution will be
Xprematurely terminated. The Routines "DWIMI" and "DWIMD"
Xare also predeclared by ADL and should be defined by the
Xprogrammer. DWIMI and DWIMD are called under circumstances
Xdetailed in Chapter 4.
X
X2.7. Global Variables
X
X There are a number of global variables available for
Xdefinition and use by the ADL programmer. A global is
Xrepresented by a sixteen-bit ID and may hold any integer
Xvalue from -32768 to 32767. These values may be interpreted
Xas simple numbers, String IDs, Routine IDs, Object IDs, Verb
XIDs, etc. depending upon how they are used. The globals
Xnamed Verb, Conj, Numd, Dobj, Prep, and Iobj are predeclared
Xby ADL and at run-time contain the values of the current
XVerb, Conjunction, Number of Direct Objects, Direct Object,
XPreposition, and Indirect Object, respectively.
X
X The ADL programmer may declare a block of global vari-
Xables for use as an array or list of things. See Chapter 5
Xfor more information.
X
X2.8. Local variables
X
X Local variables differ from global variables in that
Xtheir name is limited in scope to the routine in which they
Xappear. They are represented by sixteen-bit IDs which may
Xbe passed to other routines if desired. Local variables may
Xbe implemented in one of two ways: on the stack (like local
Xvariables on C and Pascal) in which case they are only
Xaround for as long as the current invocation of the routine;
Xor they may reside in the same space as global variables
X(like static locals in C or local variables in FORTRAN) in
Xwhich case they persist for the entire duration of program
Xexecution. Consult your local ADL documentation to deter-
Xmine which method is used in your implementation.
X
X2.9. Modifiers
X
X A modifier is simply a word that modifies an ambiguous
Xnoun to produce an Object. A modifier may be either a Verb
Xor an Adjective. If the modifier of an Object is a Verb, it
Xis represented as the NEGATIVE of the Verb ID. If it is an
XAdjective it is represented by the (positive) Adjective ID.
XIf the modifier is zero, the Object has no modifier.
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 7 -
X
X
X3. ADL Internal Structures
X
X ADL maintains several internal structures to achieve
Xthe level of interaction necessary for interesting play.
XThese structures are accessible only through the built-in
Xroutines described in Chapter 7.
X
X3.1. Actors
X
X In a typical adventure game it seems as if the player
Xis moving around the dungeon taking things, smelling them,
Xbreaking them, and so on. A better model would be that the
Xplayer is giving commands to an actor. It is the actor
Xwhich actually moves around, collects items, and otherwise
Xacts. It is this model which ADL follows.
X
X An Actor is essentially an "animate" object which acts
Xupon commands given to it. Notice that there is nothing in
Xthis model which prevents more than one Actor from running
Xaround a scenario. In fact, in ADL there may be up to ten
XActors which are active at any one time.
X
X There are two kinds of Actors: interactive and non-
Xinteractive. The player is an example of an interactive
XActor. Commands are read directly from the keyboard and
Xplaced in a line buffer which is then passed to the parser
Xand interpreter. When the line buffer is empty a new one is
Xread from the keyboard. Any number of Actors may be
Xinteractive, making multiple player games a possibility.
X
X The robot in the introductory script is an example of a
Xnon-interactive Actor (see Appendix 2 for the source to the
Xscenario which produced that script). The line buffer for
Xthe robot was initialized after the player typed the sen-
Xtence starting with "Tell the robot ...". The robot then
Xacted on this command by performing the requested actions in
Xparallel with the actions of the player. This means that
Xeach Actor gets one turn for each turn that the player
Xexperiences. A non-interactive Actor is deleted from the
Xlist of active Actors when its line buffer is emptied.
X
X There is a special object-like item named ".ME" used to
Ximplement this sort of "multiprocessing". .ME represents
Xthe Object ID of the current Actor for the purposes of mov-
Xing around, taking things, etc. Anything that the player
Xcan do can be done just as well by another Actor. This is
Xprobably the most powerful (and most obscure) feature of
XADL.
X
X Actors may be activated using the $actor built-in rou-
Xtine and deleted at any time by using the $delact routine.
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 8 -
X
X
X3.2. Daemons
X
X Daemons are routines which execute once for each active
XActor at the beginning of each turn. Daemons are typically
Xused for things like describing the player's location and
Xincrementing the turn counter. Daemons are activated by
Xusing the $sdem routine and may be de-activated by using the
X$ddem routine. Up to ten daemons may be active at one time.
X
X3.3. Fuses
X
X Fuses are routines which wait a certain amount of time,
Xexecute, then become inactive. The list of fuses is exam-
Xined each time the turn counter is incremented to see
Xwhether any have "burned down". If so, the fuse is executed
Xand deleted from the list.
X
X Fuses are typically used for things like waiting three
Xturns and then collapsing the room that the player was in,
Xor (the bane of all adventurers) running down the batteries
Xin a lamp. Fuses are activated by using the $sfus routine.
XUp to ten fuses may be active at one time. The $dfus rou-
Xtine may be called if the programmer wishes to delete a fuse
Xbefore it executes (the player found more batteries!).
X
X3.4. Prompter
X
X Many times during the play of the game it is desired
Xthat a player enter a line from the keyboard. Some sort of
Xprompting should be done in order to inform the player that
Xinput is desired. The ADL programmer may specify a Routine
XID to do this prompting. This routine is known as the
Xprompter and is set by using the $prompt routine.
X
X3.5. Run-Time Macros
X
X Normally when the parser gets its input from the line
Xbuffer of the current Actor, the words are what they seem to
Xbe: simple words. ADL has a facility whereby these words
Xmay be transformed before the parser sees them. Each word
Xis looked up in a table (the "macro table"). If found it is
Xreplaced by the expansion for the macro (which may be a
Xstring containing more than one word) and re-inserted into
Xthe line buffer whereupon the input process continues.
X
X One use of this facility is to "rename" objects. For
Xexample, it may be desired that the player be able to type
Xsomething like "Name the box 'bob'. Take bob." (notice that
Xthe second usage of bob has no quotes). This can be accom-
Xplished by the call ($define "bob" "box") which says to
Xexpand "bob" to "box" whenever it is encountered in the line
Xbuffer. The built-in routine $undef may be used to "unde-
Xfine" a macro if it outlives its usefulness -- for example
X($undef "bob") removes "bob" from the macro table. More is
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 9 -
X
X
Xsaid about macros in Section 7.10 under the entries for
X$define and $undef.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 10 -
X
X
X4. Putting It All Together
X
X The flow of execution of the game can be described now
Xthat the basic data types have been defined. The execution
Xstarts with an initialization step: an ADL routine named
XSTART is called. ADL terminates prematurely if START has
Xnot been defined. START typically activates the principal
XActor (the player) and a looker daemon (responsible for
Xdescribing the player's surroundings), initializes the
Xprompter, and so on. ADL then enters a loop from which it
Xnever returns (until program termination).
X
X4.1. The Flow of Execution
X
X The main loop of the game consists of a series of
Xphases. The built-in routine $phase will return the number
Xof the phase currently executing (see the flow diagram and
XSection 7.12 for the number of each of the phases). At the
Xbeginning of each turn, all active Daemons are executed for
Xeach Actor on the Actor list -- in the REVERSE order in
Xwhich the Actors were activated. This is so newly activated
XActors don't act before the older Actors have a chance to
Xact. The Daemons are executed in the order in which they
Xwere activated.
X
X After all Daemons have executed for all Actors, a
Xseries of phases are executed for each Actor on the Actor
Xlist (in the reverse order of Actor activation). The loop
Xprogresses downward in an orderly fashion unless interrupted
Xby a call to $exit. For information on $exit see Section
X4.2. The following are the phases which are executed for
Xeach Actor on the Actor list:
X
XClear Sentence The global variables Verb, Conj, Numd,
X Dobj, Prep, and Iobj are set to 0. This
X is done in a separate phase to facilitate
X the implementation of incremental sen-
X tences such as "Take. The red ball."
X
XInput A new line buffer is prompted for and read
X if the line buffer is empty and the
X current Actor is interactive.
X
X The current Actor is deleted from the
X Actor list and execution continues start-
X ing with the next Actor if the line buffer
X is empty and the current Actor is NOT
X interactive.
X
XParse All upper case letters in the line buffer
X are transformed into lower case letters.
X An attempt is then made at parsing the
X line buffer into a Verb, Direct Objects, a
X Preposition, and an Indirect Object. Note
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 11 -
X
X
X that unambiguous abbreviations of words
X are recognized by the parser (for example,
X if the words "newt" and "newspaper" are in
X the vocabulary, "new" is ambiguous but
X "news" is an abbreviation of "newspaper").
X An appropriate message is printed if this
X does not succeed and execution continues
X from the Input phase.
X
X ADL sentences are typically of the form
X "Verb DobjList Prep Iobj" "Verb Iobj
X DobjList", or "Iobj, String". This is an
X overly simplistic description - for a full
X specification see Chapter 9.
X
XDWIM An object may be ambiguous either through
X the lack of a modifier or through the use
X of a modifier without a noun (e.g. typing
X "Take the ball" when there is both a "red
X ball" and a "blue ball", or typing "Take
X red" in the same situation).
X
X An ADL routine named "DWIMI" is used if
X the Indirect Object is ambiguous. DWIMI
X is called once for each Object that could
X possibly be the one meant by the player.
X If EXACTLY one of these calls returns a
X non-zero value then the corresponding
X Object becomes the Indirect Object. How-
X ever, if DWIMI never returns a non-zero
X value or if it returns a non-zero value
X more than once, the player is told to be
X more specific and execution continues
X starting with the Clear Sentence phase
X above.
X
X An ADL routine named "DWIMD" is used if
X any of the Direct Objects are ambiguous.
X DWIMD is called for the Objects in ques-
X tion just like DWIMI.
X
XExecution The following phases are executed for
X every Direct Object in the Direct Object
X list. They are executed exactly once if
X there are no Direct Objects. This loop is
X the heart of the ADL system and is where
X the player's commands are actually carried
X out.
X
X Actor ACTION The ACTION routine of
X the current Actor is
X executed. It typically
X checks the sentence and
X possibly modifies it.
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 12 -
X
X
X This allows the handling
X of cases like "Take the
X beer then drink it"
X (where "it" needs to be
X massaged to mean "beer")
X and "Go north. Again."
X (where "Again" needs to
X be transformed into "Go
X north").
X
X Verb PREACT The PREACT routine of
X the current Verb is exe-
X cuted. It typically
X guards against incorrect
X use of multiple Direct
X Objects, or the use of
X Indirect Objects or
X strings where such use
X doesn't make sense. It
X also might check that
X all objects named are
X available for use.
X
X Iobj ACTION The ACTION routine of
X the current Indirect
X Object is executed.
X This is where some
X object-specific actions
X are performed. For
X example, the sentence
X "Put the coins in the
X slot" might be handled
X here if putting coins
X into the slot (as
X opposed to a box or a
X bag) causes something
X special to happen. If
X the Indirect Object is a
X string then the ACTION
X routine of the prede-
X clared ADL Object named
X STRING is executed.
X
X Dobj ACTION The ACTION routine of
X the current Direct
X Object is executed.
X This is where most
X object-specific actions
X are performed. For
X example, the sentence
X "Rub the lamp" might be
X handled here if rubbing
X the lamp is different
X than rubbing any other
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 13 -
X
X
X Object. The ACTION rou-
X tine of the predeclared
X ADL Object STRING is
X executed if the Direct
X Object is a string.
X
X Verb ACTION The ACTION routine of
X the current Verb is exe-
X cuted. This is where
X general default actions
X are usually handled.
X For example, the sen-
X tence "Rub the floor"
X might result in the mes-
X sage "Rubbing that
X object is not useful."
X
XRoom ACTION The ACTION routine of the current Actor's
X location is executed once the above loop
X has examined all of the Direct Objects.
X This routine is typically a "transition"
X routine -- that is, it might check whether
X the current verb is "north" and move the
X current actor to the appropriate location
X (it might check other directions as
X well!).
X
X4.2. $exit
X
X It is possible to change the normal flow of execution
Xby means of the $exit built-in routine. The programmer may
Xuse ($exit 0) to halt execution of the current phase and
Xmove on to the next phase. At any time, ($exit 1) may be
Xused to halt the execution of the current phase and skip to
Xthe next Actor. Inside the Direct Object loop, ($exit 2)
Xmay be used to skip the rest of the Object and Verb ACTIONs
Xand go on to the next Direct Object in the list. At any
Xtime after the parsing phase, ($exit 3) will return the flow
Xof control to the Parsing phase without clearing the sen-
Xtence. This allows for incremental entry of sentences; for
Xexample "The big door. Unlock. With the key".
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 14 -
X
X
X The following is a diagram of the flow of execution:
X
X
X START [0]
X |
X v
X +--------------------------------->o
X | |
X | v
X | Daemons [1]
X | |
X | v
X | Get Actor <----------------------+
X | | |
X | v |
X | +------------------> Clear Sentence |
X | | | |
X | | v |
X | | ($exit 3)====> Get Input? --n---> Delete Actor |
X | | | y | |
X | | v | |
X | o<---------------------- Parse? | |
X | ^ | | |
X | | v | |
X | o<-------------fail----- DWIMI | |
X | ^ | | |
X | | v | |
X | +--------------fail----- DWIMD | |
X | | | |
X | v | |
X | Get Dobj <-------+ | |
X | | | | |
X | v | | |
X | Actor ACTION [2] | | |
X | Verb PREACT [3] | | |
X | Iobj ACTION [4] | | |
X | Dobj ACTION [5] | | |
X | Verb ACTION [6] | | |
X | | | | |
X | v | | |
X | ($exit 2)===> More Dobjs? -y----+ | |
X | | n | |
X | v | |
X | Room ACTION [7] | |
X | | | |
X | v | |
X | ($exit 1)=========>o<-------------------+ |
X | | |
X | v |
X +--------------------------n- More Actors? -y-------------------+
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 15 -
X
X
X5. ADL Programs
X
X This chapter describes the format of ADL programs. An
XADL program consists of a list of one or more of the follow-
Xing statements. Comments in ADL programs are delimited by {
Xand }. Since case is significant in ADL, tokens which are
Xidentical except for differing case are different (for exam-
Xple, "noun" is not the same as "NOUN").
X
X Note: for a full BNF specification of ADL programs, see
XChapter 8.
X
X
X
XINCLUDE "filename";
X Input to the ADL compiler is read from filename
X until the end of file and compilation then resumes
X from the current file. A file included in compila-
X tion by means of an INCLUDE statement may INCLUDE
X other files.
X
X Example:
X INCLUDE "standard.adl";
X
X
X
XMESSAGE "message";
X The string message is printed on the console at com-
X pile time. This is used to remind the programmer of
X things which should be initialized or to simply
X reassure the programmer that the compiler is indeed
X reading the file.
X
X Example:
X MESSAGE "Whew! We're halfway through the file!\n";
X
X
X
XVAR name, name, ... ;
X This declares each name to be a new global variable.
X The contents of global variables are initialized to
X zero. Each name must not have been previously
X declared. Each name may be followed by a size
X specifier, in which case that number of words is
X allocated. As ADL routines have no specific facili-
X ties for handling arrays, it is the responsibility
X of the ADL programmer to add the desired offset to
X the base of the array in order to access an element
X of the array For example, ($setg ($plus Array 10) 5)
X is similar to Array[ 10 ] = 5 in C.
X
X Example:
X VAR
X Score,
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 16 -
X
X
X Dark,
X ObjList[ 10 ],
X MyLoc;
X
X
X
XLOCAL name, name, ... ;
X This statement is only legal inside routine defini-
X tions. It declares each name as a new Local Vari-
X able. Each name may or may not already have been
X declared. If a name is the same as the name of
X something declared outside the routine, that thing
X cannot be directly referenced by the routine. The
X name of a local variable is only visible to the rou-
X tine in which it is defined. Local variables may be
X arrays just as global variables may. Note that a
X routine may have a maximum of 32 words of local
X variables. Arrays of local variables use up that
X space rather quickly, so they should be used with
X care. See the next chapter for an example using
X local variables.
X
XVERB name, name, ... ;
X This statement declares each name to be a new Verb.
X The PREACT and ACTION routines of Verbs are initial-
X ized to zero. Each name must not have been previ-
X ously declared.
X
X Example:
X VERB take, drop, open, close;
X
X
X
XADJEC name, name, ... ;
X This statement declares each name to be a new Adjec-
X tive. Again, each name must not have been previ-
X ously declared.
X
X Example:
X ADJEC red, green, blue;
X
X
X
XNOUN ndecl, ndecl, ... ;
X This statement declares Objects. Ndecl may take the
X form obj or obj ( container ). The first form
X declares a new Object located in the object .ALL.
X The second form declares a new Object located in
X container. Each obj may be one of: an undeclared
X identifier, a modifier followed by an undeclared
X identifier, or a modifier followed by a previously
X declared noun. If obj is just an undeclared iden-
X tifier, the identifer is declared to be a noun and a
X new Object is created with that noun ID and with a
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 17 -
X
X
X modifier of 0. If obj is a modifier followed by an
X undeclared identifier, the identifier is declared to
X be a noun and a new Object is created with that noun
X ID and with the modifier set to the one specified.
X If obj is a modifier followed by a previously
X declared noun, a new Object is created with the
X specified noun ID and the specified modifier. Note
X that the declaration "NOUN foo, blue foo;" is ille-
X gal since it would be too easy to create situations
X where the player is unable to disambiguate the
X Objects.
X
X Example:
X NOUN room1;
X NOUN table( room1 ), chair( room1 ), red ball( room1 );
X
X
X
XROUTINE name, name, ... ;
X This statement declares each name to be a new rou-
X tine. Note that this does not associate a routine
X with the Routine ID -- it just declares the routine.
X This is useful for daisy-chaining routines (i.e.
X routine A calls routine B, which calls routine A)
X since everything must be declared before it is used.
X Each name must not have been previously declared.
X
X Example:
X ROUTINE Looker, Prompter, Quitter;
X
X
X
XARTICLE name, name, ... ;
X This statement declares each name to be a new Arti-
X cle. Each name must not have been previously
X declared.
X
X Example:
X ARTICLE the, a, an;
X
X
X
XPREP name, name, ... ;
X This statement declares each name to be a new Prepo-
X sition. Each name must not have been previously
X declared.
X
X Example:
X PREP in, into, on, above ;
X
X
X
Xobj (const) = expr ;
X This statement assigns property const of obj to be
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 18 -
X
X
X expr. Const must be a number or the name of a con-
X stant (see below). Expr may be a string, a number,
X a routine, another noun, or just about anything else
X which yields a sixteen bit ID. Obj must be previ-
X ously declared. A warning may be produced if this
X particular property is reassigned later in the pro-
X gram.
X
X Example:
X room1( LDESC ) =
X ($say "You are in a huge room.\n")
X ;
X chair( WEIGH ) = 450 ;
X table( MESSAGE ) = "This space for rent\n" ;
X
X
X
Xverb (const) = routine ;
X This statement assigns property const of verb to be
X routine. Const must be either PREACT or ACTION, and
X verb must have been previously declared. A warning
X may be produced if this particular property is reas-
X signed later in the program.
X
X Example:
X take( ACTION ) = ($say "You can't take that object.\n");
X drop( PREACT ) = (CheckAvail);
X
X
X
Xname = expr;
X This statement declares that name is equivalent to
X expr. Name must not have been previously declared
X and expr may be an object, a string, a routine, a
X number, or just about anything else that yields a
X sixteen-bit value.
X
X Example:
X MagicWord = "AbraCadabra"; { string ID }
X VISIT = 3; { constant }
X Silly = ($say "That's silly!\n"); { routine ID }
X toolbox = tool box; { object ID }
X
X
X
X(global) = expr;
X This statement initializes global variable global to
X have the value expr. Global must have been previ-
X ously declared and expr is the same as expr above.
X
X Example:
X ( MyLoc ) = -1;
X ( Score ) = 10;
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 19 -
X
X
X(global + const) = expr;
X This statement initializes the const'th slot in the
X global array global to have the value expr.
X
X Example:
X VAR foo[ 10 ];
X ( foo ) = 3; { Sets foo[0] to 3 }
X ( foo + 5 ) = 6; { Sets foo[5] to 6 }
X
X
X
Xprep1 obj prep2 = prep3;
X This statement declares that if the three-word
X sequence prep1 obj prep2 is encountered during run-
X time parsing in the proper position for a preposi-
X tion, it is to be replaced by prep3. Obj may be a
X modifier-noun pair and prep1, prep2, and prep3 must
X have been previously declared.
X
X Example:
X PREP
X in, of, before;
X NOUN
X front;
X
X in front of = before;
X
X
X
Xverb1 prep = verb2;
X This statement declares that if the two-word
X sequence verb1 prep is encountered during run-time
X parsing in the proper position for a verb, it is to
X be replaced by verb2. Verb1, verb2, and prep must
X have been previously declared.
X
X Example:
X VERB
X put, take, turn, wear, remove, light, douse;
X PREP
X on, off;
X
X put on = wear;
X take off = remove;
X turn on = light;
X turn off = douse;
X
X
X
X
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 20 -
X
X
X6. Routines
X
X This chapter describes the syntax of ADL routines. An
XADL routine consists of an optional LOCAL declaration fol-
Xlowed by a sequence of one or more expressions. An expres-
Xsion is one of the following:
X
XRoutine call A routine call in ADL takes the form (rout
X arglist). Rout is either the name of a
X built-in routine, the name of a user routine,
X or an expression which evaluates to a Routine
X ID. Arglist is a list of zero or more args
X each of which is one of:
X
X An expression
X
X A simple expression
X A simple expression is one of a
X string, a number, or a name
X which was declared as in Chapter
X 5.
X
X @global This is interpreted to mean "the
X contents (or value) of global".
X
X %number This is interpreted to mean "the
X numberth argument to this func-
X tion". Note that %0 is the
X number of arguments passed to
X this function.
X
X [ modif noun ]This construct must be used if
X the programmer wants to use the
X value of an Object which has a
X modifier.
X
X The value of the expression is the result of
X executing rout with arguments arglist.
X
XConditional A conditional expression takes the form
X ( IF arg1 THEN expression ...
X ELSEIF arg2 THEN expression ...
X ...
X ELSE expression ... )
X
X This statement evaluates arg1 and if the
X result is non-zero the expressions following
X THEN are executed. If the result of the
X evaluation of arg is zero then the expressions
X following THEN are skipped until one of ELSE,
X ELSEIF or the end of the conditional are
X found. If ELSEIF was found the corresponding
X arg is evaluated and execution proceeds as for
X IF. If none of the ELSEIFs evaluate to a
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 21 -
X
X
X non-zero value then the ELSE expressions are
X executed. The ELSEIFs and the ELSE are
X optional. The conditional expression returns
X the value of the last expression executed or
X zero of no expressions were executed.
X
XLoop A loop takes the form ( WHILE arg DO expres-
X sion ... ). If arg evaluates to a non-zero
X value then the expressions are evaluated.
X This process repeats until arg evaluates to
X zero. This statement always returns zero.
X
XExample On the following page is a sample ADL routine
X which demonstrates each of the above con-
X structs and is almost useful as well See
X Chapter 7 for the definitions of the built-in
X routines called.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 22 -
X
X
X { A sample looking daemon }
X Look =
X LOCAL obj;
X ($incturn) { Increment the turn counter }
X (IF ($prop ($loc .ME) VISIT) THEN
X { I've been here before - print a short description }
X ( ($sdesc ($loc .ME)) )
X ELSEIF ($ne ($cont ($loc .ME)) .ME) THEN
X { There are other objects here }
X ( ($ldesc ($loc .ME)) )
X ($say "You can see:\n")
X ($setg obj ($cont ($loc .ME)))
X (WHILE @obj DO
X { Describe each object in the room }
X ( ($sdesc @obj) )
X ($setg obj ($link @obj))
X )
X ELSE
X { I've never been here }
X ( ($ldesc ($loc .ME)) )
X ($say "There is nothing else in the room.\n")
X )
X ($setp ($loc .ME) VISIT TRUE)
X ;
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 23 -
X
X
X7. ADL Built-in Routines
X
X The following is the complete list of ADL built-in rou-
Xtines. They are organized into groups of related routines.
XA description of each routine is provided with at least one
Xexample to clarify its usage. The following groupings of
Xbuilt-in routines are detailed in this chapter:
X
X
X 7.1 Object Routines
X
X 7.2 Verb Routines
X
X 7.3 Arithmetic Routines
X
X 7.4 Boolean Routines
X
X 7.5 Global Value Routines
X
X 7.6 Transition Routines
X
X 7.7 String Manipulation Routines
X
X 7.8 Name Routines
X
X 7.9 Conversion Routines
X
X 7.10 Internal Structure Manipulation Routines
X
X 7.11 Special Routines
X
X 7.12 Miscellaneous Routines
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 24 -
X
X
X7.1. Object Routines
X
X These routines operate primarily on Objects. They move
XObjects around, find Object properties, and set Object pro-
Xperties.
X
X$loc ( $loc obj ) -> The location of obj.
X
X Example:
X (IF ($eq ($loc .ME) volcano) THEN
X ($say "You are fried to a crisp.\n")
X )
X
X
X
X$cont ( $cont obj ) -> The first object which is contained
X in obj.
X
X Example:
X (IF ($eq ($cont .ME) 0) THEN
X ($say "You are empty-handed.\n")
X )
X
X
X
X$link ( $link obj ) -> The next object contained in the
X same location as obj.
X
X Example:
X ($setg obj ($cont .ME))
X (WHILE @obj DO
X ($say ($name @obj) "\n")
X ($setg obj ($link @obj))
X )
X
X
X
X$ldesc ( $ldesc obj ) -> The long description of obj. This
X is equivalent to ($prop obj LDESC). Since this is a
X Routine ID, it is typically used as the callee in a
X routine call.
X
X Example:
X ($setg obj ($loc .ME))
X ( ($ldesc @obj) ) { Call LDESC of ($loc .ME) }
X
X
X
X$sdesc ( $sdesc obj ) -> The short description of obj.
X This is equivalent to ($prop obj SDESC). Since this
X is a Routine ID, it is typically used as the callee
X in a routine call.
X
X Example:
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 25 -
X
X
X ($setg obj ($loc .ME))
X ( ($sdesc @obj) ) { Call SDESC of ($loc .ME) }
X
X
X
X$action ( $action obj ) -> The ACTION routine of obj. This
X is equivalent to ($prop obj ACTION). Since this is
X a Routine ID, it is typically used as the callee in
X a routine call.
X
X Example:
X ( ($action .ME) ) { Call ACTION of .ME }
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X c 1987 Ross Cunniff and Tim Brengle
X
X
X
X
X
X - 26 -
X
X
X$modif ( $modif obj ) -> The modifier of obj. This is zero
X if there is no modifier, negative if the modifier is
X a Verb, and positive if the modifier is an Adjec-
X tive.
X
X Example:
X (IF ($eq ($modif [ blue ball ] ) blue) THEN
X ($say "$modif works!\n")
X )
X (IF ($eq ($modif [ north wall ] ) ($minus 0 north)) THEN
X ($say "$modif still works!\n")
X )
X (IF ($eq ($modif room1) 0) THEN
X ($say "$modif comes through one more time!\n")
X )
X
END_OF_man/doc.aa
if test 42626 -ne `wc -c <man/doc.aa`; then
echo shar: \"man/doc.aa\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test ! -d misc ; then
echo shar: Creating directory \"misc\"
mkdir misc
fi
if test ! -d samples ; then
echo shar: Creating directory \"samples\"
mkdir samples
fi
if test ! -d samples/aard ; then
echo shar: Creating directory \"samples/aard\"
mkdir samples/aard
fi
if test ! -d samples/demos ; then
echo shar: Creating directory \"samples/demos\"
mkdir samples/demos
fi
if test ! -d samples/mpu ; then
echo shar: Creating directory \"samples/mpu\"
mkdir samples/mpu
fi
if test ! -d util ; then
echo shar: Creating directory \"util\"
mkdir util
fi
echo shar: End of archive 1 \(of 11\).
cp /dev/null ark1isdone
MISSING=""
for I in 1 2 3 4 5 6 7 8 9 10 11 ; do
if test ! -f ark${I}isdone ; then
MISSING="${MISSING} ${I}"
fi
done
if test "${MISSING}" = "" ; then
echo You have unpacked all 11 archives.
rm -f ark[1-9]isdone ark[1-9][0-9]isdone
echo Making adl.doc
(cd man; cat doc.aa doc.ab doc.ac >adl.doc; rm doc.a[a-c])
else
echo You still need to unpack the following archives:
echo " " ${MISSING}
fi
## End of shell archive.
exit 0