As is, we must use a To phrase (and global variables) as a go-between, just as the "can see" and "can touch" relations do. But this is such a powerful pattern that I feel it merits fluid expression:

The friendship rules are a rulebook.
Likability relates a person (called X) to a person (called Y) when the friendship rules succeed with X and Y.
A friendship rule: if X is.....

I think of this compound construct as a very good "design pattern" for Inform 7, much like using an amendable table to define kinds-of-value while holding all of an extension's text for authorial replacement is a common pattern. Considering all the places a relation can appear -- Understand tokens, repeat loops, rule headers, etc. -- and how vital rulebooks are to the extensibility and power of the language, tying them together seems natural.

When you use block value types (indexed text etc) the code a phrase produces is actually placed in a SHELL function, with the head rule function instead being used to initialise the block value and close it down when finished.

It would be useful to be able to do this with other functions. I am having a look at refactoring Flexible Windows, as it is very slow because every time you change a window it runs a bunch of code. If we could use the same sort of stuff as block values do, then the window configuring could run once, accounting for several changes at once.

Similar to invocation phrases, I suggest the following syntax:

To foo: ...

To foo -- initialising: ...
To foo -- finalising: ...

If multiple to foo phrases are used in one rule, they would collectively only run the initialising and finalising code once.

Currently writing "Let Cave be a room." outside a rule raises a problem report that "You wrote...but I can't find a verb here that I know how to deal with, so I am ignoring this sentence altogether."

This might be a little hard to understand for anyone who hasn't absorbed all the relevant documentation. I7 takes great pains to produce helpful messages, which is the only reason this one stands out.

A more tailored message would be splendid, a la "You wrote "let Cave..." but that suggests that Cave should be or begin a temporary name for something. I expected to see an assertion (such as 'Mr Jones is a man') rather than a variable declaration ('let Mr Jones be a man')."

(This was originally a bug report, but jesse suggested moving it here. See http://inform7.com/mantis/view.php?id=594 for original post.)

The problem is that MoveFloatingObjects is not sufficiently flexible for extensions that want to make new and better kinds of backdrop.

Way back in the I6 days, the MoveFloatingObjects routine would call "i.found_in()" to decide whether i should be in or out of the location. But in the rewrite to the template system, this was changed to:

address = i.&found_in;
m = address-->0;
if (m.call(real_location) ~= 0) ...

The difference is that the old way set "self" to i (for the duration of the call). The new way sets "self" to m -- the address of the I6 function being called. (Due to the semantics of the I6 ".()" operator.)

This is fine for I7's backdrops and doors. However, if you want to write a clever extension in which the found_in function invokes some object-related code, you're hosed, because "self" doesn't refer to the object. (I.e., you can't invoke an object-based rulebook or look up some property of the object, to decide whether the location is in or out.)

This has broken the "Conditional Backdrops by John Clemens" extension, for example.

I do this all the time. Consider the following code:

Check an actor going (this is the automatically open closed doors rule):
if the door gone through is not nothing and the door gone through is closed:
if the actor is the player, say "(first opening [the door gone through])[command clarification break]";
silently try the actor opening the door gone through.
if the door gone through is closed, stop the action.

Note the full stop after the "silently try the actor opening the door gone through" command. The compiler should be able to detect the invalid command after the full stop and issue a (more helpful) error message. Something like:

You wrote 'if the door gone through is closed, stop the action.' indented as though it was part of the automatically open closed doors rule: but the full stop at the end of 'silently try the actor opening the door gone through.' means that it can't be. This line doesn't make sense in a general context either, so I'm stuck...

A long-running complaint about IF systems is that every new release of a game breaks compatibility with old save files. This is a manageable nuisance with old-fashioned native interpreters -- you can keep your old game files, or delay upgrading until a convenient time. A web interpreter gives the player no control: the author installs an upgraded release, and players find that their save files have effectively disappeared.

True backwards compatibility of save files is a very difficult problem (which is why this is a *long-running* complaint). It requires much more game file introspection than Zcode/Glulx currently provide, and that only hands a hellish data management problem to the game author. So I will not address it here.

A possible end-run around the abyss: allow a Blorb archive to contain *both* the old release and the new release of the game file. This allows the player to keep using old save files, albeit without the benefit of the game's bug fixes.

There are three parts to this plan:

- Add a new (optional) chunk usage identifier to Blorb, for old game files. The usage ID would be 'Exed', for the past tense of 'Exec' (and a dim L'Engle pun). The format is exactly the same as 'Exec'. There can be multiple 'Exed' chunks, for multiple old releases; their order and index number doesn't matter.

(This could conflict with the hypothetical use of multiple 'Exec' chunks for a single game. But I don't believe anybody's using that option.)

- Add an I7 statement, such as the following

Release along with previous release "old.blorb".
Release along with previous releases "old.blorb", "older.blorb", and "oldest.z5".

The named files would have to be provided in the Materials folder. The I7 toolchain would then find these files, extract the 'Exec' chunks (if necessary), and pack them in as 'Exed' chunks.

- To support this feature, an interpreter would notice the 'Exed' chunks. When the player types "restore", the interpreter would offer a list of save files that match *any* of the available game files ('Exec' and 'Exed'). (Quetzal game-file fingerprints are sufficient for this task.) Obsolete (Exed-matching) game files would be listed with a footnote: "This save file is for an old release of the game. You may encounter bugs that are fixed in the current release." If the player selects one anyway, the interpreter switches to the matching obsolete game file to play.

Also, when the player types "restart", the interpreter would jump to the current (Exec) game file, if an older one was in play.

I-crossing details:

- In Glulx, when the interpreter jumps between game file releases, it should close all Glk windows and streams and so on. (Normally the interpreter does *not* close these at restore/restart time.) This may cause some ugly display-flicker, but better to be safe about window and stream assumptions. (A hard enough problem within a single release.)

- We're packaging the old game file, but *not* old suites of sounds and images. So the author will have to handle that aspect of backwards compatibility. Simple rule: don't rearrange or delete sound and image resources, if you plan to use this system. Only add new ones.

- Using this system means that your blorb file will grow with every release. I think this is a cheap price, even for the half-assed solution I am proposing. Disk space is cheap even on mobile devices. (Memory is not, but in this system, the interpreter only needs to keep one copy of the game file in memory at a time.)

Currently it's tricky/annoying writing new accessibility rules because one has to separately check the requirements on noun and second noun, as shown in the "Electrified" example:

if the action requires a touchable noun and the noun is electrified, say "You fear touching [the noun]." instead;
if the action requires a touchable second noun and the second noun is electrified, say "You fear touching [the second noun]." instead.

But internally I6 does have the information about which object-that-needs-touching we're looking at. We just need to expose it to I7, with something like

To decide what object is the touching goal: (or some much better term)
(- (untouchable_object) -).