I was originally going to title this post "I7 Purged of Every Flaw". But
someone might not realize I was kidding. What I'm actually going to do is
sketch out a scheme for unifies a lot of I7's disparate mechanisms:
properties, adjectives, kinds. It is a uniform scheme which relieves some of
the limitations of these mechanisms, while still being firmly based on the
(hopefully) familiar rule model.

This is a sweeping enough change that it probably isn't the same language
any more. This could wind up being Inform 7a, or Inform 8, or the root of an
entirely new IF system. However, for the sake of familiarity, I will discuss
it as an extension to I7, with I7-like example code and so on.

(I will also refer to "Z-machine" mechanisms, but it could be Glulx or
whatever game execution platform.)

What I am *not* addressing in this post: natural language; relations. (Well,
I'll touch on relations at the end.) I am also not dealing with the
rule-precedence topic that I've talked about in the past -- although I'll be
assuming that the compiler's rule engine *has* a way to deal with precedence
issues.

---------

** Attacking the problem: the description property

Way back in May, I opined that the use of description properties in I7 is a
bit of a historical artifact. You want to attach a textual description to
most game objects, but the natural way to do this in I7 is a set of rules:

  Rule for describing a thing: say "You see nothing special."
  Rule for describing a room: say "" [the default room description is blank]
  ...
  Rule for describing the sword: say "It's an ancient Elvish sword."
  Rule for describing the lamp: say "It's a battered brass lantern."
  Rule for describing the lamp when the lamp is on: say "It's a
    brightly-glowing brass lantern."

(One could set up this kind of description in I7 today. It would be an
extension that declared all descriptions to be "[run-describing-activity]",
a describing activity defined as above, and then a phrase "To
run-describing-activity..." Might even be worth doing, but that's not the
point of today's lecture. :)

When I first thought of this, my impulse was to throw away description
properties entirely. Do it with rules. This is my usual plan: if there are
two mechanisms that seem to serve the same purpose, one of them is
redundant.

But: if two mechanisms seem to serve the same purpose, maybe one is a
special case of the other.

Take the whole notion of an object property:

  The description of the sword is "It's an ancient Elvish sword."

...and assume that this *is* a rule -- simply another phrasing of

  Rule for describing the sword: say "It's an ancient Elvish sword."

(Perhaps the "describing activity" was defined with noun form "description",
so the compiler knows how to do this rephrasing.)

(Footnote: I am skipping over the distinction between a piece of text and
the action of saying that text. Maybe the description of the sword is *to
say* "It's an ancient sword." Ask me more about this later.)

Note that this neatly includes the capability of "The description of a KIND
is usually..." The rule mechanism already knows how to cope with that sort
of thing. It also lets us do stuff like "The description of X is Y *when
C*", which is new -- I7 cannot currently do that.

What else can we (currently) do with description properties? We can change
them.

  Change the description of the lamp to "It's a burned-out lamp."

I don't like to write code that way, as it happens. (I'd prefer a variable
description based on some attribute.) But it's a valid thing to do. If all
descriptions are rules, how do I account for changing them in this
imperative way?

Well, the naive answer is to assume there's an implicit rule:

  Rule for describing a thing (called T) when T has-been-changed-to X:
    say X.

The "has-been-changed-to" condition is an internal construct -- the language
doesn't care how it's implemented. Most likely the compiler would assign a
Z-machine property for this purpose. But at this point the *language* notion
of a "property" is completely separate from Z-machine properties.

Note that this implicit rule doesn't have to affect game efficiency. In *my*
game, I'm not *going* to change any descriptions on the fly -- like I said,
it's not my style. The phrase "Change the description..." will never occur
in my game. The compiler can detect this, and decide that the implicit rule
can be entirely dropped from the rule model.

(The compiler may well be able to do smarter optimizations. If the only
"change the description" phrase in a game applies to the lamp, the implicit
rule can be restricted to "Rule for describing the lamp when..." and then
the extra if-test will only apply to the lamp. This is a level of
optimization that I7 does not currently support -- but if the rule engine
can do it, we can take advantage of it.)

Also note, by the way, these implicit rules aren't the only way to manage a
mutable description property. You could write your own description-changing
phrase, which stores the value however you want, and then have a "rule for
describing" which retrieves the value.

(This scheme lets you arbitrarily redefine the "getter" of a property.
Should we also allow the author to redefine the "setter", the implementation
of the "change P of T to V" phrase? I dunno. Probably. You tell me.)

** Extend the problem: properties containing values

Okay, this "properties are just rules" idea seems to be working out. What
other features do properties support (in current I7)? Well, properties can
store data.

  The lamp has a number called the charge. The charge of the lamp is 10.
  ...
  Change the charge of the lamp to 9.
  If the lamp has a charge, ...
  If the charge of the lamp is 10, ...

This is where I snuck around the point I mentioned earlier, the difference
between having some text and saying it. The description property stores
data, but really just so that it can be printed. Lots of properties aren't
like that; they genuinely store data for later retrieval.

But we can still do that, because rules can return values. (It's awkward,
but what the heck. Assume that the phrase "decide on" mechanism for
returning values, which is fairly tidy, is going to be unified with
activities and rulebooks. It's not the biggest assumption this post makes.)

What's a property? An activity for setting a value, and an activity for
getting it. If you say "The weight of a brick is 5", you're implicitly
creating the rule:

  Rule for getting the weight of a brick: decide on 5.

And changing the weight is just like changing the description. *If* the game
changes a weight property, the compiler will need to allocate an internal
Z-machine property and add an implicit rule for checking it.

(The question of whether an object provides a property can be handled with
some kind of exceptional result. "Rule for getting the weight of a thing:
ain't got one.")

This is not a deep idea, but look at the nice stuff it gets us:

Computed properties. You can say "Rule for getting the weight of a solid
(S): decide on the density of S times the volume of S." The value comes from
arithmetic rather than from a "change" statement being executed -- but
that's an implementation detail. The user doesn't care. And since the rule
engine is in play, you don't even have to be homogenous about it. Some
objects could have computed weights, others have set weights. (It's IF:
exceptions will always arise.)

Properties of non-objects. What if I said:

  Rule for getting the double of a number (N): decide on 2 times N.

Now, how is that any different from a computed property? N is a number as
opposed to a brick. That's the *only* difference. Of course, the compiler
will have to jump through some hoops if I then say:

  Change the double of 5 to 11.

That's not *syntactically* illegal -- it's just hard to optimize! The
compiler might have to set up a hash table of changed values. Or maybe the
compiler will cry uncle. I'm okay with that. I7 already operates in a regime
where some meaningful source code fails to compile because it's too hard.
Aim for a unified language schema, and then at least we'll know where to put
new pieces as we implement them.

Oh, yes, and global variables just become properties with no arguments at
all.

I've skipped over either/or properties, but they can be handled the same way
as value properties -- as you might expect, they're value properties with
boolean values. Note that I7 already has a sort of computed boolean
property: the adjective.

  Definition: A room is occupied if a person is in it.

This could as well be:

  Rule for deciding whether a room (R) is occupied:
    if a person is in R, decide yes;
    else decide no.

(In fact I7 already has a definition syntax which employs rules, just like
this.) So great -- unify that with settable either/or properties, same trick
as before.

At this point you're probably standing on a chair and screaming, what the
hell? Adjectives are computed -- they come out of a formula! Properties can
be set or cleared at any time! How are those *the same thing*?

Because this is a rule-based system. One rule for deciding X computes a
value. Another rule for deciding X checks a stored value. The rules
conflict. Big deal -- we have mechanisms for deciding rule precedence. It's
a solved problem.

(Okay, not as solved as I'd like. But since I *do* want a better way for a
language to handle rule conflicts, I might as well want it for multiple
purposes.)

In fact, we can make a broad generalization: run-time changes take
precedence over initial conditions. If you say "now the kitchen is
occupied", it's an excellent guess that this -- the implicit value-checking
rule -- should override the rule about whether a person is there. You'll
probably want a way to wipe the stored value ("change the kitchen back to
its initial occupation condition", only less ugly) but this is a detail.

What? You in the back? You're going to ask me when it stops, right? ...

read more »

** Going for broke: kinds

What else have we got? Oh, yes, kinds.

As we noted on the newsgroup a few days ago, kinds in I7 have limitations.
(Standard example: you can't make a man who is a door. Ok, that's a silly
example. But I have encountered this in real-life game creation: I defined a
kind, and had a bunch of examples. Then I wanted to make another instance of
that kind which floated between several rooms. Not possible: my kind was not
derived from backdrop.)

The standard rules use kinds to describe groups of objects. There are rules
which apply to doors; you can put a door in your game; the rules apply to
your door. But... we already have ways to describe objects. Several ways,
which I've been trying to unify.

Say we kapoof the notion of "kinds" from the language, and instead use
either/or properties in the way I've been describing.

  A thing can be a door.

Well, that's straightforward. It gives us the implicit rule:

  Rule for deciding whether a thing is a door: decide no. [Things are
    usually not doors.]

Create a door:

  The garden gate is a door.

Implicit rule:

  Rule for deciding whether the garden gate is a door: decide yes.

The rule engine easily sees that this is an exception to the general rule,
and therefore has higher precedence. Result: as expected.

Oh, sure, the compiler is going to have to optimize this. So? It had to
optimize the description property too. Heuristic: if a whole bunch of rules
for an activity hinge on what the argument object is, you should allocate a
Z-machine property. (If the rules return a boolean, allocate a Z-machine
attribute instead.) Now you can run the rules in constant time. If you're a
crazy person and you change the player into a door halfway through the game,
the compiler can still boil it down to that constant time plus an if.

** Going for broker: why kinds are hard

Now, kinds are different from either/or properties in two ways: they are
immutable, and they form an inheritance tree.

Immutability can go honk itself. If you want to change the player into a
door, go for it. The system can handle that, and (more importantly) the
system can be efficient about doorness in all the games that *don't* do
that.

Inheritance? It's certainly desirable to be able to say:

  A thing can be a person. A person can be a man. A person can be a woman.
  Steve is a man.

...and have the compiler realize that Steve must also be a person.

This is not merely a way to shorten your object declarations. The compiler
must also realize that the set of men is a *subset* of the set of people.
When it sees two rules:

  Rule for describing a person: say "It is humanoid."
  Rule for describing a man: say "Masculine!"

...it must deduce that the second rule is logically stricter than the first,
and so takes precedence. (I've spent this whole article appealing to the
rule engine to solve all my problems. I can't afford to handicap it now!)

From the top, now. The implicit rules here are:

  Rule for deciding whether a thing is a person: decide no.
  Rule for deciding whether a thing is a man: decide no.
  Rule for deciding whether a man is a person: decide yes.
  Rule for deciding whether Steve is a man: decide yes.

The third rule is the juicy one; it's implied by the declaration that a
*person* (not just anything) can be a man.

Here's the catch. The compiler is going to have to be able to evaluate these
rules -- at compile-time, I mean. Not *every* rule! Just the simplest ones:
the ones with a logical condition and a decide yes/no. The compiler is
already building decision trees, so this shouldn't be a stretch.

So when the Steve object comes along, the compiler thinks: is Steve a man? I
see two rules about that, and they're simple: the answer is clearly yes. Is
Steve a person? Two rules about *that*, and again, the answer comes out yes.

In this way, the compiler works out the membership of every *simple
immutable boolean property.* Those are our kinds, right? And then it can
simply *observe* that the set of men (in the game) is a subset of the set of
people.

Notice what I've done. A simple I7 declaration ("a man is a kind of person")
set up three different things: a subset relationship, a rule precedence
decision, and a way to declare objects.

I've broken this down into independent stages. The declaration sets up
rules. The rules are sucked into the compiler, which then lets you declare
objects based on them. The objects in turn are then observed, and the
compiler determines the subset relationship. Finally, the subset implies a
rule precedence.

Heck of a lot of extra work. The payoff: at every stage, we get
*first-class* language objects, which can be customized -- or even created
from scratch -- by the game author.

For example, the author could type those four implicit rules I quoted
earlier -- have them as *explicit* rules in his game. They would have
exactly the same effect as "A person can be a man. Steve is a man." Or, the
author could skip around the implication, and simply say "Steve is a person.
Steve is a man." Again, same effect. The subset relation is no longer
declared anywhere in the source code, but it's still *true*, so the compiler
can still correctly assess the precedence of "man" vs "person".

And we get "multiple inheritance" for free. It's not even complicated crazy
C++ multiple inheritance. Just say "Steve is a door." Now he's a door, a
person, and a man all at once. All the appropriate rules will apply --
what's the big deal?

Sure, if you have a rule for describing a man and a rule for describing a
door, they'll conflict. (Neither set is a subset of the other. So no
precedence auto-resolution.) That's what you signed up for when you created
your freakish door-man. Resolve all the conflicts (by declaring precedence
manually) and get on with the game.

The other way to make your life harder is to have more complicated rules:

  Rule for deciding whether Steve is a man:
    if the turn counter is even, decide yes;
    else decide no.

This is a perfectly valid rule. But the compiler can't possibly work out (at
compile-time) whether Steve is a man. (Same goes if you have a "change Steve
to a man" statement somewhere in your program.) Nonetheless, as long as you
explicitly declare Steve to be a *person*, the compiler can still conclude
that "man" is a subset of "person".

Now, if you explicitly declared Steve to be a man but *not* a person, the
subset relation is no longer true. That could cause a bunch of rule
conflicts (which previously got auto-resolved) to pop to your attention.
Again, this is what you signed up for.

(By the way, the question of whether an object provides a value property is
itself a boolean property. The compiler can precompute that, if needed, in
the same way.)

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
When Bush says "Stay the course," what he means is "I don't know what to
do next." He's been saying this for years now.

** Tricky bit: circularity

This plan has some disadvantages. Or rather, it loses some advantages of the
current I7 model. One notably nice thing about the current model is that you
have a clear layering of operations. Properties and attributes are basic:
reading them is simple, changing them is always legal and never has side
effects. Adjectives, conditions, and rules are bits of code based on the
attributes and properties.

I've thrown all that away. There are only rules. Some of the rules depend on
(internal) Z-machine properties, but most of the rules are written in terms
of each other. E.g.

  Rule for deciding whether a thing is a man: decide no.
  Rule for deciding whether a man is a person: decide yes.

Nothing stops you from writing circular dependencies:

  Rule for deciding whether a person is a man: decide yes.

When the game tries to evaluate "if Steve is a man..." it's going to go
do-lally. Heck, the *compiler* has to evaluate whether Steve is a man --
*it's* going to go do-lally. We can't have that.

I think the compiler is going to have to do dependency checking. (Perhaps
only on the conditions of the rules, not the bodies.) If it finds a cycle,
it'll throw an error. If you use properties to emulate an inheritance tree,
there should be no cycles, so this won't bother you. Sane (non-circular)
forms of multiple inheritance will be fine also.

** Tricky bit: improper subsets

Another potential pitfall: say Steve is the only person in the game. (Ignore
the player-character for the sake of argument.) Now the set of men and the
set of people are the same thing: the singleton set of Steve. Neither is a
(proper) subset of the other.

So how can the poor compiler work out our old rule conflict?

  Rule for describing a person: say "It is humanoid."
  Rule for describing a man: say "Masculine!"
  Rule for describing Steve: say "Steve is a hunk."

It can't decide which condition is logically stricter than the others.
Indeed, the conditions are logically *identical*.

(Note that I am precisely describing the case where the compiler is
deciding, not which rule is an *exception* to the others, but which rule
*obviates* the others. Since Steve is the only man and the only person, the
two lower-precedence rules can never execute at all.)

This situation -- identical property sets, with conflicting rules based on
each -- wouldn't arise in a simple program. The author would just define one
for his purpose. But it *will* arise in IF development, from two possible
scenarios. (1) library-defined properties (such as "man", "woman", "person")
which are used by a game -- e.g. poor Steve. (2) a game which is part-way
through development -- the author has defined the Steve object, but not yet
gotten to Linda.

I'm not sure what to make of this problem. In the case of library
properties, it may be desirable for the library to have extra precedence
hints. ("Man is a subset of person unless the author messes with stuff.") In
the case of game development, the easiest solution may be for the author to
throw in the line "Linda is a woman".

** Tricky bit: iterators

I've talked about how boolean properties can take the place of descriptions,
either/or properties, and kinds: they serve the basic purpose of answering
the question, "Is X in set S?" But conditionals are actually only one of
three ways that I7 uses descriptions. The other two are assertions ("S are
T", when defining the game world) and mutations ("Now S are T", at some
point during the game.)

(I'm mutilating Graham's discussion of sentences in the "Formal Syntax of
Sentences" example of the I7 manual.)

The upshot, anyway, is that we don't just test a specific object for
membership in S. We also have to be able to iterate over S, to carry out
tests like "if any S is T" or "if all S are T". Iteration is also necessary
for mutations: "now all S are T."

The naive implementation of iteration is: iterate over the world, testing
each object for membership. That's slow, of course. Fortunately, for many
properties -- the simple, immutable ones -- the compiler has already
computed which objects do and don't have them! So it can optimize these, by
storing arrays or linked property chains. It may be able to optimize more
complex cases as well: if a property-set S definitely contains ten objects,
and might contain five more (because those five change S during the game),
it's worth storing the list of fifteen potentials.

(As usual, it's worthwhile for the compiler to pay attention to which
iterations the game calls for. If no game operation applies to "all S",
there's no need to waste memory on a list of S objects.)

** One more tricky bit: ill-defined changes

The compiler needs to do a lot of reasoning for this system to work. This
puts some burden on the author to make sure the compiler has hard
information to work with. Mostly this means writing rules with meaningful
conditions. (Don't bury conditions as "if" statements inside rule bodies.)

A particular sore point is changes. If you write, at some point,

  Change the lamp to lit.

...then the compiler will know that the lamp may or not be lit during the
course of the game. However, if you do this:

  To illuminate a thing (T):
    change T to lit;
    say "The [T] begins to glow."

  [...and then, at some point...]  
  Illuminate the lamp.

...then the compiler has to assume that "lit" is a completely mutable
property; any object in the game may or may not be lit at some point. Now,
that isn't a disaster -- after all, the *current* I7 "lit" property is
mutable in just this way. But you wouldn't want to accidentally make
"container" or "player-character" into mutable properties; it would make the
container/player rules hard to manage.

(Yes, *in theory*, the compiler could trace the statement "Illuminate the
lamp" down into the function. But this is a big horrible task that we don't
want to get into.)

The worst case would be if you said:

  To mutate a thing (T) to a property (P):
    change T to P.

At this point the compiler decides that *every property* is mutable, and the
standard library probably catches fire and burns down.

** Not going there today: Relations

Having levelled most of I7's towering skyscrapers with my death-ray, I
suppose I should turn my attention to its newest and most modern: relations.

Maybe next week.

Really, this system already overlaps the role of relations. A property which
returns something is a many-to-one relation, by definition. I7 also has
conditional relations (which I can express as computed boolean properties of
two things).

However, I7 relations go to places that my properties haven't touched:
one-to-one relations, many-to-many relations, reciprocal relations, indirect
relations. I am not going to try to encompass all that stuff. Perhaps that
stuff can be built on top of properties in a useful way. Ask me some other
time.

** Summary of this scheme:

The following I7 mechanisms all become the same thing: properties (value,
text, and either/or); adjectives; kinds of thing; global variables;
constants.

(Kinds of value are not affected by this plan. Neither are regions and
scenes, which are implemented as Z-machine objects but are not things.)

The new "property" mechanism consists, formally, of a get(...) activity and
a set(...) activity, each of which applies to zero, one, or (perhaps) more
arguments. The get(...) may either return a value or take an action
(returning nothing). (Or act *and* return, I suppose.) Each such operation
is implemented by a rule (or group of rules).

(I am assuming that phrases, actions, and activities have already been
unified!)

A property can be constant (entirely determined at compile-time) or mutable
(determined by run-time code). An explicitly-changed property is just a kind
of mutable property. A mutable property may be based on computed values,
stored values, or both.

Properties of one thing are particularly handy, because the compiler can use
Z-machine properties/attributes (of the argument) to manage them.

*Boolean* properties of one thing are treated specially. Each such property
defines a set of things, and therefore an adjective (description). Where
possible, the compiler works out (at compile-time) the properties of every
object. It then works out which sets are subsets of which other sets.

The compiler must do additional work in this scheme. It must work out
properties and subset relations, as noted above. It must also look at the
dependencies of rules, and detect cycles.

Classic I6 attributes (container, supporter, closed, transparent, door, etc)
are no longer even slightly supported. Therefore, the standard verb library
has to get rebuilt from scratch. (About time, too.)

(A minor side benefit of this: the library is no longer maintaining
"mirrored" mechanisms such as the female attribute and the woman kind, the
door attribute and the door kind, the supporter attribute and the supporter
kind, etc. There's one property for each of these.)

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
When Bush says "Stay the course," what he means is "I don't know what to
do next." He's been saying this for years now.

So when will the beta be out?

David C.

Okay - real response.

I think a pure rule-based IF system is a fantastic idea. Is it
something you just start hammering out or is it something you create a
mailing list for and start writing up details first? Some sort of
specification.

David C.

There are still enough pieces missing (e.g, the rule precedence stuff
that I've been talking about forever) that I don't see a way to start
messing with it.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because of the Eighth Amendment.

Not exactly. "Steve is a person. Steve is a man." implies a
multiple-inheritance relation, not a subset relation, just like "Steve
is a man. Steve is a door."  To get the subset relation you HAVE to
have a "A person can be a man" or "All men are persons" or something
equivalent; some way to know that there's a connection between men and
persons. Otherwise it's all multiple inheritance relations.

Am I wrong?

Here's a different way to go nuts:

Rule for determining if a thing is Steve: decide yes.

You missed a step. You get the subset relation by looking at the
complete set of objects in the game:

  Steve: person, man, flammable
  Linda: person, woman
  Floopies: animal, dog, poodle
  brass lantern: flammable

And then "man" is *observably* a subset of "person". No attempt is made
to reason from the declarations to the subset ordering.

(This is why I put in the caveat about improper subsets. In the above
list of objects, there is nothing to tell you that "poodle" is
notionally a subset of "dog". In this game, they're the *same* set.)

Roger Carbol commented "Rule for determining whether something exists:
if its name is Steve, decide yes". These are both terrific ideas (at
somewhat different angles), which I'm not sure have practical value. I
frequently want to customize the definition of "door", "open/closed",
etc. I do not find myself wanting to twiddle the existence of objects
in a game, or what I (as a programmer) call them. But perhaps this is
an approach to dynamically creating game objects, in a game platform
which supports that?

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because of the Eighth Amendment.