44e26d6972
- CLAUDE.md 생성 (볼트 운영 규칙, Karpathy LLM Wiki 10가지 규칙) - 나의 핵심 맥락.md 생성 (아키텍트 프로필, 세컨드 브레인 목적, 핵심 소스) - raw/ 구조 정립 (book/기존 설계원칙 보존, articles/repos/notes/ 추가) - wiki/ 초기화 (index.md, log.md, concepts/sources/patterns/ 폴더) - output/ 초기화 - LLMWiki/ 기존 프롬프트 패턴 파일 보존 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
38 KiB
3.5 Efficient user-defined types
In section 3.4.2 we introduced tags as part of a caching mechanism for dispatch. Each argument is mapped to a tag, and the list of tags is then used as a key in a cache to obtain the handler. If the cache has a handler associated with this list of tags, it is used. If not, the trie of predicates is used to find the appropriate handler and it is entered into the cache associated with the list of tags.
This mechanism is pretty crude: the predicates that can be used for the applicability specifications are restricted to those that always give the same boolean value for any two objects with the same tag. So the discrimination of types cannot be any finer than the available tags. The tags were implementation-specific symbols, such as pair, vector, or procedure. So this severely limits the possible predicates. We could not have rules that distinguish between integers that satisfy even-integer? and integers that satisfy oddinteger?, for example.
What is needed is a system of tagging that makes it computationally easy to obtain the tag associated with a data item, but where the tags are not restricted to a small set of implementation-specific values. This can be accomplished by attaching a tag to each data item, either with an explicit data structure or via a table of associations.
We have several problems interwoven here: we want to use predicates in applicability specifications; we want an efficient mechanism for dispatch; and we want to be able to specify relationships between predicates that can be used in the dispatch. For example, we want to be able to say that the predicate integer? is the disjunction of the predicates even-integer? and oddinteger?, and also that integer? is the disjunction of positiveinteger?, negative-integer?, and zero?.
To capture such relationships we need to put metadata on the predicates; but adding an associative lookup to get the metadata of a predicate, as we did with the arity of a function (on page 28), adds
too much overhead, because the metadata will contain references to other tags, and chasing these references must be efficient.
One way out is to register the needed predicates. Registration creates a new kind of tag, a data structure that is associated with the predicate. The tag will be easy to attach to objects that are accepted by the predicate. The tag will provide a convenient place to store metadata.
We will construct a system in which each distinct object can have only one tag and where relationships between predicates can be declared. This may appear to be overly simple, but it is adequate for our purposes.
3.5.1 Predicates as types
Let's start with some simple predicates. For example, the primitive procedure exact-integer? is preregistered in our system as a simple predicate:
(predicate? exact-integer?)
#t
Now let's define a new predicate that's not a primitive. We will build it on this particularly slow test for prime numbers.
(define (slow-prime? n)
(and (n:exact-positive-integer? n)
(n:>= n 2)
(let loop ((k 2))
(or (n:> (n:square k) n)
(and (not (n:= (n:remainder n k) 0))
(loop (n:+ k 1)))))))
Note that all of the arithmetic operators are prefixed with n: to ensure that we get the underlying Scheme operations.
We construct the prime-number? abstract predicate, with a name for use in error messages and a criterion, slow-prime?, for an object to be considered a prime number:
(define prime-number?
(simple-abstract-predicate 'prime-number slow-prime?))
The procedure simple-abstract-predicate creates an abstract predicate, which is a clever trick for memoizing the result of an expensive predicate (in this case slow-prime?). An abstract predicate has an associated constructor that is used to make a tagged object, consisting of the abstract predicate's tag and an object. The constructor requires that the object to be tagged satisfies the expensive predicate. The resulting tagged object satisfies the abstract predicate, as well as carrying its tag. Consequently the tagged object can be tested for the property defined by the expensive predicate by using the fast abstract predicate (or, equivalently, by dispatching on its tag).
For example, the abstract predicate prime-number? is used to tag objects that are verified prime numbers, for the efficient implementation of generic dispatch. This is important because we do not want to execute slow-prime? during the dispatch to determine whether a number is prime. So we build a new tagged object, which contains both a tag (the tag for prime-number?) and a datum (the raw prime number). When a generic procedure is handed a tagged object, it can efficiently retrieve its tag and use that as a cache key.
In order to make tagged objects, we use predicateconstructor to get the constructor associated with the abstract predicate:
(define make-prime-number
(predicate-constructor prime-number?))
(define short-list-of-primes
(list (make-prime-number 2)
(make-prime-number 7)
(make-prime-number 31)))
The constructor make-prime-number requires that its argument be prime, as determined by slow-prime?: the only objects that can be tagged by this constructor are prime numbers.
(make-prime-number 4)
;Ill-formed data for prime-number: 4
3.5.2 Relationships between predicates
The sets that we can define with abstract predicates can be related to one another. For example, the primes are a subset of the positive integers. The positive integers, the even integers, and the odd integers are subsets of the integers. This is important because any operation that is applicable to an integer is applicable to any element of any subset, but there are operations that can be applied to an element of a subset that cannot be applied to all elements of an enclosing superset. For example, the even integers can be halved without leaving a remainder, but that is not true of the full integers.
When we defined prime-number?, we effectively defined a set of objects. But that set has no relation to the set defined by exactinteger?:
(exact-integer? (make-prime-number 2))
#f
We would like these sets to be properly related, which is done by adding some metadata to the predicates themselves:
(set-predicate<=! prime-number? exact-integer?)
This procedure set-predicate<=! modifies the metadata of its argument predicates to indicate that the set defined by the first argument is a (non-strict) subset of the set defined by the second argument. In our case, the set defined by prime-number? is declared to be a subset of the set defined by exact-integer?. Once this is done, exact-integer? will recognize our objects:
(exact-integer? (make-prime-number 2))
#t
3.5.3 Predicates are dispatch keys
The abstract predicates we have defined are suitable for use in generic dispatch. Even better, they can be used as cache keys to make dispatch efficient. As we described above, when a predicate is registered, a new tag is created and associated with the predicate. All
we need is a way to get the tag for a given object: the procedure get-tag does this.
If we pass get-tag to cache-wrapped-dispatch-store as its get-key argument, we have a working implementation. However, since the set defined by a predicate can have subsets, we need to consider a situation where there are multiple potential handlers for some given arguments. There are a number of possible ways to resolve this situation, but the most common is to identify the "most specific" handler by some means, and invoke that one. Since the subset relation is a partial order, it may not be clear which handler is most specific, so the implementation must resolve the ambiguity by independent means.
Here is one such implementation. It uses a procedure rule< to sort the matching rules into an appropriate order, then chooses a handler from the result. 30
(define (make-subsetting-dispatch-store-maker choose-handler)
(lambda ()
(let ((delegate (make-simple-dispatch-store)))
(define (get-handler args)
(let ((matching
(filter (lambda (rule)
(is-generic-handler-applicable?
rule args))
((delegate 'get-rules)))))
(and (n:pair? matching)
(choose-handler ; from sorted handlers
(map cdr (sort matching rule<))
((delegate 'get-default-handler))))))
(lambda (message)
(case message
((get-handler) get-handler)
(else (delegate message)))))))
The procedure make-most-specific-dispatch-store chooses the first of the sorted handlers to be the effective handler:
(define make-most-specific-dispatch-store
(make-subsetting-dispatch-store-maker
(lambda (handlers default-handler)
(car handlers))))
Another possible choice is to make a "chaining" dispatch store, in which each handler gets an argument that can be used to invoke the next handler in the sorted sequence. This is useful for cases where a subset handler wants to extend the behavior of a superset handler rather than overriding it. We will see an example of this in the clock handler of the adventure game in section 3.5.4.
(define make-chaining-dispatch-store
(make-subsetting-dispatch-store-maker
(lambda (handlers default-handler)
(let loop ((handlers handlers))
(if (pair? handlers)
(let ((handler (car handlers))
(next-handler (loop (cdr handlers))))
(lambda args
(apply handler (cons next-handler args))))
default-handler)))))
Either one of these dispatch stores can be made into a cached dispatch store by adding a caching wrapper:
(define (make-cached-most-specific-dispatch-store)
(cache-wrapped-dispatch-store
(make-most-specific-dispatch-store)
get-tag))
(define (make-cached-chaining-dispatch-store)
(cache-wrapped-dispatch-store
(make-chaining-dispatch-store)
get-tag))
Then we create the corresponding generic-procedure constructors:
(define most-specific-generic-procedure
(generic-procedure-constructor
make-cached-most-specific-dispatch-store))
(define chaining-generic-procedure
(generic-procedure-constructor
make-cached-chaining-dispatch-store))
3.5.4 Example: An adventure game
One traditional way to model a world is "object-oriented programming." The idea is that the world being modeled is made up of objects, each of which has independent local state, and the coupling between the objects is loose. Each object is assumed to have particular behaviors. An object may receive messages from other objects, change its state, and send messages to other objects. This is very natural for situations where the behavior we wish to model does not depend on the collaboration of multiple sources of information: each message comes from one other object. This is a tight constraint on the organization of a program.
There are other ways to break a problem into pieces. We have looked at "arithmetic" enough to see that the meaning of an operator, such as *, can depend on the properties of multiple arguments. For example, the product of a number and a vector is a different operation from the product of two vectors or of two numbers. This kind of problem is naturally formulated in terms of generic procedures. 31
Consider the problem of modeling a world made of "places," "things," and "people" with generic procedures. How should the state variables that are presumed to be local to the entities be represented and packaged? What operations are appropriately generic over what kinds of entities? Since it is natural to group entities into types (or sets) and to express some of the operations as appropriate for all members of an inclusive set, how is subtyping to be arranged? Any object-oriented view will prescribe specific answers to these design questions; here we have more freedom, and must design the conventions that will be used.
To illustrate this process we will build a world for a simple adventure game. There is a network of rooms connected by passages and inhabited by a variety of creatures, some of which are autonomous in that they can wander around. There is an avatar that is controlled by the player. There are things, some of which can be picked up and carried by the creatures. There are ways that the creatures can interact: a troll can bite another creature and damage it; any creature can take a thing carried by another creature.
Every entity in our world has a set of named properties. Some of these are fixed and others are changeable. For example, a room has exits to other rooms. These represent the topology of the network and cannot be changed. A room also has contents, such as the creatures who are currently in the room and things that may be acquired. The contents of a room change as creatures move around and as they carry things to and from other rooms. We will computationally model this set of named properties as a table from names to property values.
There is a set of generic procedures that are appropriate for this world. For example, some things, such as books, creatures, and the avatar, are movable. In every case, moving a thing requires deleting it from the contents of the source, adding it to the contents of the destination, and changing its location property. This operation is the same for books, people, and trolls, all of which are members of the "movable things" set.
A book can be read; a person can say something; a troll can bite a creature. To implement these behaviors there are specific properties of books that are different from the properties of people or those of trolls. But these different kinds of movable things have some properties in common, such as location. So when such a thing is instantiated, it must make a table for all of its properties, including those inherited from more inclusive sets. The rules for implementing the behavior of operators such as move must be able to find appropriate handlers for manipulating the properties in each case.
The game
Our game is played on a rough topological map of MIT. There are various autonomous agents (non-player characters), such as students and officials. The registrar, for example, is a troll. There are movable and immovable things, and movable things can be taken by an autonomous agent or the player's avatar. Although this game has little detail, it can be expanded to be very interesting.
We create a session with an avatar named gjs who appears in a random place. The game tells the player about the environment of the avatar.
(start-adventure 'gjs)
You are in dorm-row
You see here: registrar
You can exit: east
Since the registrar is here it is prudent to leave! (He may bite, and after enough bites the avatar will die.)
(go 'east)
gjs leaves via the east exit
gjs enters lobby-7
You are in lobby-7
You can see: lobby-10 infinite-corridor
You can exit: up west east
alyssa-hacker enters lobby-7
alyssa-hacker says: Hi gjs
ben-bitdiddle enters lobby-7
ben-bitdiddle says: Hi alyssa-hacker gjs
registrar enters lobby-7
registrar says: Hi ben-bitdiddle alyssa-hacker gjs
Notice that several autonomous agents arrive after the avatar, and that they do so one at a time. So we see that the report is for an interval of simulated time rather than a summary of the state at an instant. This is an artifact of our implementation rather than a deliberate design choice.
Unfortunately the registrar has followed, so it's time to leave again.
(say "I am out of here!")
gjs says: I am out of here!
(go 'east)
gjs leaves via the east exit
gjs enters lobby-10
You are in lobby-10
You can see: lobby-7 infinite-corridor great-court
You can exit: east south west up
(go 'up)
gjs leaves via the up exit
gjs enters 10-250
You are in 10-250
You see here: blackboard
You can exit: up down
Room 10-250 is a lecture hall, with a large blackboard. Perhaps we can take it?
(take-thing 'blackboard)
blackboard is not movable
So sad—gjs loves blackboards. Let's keep looking around.
(go 'up)
gjs leaves via the up exit
gjs enters barker-library
You are in barker-library
You see here: engineering-book
You can exit: up down
An earth-shattering, soul-piercing scream is heard...
Apparently, a troll (maybe the registrar) has eaten someone. However, here is a book that should be takable, so we take it and return to the lecture hall.
(take-thing 'engineering-book)
gjs picks up engineering-book
(go 'down)
gjs leaves via the down exit
gjs enters 10-250
You are in 10-250
Your bag contains: engineering-book
You see here: blackboard
You can exit: up down
From the lecture hall we return to lobby-10, where we encounter lambda-man, who promptly steals our book.
(go 'down)
gjs leaves via the down exit
gjs enters lobby-10
gjs says: Hi lambda-man
You are in lobby-10
Your bag contains: engineering-book
You see here: lambda-man
You can see: lobby-7 infinite-corridor great-court
You can exit: east south west up
alyssa-hacker enters lobby-10
alyssa-hacker says: Hi gjs lambda-man
lambda-man takes engineering-book from gjs
gjs says: Yaaaah! I am upset!
The object types
To create an object in our game, we define some properties with make-property, define a type predicate with make-type, get the predicate's associated instantiator with type-instantiator, and call that instantiator with appropriate arguments.
How do we make a troll? The make-troll constructor for a troll takes arguments that specify the values for properties that are specific to the particular troll being constructed. The troll will be created in a given place with a restlessness (proclivity to move around), an acquisitiveness (proclivity to take things), and a hunger (proclivity to bite other people).
(define (create-troll name place restlessness hunger)
(make-troll 'name name
'location place
'restlessness restlessness
'acquisitiveness 1/10
'hunger hunger))
We create two trolls: grendel and registrar. They are initially placed in random places, with some random proclivities.
(define (create-trolls places)
(map (lambda (name)
(create-troll name
(random-choice places)
(random-bias 3)
(random-bias 3)))
'(grendel registrar)))
The procedure random-choice randomly selects one item from the list it is given. The procedure random-bias chooses a number (in this case 1, 2, or 3) and returns its reciprocal.
The troll type is defined as a predicate that is true only of trolls. The make-type procedure is given a name for the type and a descriptor of the properties that are specific to trolls. (Only trolls have a hunger property.)
(define troll:hunger
(make-property 'hunger 'predicate bias?))
(define troll?
(make-type 'troll (list troll:hunger)))
The troll is a specific type of autonomous agent. Thus the set of trolls is a subset of (<=) the set of autonomous agents.
(set-predicate<=! troll? autonomous-agent?)
The constructor for trolls is directly derived from the predicate that defines the type, as is the accessor for the hunger property.
(define make-troll
(type-instantiator troll?))
(define get-hunger
(property-getter troll:hunger troll?))
Autonomous agents are occasionally stimulated by the "clock" to take some action. The distinctive action of the troll is to bite other people.
(define-clock-handler troll? eat-people!)
A biased coin is flipped to determine whether the troll is hungry at the moment. If it is hungry it looks for other people (trolls are people too!), and if there are some it chooses one to bite, causing the victim to suffer some damage. The narrator describes what happens.
(define (eat-people! troll)
(if (flip-coin (get-hunger troll))
(let ((people (people-here troll)))
(if (n:null? people)
(narrate! (list (possessive troll) "belly
rumbles")
troll)
(let ((victim (random-choice people)))
(narrate! (list troll "takes a bite out of"
victim)
troll)
(suffer! (random-number 3) victim))))))
The procedure flip-coin generates a random fraction between 0 and 1. If that fraction is greater than the argument, it returns true. The procedure random-number returns a positive number less than or equal to its argument.
The procedure narrate! is used to add narration to the story. The second argument to narrate! (troll in the above code) may be anything that has a location. The narrator announces its first argument in the location thus determined. One can only hear that announcement if one is in that location.
We said that a troll is a kind of autonomous agent. The autonomous agent type is defined by its predicate, which specifies the properties that are needed for such an agent. We also specify that the set of autonomous agents is a subset of the set of all persons.
(define autonomous-agent:restlessness
(make-property 'restlessness 'predicate bias?))
(define autonomous-agent:acquisitiveness
(make-property 'acquisitiveness 'predicate bias?))
(define autonomous-agent?
(make-type 'autonomous-agent
(list autonomous-agent:restlessness
autonomous-agent:acquisitiveness)))
(set-predicate<=! autonomous-agent? person?)
The constructor for trolls specified values for the properties restlessness and acquisitiveness, which are needed to make an autonomous agent, in addition to the hunger property specific to
trolls. Since trolls are autonomous agents, and autonomous agents are persons, there must also be values for the properties of a person and all its supersets. In this system almost all properties have default values that are automatically filled if not specified. For example, all objects need names; the name was specified in the constructor for trolls. But a person also has a health property, necessary to accumulate damage, and this property value was not explicitly specified in the constructor for trolls.
The generic procedures
Now that we have seen how objects are built, we will look at how to implement their behavior. Specifically, we will see how generic procedures are an effective tool for describing complex behavior.
We defined get-hunger, which is used in eat-people!, in terms of property-getter. A getter for a property of objects of a given type is implemented as a generic procedure that takes an object as an argument and returns the value of the property.
(define (property-getter property type)
(let ((procedure ; the getter
(most-specific-generic-procedure
(symbol 'get- (property-name property))
1 ; arity
#f))) ; default handler
(define-generic-procedure-handler procedure
(match-args type)
(lambda (object)
(get-property-value property object)))
procedure))
This shows the construction of a generic procedure with a generated name (for example get-hunger) that takes one argument, and the addition of a handler that does the actual access. The last argument to most-specific-generic-procedure is the default handler for the procedure; specifying #f means that the default is to signal an error.
We also used define-clock-handler to describe an action to take when the clock ticks. That procedure just adds a handler to a
generic procedure clock-tick!, which is already constructed.
(define (define-clock-handler type action)
(define-generic-procedure-handler clock-tick!
(match-args type)
(lambda (super object)
(super object)
(action object))))
This generic procedure supports "chaining," in which each handler gets an extra argument (in this case super) that when called causes any handlers defined on the supersets of the given object to be called. The arguments passed to super have the same meaning as the arguments received here; in this case there's just one argument and it is passed along. This is essentially the same mechanism used in languages such as Java, though in that case it's done with a magic keyword rather than an argument.
The clock-tick! procedure is called to trigger an action, not to compute a value. Notice that the action we specify will be taken after any actions specified by the supersets. We could have chosen to do the given action first and the others later, just by changing the order of the calls.
The real power of the generic procedure organization is illustrated by the mechanisms for moving things around. For example, when we pick up the engineering book, we move it from the room to our bag. This is implemented with the move! procedure:
(define (move! thing destination actor)
(generic-move! thing
(get-location thing)
destination
actor))
The move! procedure is implemented in terms of a more general procedure generic-move! that takes four arguments: the thing to be moved, the thing's current location, its destination location, and the actor of the move procedure. This procedure is generic because the movement behavior potentially depends on the types of all of the arguments.
When we create generic-move! we also specify a very general handler to catch cases that are not covered by more specific handlers (for specific argument types).
(define generic-move!
(most-specific-generic-procedure 'generic-move! 4 #f))
(define-generic-procedure-handler generic-move!
(match-args thing? container? container? person?)
(lambda (thing from to actor)
(tell! (list thing "is not movable")
actor)))
The procedure tell! sends the message (its first argument) to the actor that is trying to move the thing. If the actor is the avatar, the message is displayed.
In the demo we picked up the book. We did that by calling the procedure take-thing with the name engineering-book. This procedure resolves the name to the thing and then calls takething!, which invokes move!:
(define (take-thing name)
(let ((thing (find-thing name (here))))
(if thing
(take-thing! thing my-avatar)))
'done)
(define (take-thing! thing person)
(move! thing (get-bag person) person))
There are two procedures here. The first is a user-interface procedure to give the player a convenient way of describing the thing to be taken by giving its name. It calls the second, an internal procedure that is also used in other places.
To make this work we supply a handler for generic-move! that is specialized to moving mobile things from places to bags:
(define-generic-procedure-handler generic-move!
(match-args mobile-thing? place? bag? person?)
(lambda (mobile-thing from to actor)
(let ((new-holder (get-holder to)))
(cond ((eqv? actor new-holder)
(narrate! (list actor
"picks up" mobile-thing)
actor))
(else
(narrate! (list actor
"picks up" mobile-thing
"and gives it to" new-holder)
actor)))
(if (not (eqv? actor new-holder))
(say! new-holder (list "Whoa! Thanks, dude!")))
(move-internal! mobile-thing from to))))
If the actor is taking the thing, the actor is the new-holder. But it is possible that the actor is picking up the thing in the place and putting it into someone else's bag!
The say! procedure is used to indicate that a person has said something. Its first argument is the person speaking, and the second argument is the text being spoken. The move-internal! procedure actually moves the object from one place to another.
To drop a thing we use the procedure drop-thing to move it from our bag to our current location:
(define (drop-thing name)
(let ((thing (find-thing name my-avatar)))
(if thing
(drop-thing! thing my-avatar)))
'done)
(define (drop-thing! thing person)
(move! thing (get-location person) person))
The following handler for generic-move! enables dropping a thing. The actor may be dropping a thing from its own bag or it might pick up something from another person's bag and drop it.
(define-generic-procedure-handler generic-move!
(match-args mobile-thing? bag? place? person?)
(lambda (mobile-thing from to actor)
(let ((former-holder (get-holder from)))
(cond ((eqv? actor former-holder)
(narrate! (list actor
"drops" mobile-thing)
actor))
(else
(narrate! (list actor
"takes" mobile-thing
"from" former-holder
"and drops it")
actor)))
(if (not (eqv? actor former-holder))
(say! former-holder
(list "What did you do that for?")))
(move-internal! mobile-thing from to))))
Yet another generic-move! handler provides for gifting or stealing something, by moving a thing from one bag to another bag. Here the behavior depends on the relationships among the actor, the original holder of the thing, and the final holder of the thing.
(define-generic-procedure-handler generic-move!
(match-args mobile-thing? bag? bag? person?)
(lambda (mobile-thing from to actor)
(let ((former-holder (get-holder from))
(new-holder (get-holder to)))
(cond ((eqv? from to)
(tell! (list new-holder "is already carrying"
mobile-thing)
actor))
((eqv? actor former-holder)
(narrate! (list actor
"gives" mobile-thing
"to" new-holder)
actor))
((eqv? actor new-holder)
(narrate! (list actor
"takes" mobile-thing
"from" former-holder)
actor))
(else
(narrate! (list actor
"takes" mobile-thing
"from" former-holder
"and gives it to" new-holder)
actor)))
(if (not (eqv? actor former-holder))
(say! former-holder (list "Yaaaah! I am upset!")))
(if (not (eqv? actor new-holder))
(say! new-holder
(list "Whoa! Where'd you get this?")))
(if (not (eqv? from to))
(move-internal! mobile-thing from to)))))
Another interesting case is the motion of a person from one place to another. This is implemented by the following handler:
(define-generic-procedure-handler generic-move!
(match-args person? place? place? person?)
(lambda (person from to actor)
(let ((exit (find-exit from to)))
(cond ((or (eqv? from (get-heaven))
(eqv? to (get-heaven)))
(move-internal! person from to))
((not exit)
(tell! (list "There is no exit from" from
"to" to)
actor))
((eqv? person actor)
(narrate! (list person "leaves via the"
(get-direction exit) "exit")
from)
(move-internal! person from to))
(else
(tell! (list "You can't force"
person
"to move!")
actor))))))
There can be many other handlers, but the important thing to see is that the behavior of the move procedure can depend on the types of all of the arguments. This provides a clean decomposition of the behavior into separately understandable chunks. It is rather difficult to achieve such an elegant decomposition in a traditional objectoriented design, because in such a design one must choose one of the arguments to be the principal dispatch center. Should it be the thing being moved? the source location? the target location? the actor? Any one choice will make the situation more complex than necessary.
As Alan Perlis wrote: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."
Implementing properties
We saw that the objects in our game are created by defining some properties with make-property, defining a type predicate with
make-type, getting the predicate's associated instantiator with type-instantiator, and calling that instantiator with appropriate arguments. This simple description hides a complex implementation that is worth exploring.
The interesting aspect of this code is that it provides a simple and flexible mechanism for managing the properties that are associated with a type instance, which is robust when subtyping is used. Properties are represented by abstract objects rather than names, in order to avoid namespace conflicts when subtyping. For example, a type mammal might have a property named forelimb that refers to a typical front leg. A subtype bat of mammal might have a property with the same name that refers to a different object, a wing! If the properties were specified by their names, then one of these types would need to change its name. In this implementation, the property objects are specified by themselves, and two properties with the same name are distinct.
The procedure make-property creates a data type containing a name, a predicate, and a default-value supplier. Its first argument is the property's name, and the rest of the arguments are a property list with additional metadata about the property. For example, see the definition of troll:hunger on page 143. We will ignore how the property list is parsed since it's not interesting. 32
(define (make-property name . plist)
(guarantee n:symbol? name)
(guarantee property-list? plist)
(%make-property name
(get-predicate-property plist)
(get-default-supplier-property plist)))
A property is implemented as a Scheme record [65], which is a data structure that consists of a set of named fields. It is defined by elaborate syntax that specifies a constructor, a type predicate, and an accessor for each field:
(define-record-type <property>
(%make-property name predicate default-supplier)
property?
(name property-name)
(predicate property-predicate)
(default-supplier property-default-supplier))
We chose to give the primitive record constructor %make-property a name with an initial percent sign (%). We often use the initial percent sign to indicate a low-level procedure that will not be used except to support a higher-level abstraction. The %make-property procedure is used only in make-property, which in turn is used by other parts of the system.
Given a set of properties, we can construct a type predicate:
(define (make-type name properties)
(guarantee-list-of property? properties)
(let ((type
(simple-abstract-predicate name instance-data?)))
(%set-type-properties! type properties)
type))
A type predicate is an ordinary abstract predicate (see page 134) along with the specified properties, which are stored in an association using %set-type-properties!. Those specified properties aren't used by themselves; instead they are aggregated with the properties of the supersets of this type. The object being tagged satisfies instance-data?. It is an association from the properties of this type to their values.
(define (type-properties type)
(append-map %type-properties
(cons type (all-supertypes type))))
And type-instantiator builds the instantiator, which accepts a property list using property names as keys, parses that list, and uses the resulting values to create the instance data, which associates each property of this instance with its value. It also calls the setup! procedure, which gives us the ability to do type-specific initialization.
(define (type-instantiator type)
(let ((constructor (predicate-constructor type))
(properties (type-properties type)))
(lambda plist
(let ((object
(constructor (parse-plist plist properties))))
(set-up! object)
object))))
Exercise 3.16: Adventure warmup
Load the adventure game and start the simulation by executing the command (start-adventure your-name). Walk your avatar around. Find some takable object and take it. Drop the thing you took in some other place.
Exercise 3.17: Health
Change the representation of the health of a person to have more possible values than are given in the initial game. Scale your representation so that the probability of death from a troll bite is the same as it was before you changed the representation. Also make it possible to recover from a nonfatal troll bite, or other loss of health, by some cycles of rest.
Exercise 3.18: Medical help
Make a new place, the medical center. Make it easily accessible from the Green building and the Gates tower. If a person who suffers a nonfatal injury (perhaps from a troll bite) makes it to the medical center, their health may be restored.
Exercise 3.19: A palantir
Make a new kind of thing called a palantir (a "seeing stone," as in Tolkien's Lord of the Rings). Each instance of a palantir can communicate with any other instance; so if there is a palantir in lobby-10 and another in dorm-row, you can observe the goings-on in
dorm-row by looking into a palantir in lobby-10. (Basically, a palantir is a magical surveillance camera and display.)
Plant a few immovable palantiri in various parts of the campus, and enable your avatar to use one. Can you keep watch on the positions of your friends? Of the trolls?
Can you make an autonomous person other than your avatar use a palantir for some interesting purpose? The university's president might be a suitable choice.
Exercise 3.20: Invisibility
Make an "Invisibility Cloak" that any person (including an avatar) can acquire to become invisible, thus invulnerable to attacks by trolls. However, the cloak must be discarded (dropped) after a short time, because possession of the cloak slowly degrades the person's health.
Exercise 3.21: Your turn
Now that you have had an opportunity to play with our "world" of characters, places, and things, extend this world in some substantial way, limited only by your creativity. One idea is to have mobile places, such as elevators, which have entrances and exits that change with time, and are perhaps controllable by persons. But that is just one suggestion—invent something you like!
Exercise 3.22: Multiple players
This is a pretty big project rather than a simple exercise.
- a. Extend the adventure game so that there can be multiple players, each controlling a personal avatar.
- b. Make it possible for players to be on different terminals.