Changes to Inform

Chapter 1: Introduction

Chapter 2: Build 6M62

Chapter 3: Build 6L38

Chapter 4: Build 6L02

Chapter 5: The Inform application

Chapter 6: Documentation and Index

Chapter 7: The Inform language

Chapter 8: The Standard Rules

Chapter 9: Other features

Chapter 10: Maintenance

Chapter 11: Earlier builds

Chapter 1: Introduction

§1.1. Preface

§1.1. Preface

Inform is a project under active development, both by its original authors and by users who contribute extensions. Besides that, it belongs to an ecosystem of related tools and projects, and they develop, too.

So Inform is periodically reissued in new versions, or "builds". Builds of Inform are identified by four-character codes: number, letter, number, number. Builds are always accompanied by a detailed if sometimes technical "change log", laying out what's new. You're now reading a collection of these change logs, going backwards in time to build 4S08, which was really the first version of Inform 7 considered solid enough for regular rather than experimental use.

Note: Throughout this document, bug numbers in the seven-digit form "0000123" refer to tickets at the Inform bug tracker: http://inform7.com/mantis/. Suggestion numbers, also large but not starting with a 0, refer to tickets at Inform's Uservoice forum, a public venue for suggestions to be made about future features: http://inform7.uservoice.com/.

Chapter 2: Build 6M62

§2.1. About build 6M62 (December 2015); §2.2. Minor new features in the language; §2.3. Inform for Mac OS X; §2.4. Inform for Windows; §2.5. Inform for Linux; §2.6. Source text and punctuation; §2.7. Extensions; §2.8. Assertions and creations; §2.9. Model world; §2.10. Properties; §2.11. Relations; §2.12. Actions; §2.13. Rules and rulebooks; §2.14. Lists; §2.15. Tables; §2.16. Scenes; §2.17. Kinds and typechecking; §2.18. Phrases and functional programming; §2.19. Equations, units and arithmetic; §2.20. Understanding; §2.21. Glulx issues, file I/O, figures, sounds; §2.22. I6 template layer and inclusions; §2.23. Text, spacing and printing; §2.24. Indexing; §2.25. Testing commands; §2.26. Releasing, bibliographic data, and cBlorb; §2.27. Extension maintenance; §2.28. Examples maintenance; §2.29. Interpreter maintenance

§2.1. About build 6M62 (December 2015)

This is for the most part a maintenance release of Inform, incorporating fixes for nearly 300 issues reported with the previous build. All bugs reported before 3 September 2015 (and most later ones) have been removed. Fans of bugs need not despair, however, as the code has internally been much rewritten, so new ones will doubtless appear.

A modest selection of minor improvements to the underlying language can be found below, but little is fundamentally altered.

The Mac OS X user interface application sees two new developments in this release. One is the new concept of an "extension project", intended for writers of Inform extensions, which manages the extension source text better, and can automatically test the extension's examples of usage, which should make maintenance easier. The other development is that the previous Skein and Transcript panels have been merged together into one, simply called Testing, with a much clearer and simpler user interface. As in the past, some of these developments are likely to appear on other platforms in due course, but users should expect this to take a little time.

Many users gave up their time to report bugs in 2014/15, and we're grateful to all of them, but a particular tip of the hat goes to Daniel Fremont, who not only tested many obscure corners of the language but also combed through the documentation for out-of-date usages. It is thanks to Daniel that we learned that repeating the sentence "Foo is a room." 117030 times would crash the compiler, and that the documentation made what he called "a 300 sextillion kg error in the mass of Jupiter" (in our defence, that makes less difference than you might expect); and, at Daniel's urging, we did indeed "pick a consistent spelling for 'discombobulate'".

§2.2. Minor new features in the language

* Usage of the "stored action" kind has been streamlined considerably. For one thing, it can now be called simply "action". As when "indexed text" and "text" became the same thing, so too "action" and "stored action" are now synonymous. Constant actions no longer need to be written using the "action of" phrase, so for example these usages are now legal:

The best idea yet is an action that varies.

When play begins:
    now the best idea yet is pushing the button.

Previously one had to call it a stored action that varies, and one had to say "now the best idea yet is the action of pushing the button". The "action of..." phrase still exists, to keep old source text working, but it now has the following comically redundant definition in the Standard Rules:

To decide what action is the action of (A - action): (- {A} -).

* In past builds, switch-like ifs were valid only for simpler kinds of value such as numbers; they can now switch on any value, and in particular on texts. For example:

if the new password text is:
    -- "xyzzy": say "Nothing happens.";
    -- "password": say "Would you care to accept a position at the NSA?";
    -- otherwise: say "Accepted."

* Two minor improvements to the handling of named constants, which are relatively new in the language.

(a) The number of blank rows in a table can now be specified using a named constant, like so:

The spare capacity is always 10.

Table of Stuff
whatever (a number)
with spare capacity blank rows

The named constant must, of course, hold a non-negative integer. Note that it is allowed to be 0, which adds no blank rows. Inform doesn't allow completely empty tables, so if, as in this case, there are no explicit rows and the name comes out to 0 as well, Inform quietly gives the table a single row of blanks, but does compile it. (See bug report 0001724.)

(b) Map connections can now be made to or from rooms referred to by named constants, not explicitly as usual. Thus:

The Lounge is a room.
The designated room is always the Lounge.
The Exit Area is east of the designated room.

places the Exit Area east of the Lounge.

* When one action is converted to another one inside the Standard Rules, as most often happens when "removing X from Y" is converted to "taking X", and the action then succeeds, the after rulebook for the original action is now followed. For example,

Some coins and some bills are in the tip jar.

After removing something from the tip jar:
    say "Alice is shocked at your bold impropriety."

will now work as might be expected from its wording. (This was filed as bug report 0001476, but it was really a feature request.)

* A new Understand token "[any things]" is a sort of cross-breed between "[any ...]" and "[things]", in that it behaves like "[things]" (accepting a multiple object) but with no restriction on scope, that is, applying to anything however distant or invisible, as with "any". (This was suggestion 751340.)

* A new text substitution for adaptive text:

[regarding N]

makes it easier to write responses such as the parser error internal rule (Q):

"[if number understood is 0]None[otherwise]Only [number understood in
words][end if] of those [regarding the number understood][are] available."

which inflects the verb to agree with the number.

* A subtle change to the rules on kind inference: if a temporary value X is created with "let", in the shape

let X be V;

then Inform gives X whatever kind V has - for example, "let X be 10" will make X a number, and so on. Traditionally, though, if V is any kind of object, X has the kind "object", not something more specific. This is so that sensible-looking source text like this:

let X be Peter;
now X is Jane;

...won't cause a problem message. If X is given the kind "man", the kind of Peter, then the "now" can't be allowed because Jane has kind "woman". In previous builds, then, Inform gave X the kind "object".

The change is that it now gives X the right top-level kind of object, instead of "object" itself. In the case of "let X be Peter", X will now be given the kind "thing", because Peter has the kind "man", but man is a kind of person, which is a kind of thing, and thing is a kind of object. More generally, where X would once have been an "object", it will now be one of "thing", "room", "region" or "direction". This removes a number of small annoyances (see for example bug report 0001501).

* Most phrase definitions are not case sensitive, but an exception is made for text substitutions where there are different definitions depending on whether the first word is capitalised or not. This enables "[the X]" and "[The X]" to have different meanings. In the new build, case sensitivity has been extended to cover all text substitutions whose definition is a single letter. This means that "[S]" will no longer be misread as if it were "[s]", the notation for an optional "s"; so source text such as

let S be 10;
say "S is [S].";

will no longer peculiarly say "S is s." or "S is .", but will say "S is 10." (Prompted by bug report 0001492.)

* In past builds, the adjective "empty" couldn't usefully be applied to relations created in sentences in the usual way; for example, given

Noticing relates various people to one person.

the condition "the noticing relation is empty" and the instruction "now the noticing relation is empty" weren't allowed. They now are. (Prompted by bug report 0001416.)

* A new rulebook has been added:

multiple action processing rules

This is called when a command would produce a multiple action, such as TAKE ALL. Rules in it can then take the opportunity to look at the list of objects to which the action would apply, and can change or rearrange this.

* "Understand" can now apply to descriptions of values. For example,

Understand "glowing" as something lit.

now works; previously this could only be done with the circumlocution

Understand "glowing" as a thing when the item described is lit.

(Prompted by bug report 0001796.)

* The following rules have been added to the Standard Rules:

(a) The "describe what's on mentioned supporters in room descriptions rule" improves the look of room descriptions when a non-scenery, non-undescribed supporter is holding up one item that has an initial appearance and another that hasn't, and is for some reason mentioned in that first item's initial appearance; this parallels the existing handling of scenery supporters.

(b) The "exclude indirect possessions from take all rule" means that TAKE ALL won't try to take items which are inside open containers already being carried, and so forth. (See bug report 0001474.)

* The following existing rules in the Standard Rules have changed:

(a) The "standard taking rule" has been extended to add:

if the actor is the player, now the noun is handled.

This ensures that even items only fleetingly carried are "handled"; in previous builds, a successful taking action might not result in an object being "handled" if it were then lost again before the end of the same turn. (This can happens as a result of implicit takes. See bug report 0001460.)

(b) The "immediately undo rule" has a new response (F) which reports that the interpreter's UNDO capacity has been exhausted. (See bug 0001689.)

(c) The following existing responses in existing rules have been made adaptive (see bug report 0001715). Old and new definitions are as follows -

basic visibility rule response (A)
    "It is pitch dark, and you can't see a thing."
    "[It] [are] pitch dark, and [we] [can't see] a thing."

block climbing rule response (A)
    "I don't think much is to be achieved by that."
    "Little [are] to be achieved by that."

parser nothing error internal rule response (B)
    "There are none at all available!"
    "[There] [adapt the verb are from the third person plural] none
    at all available!"

(d) The "announce items from multiple object lists rule" now has a new response (A), which is responsible for the traditional format of the text dividing up replies relating to different objects (see bug report 0001762). This has the value

"[current item from the multiple object list]: [run paragraph on]"

and is responsible for e.g. "yellow marble: " and "red marble: " in -

yellow marble: Taken.
red marble: Taken.

Being a response, it's now customisable. For example,

The announce items from multiple object lists rule response (A) is "[current

action]: [run paragraph on]".

leads to

taking the yellow marble: Taken.
taking the red marble: Taken.

* The implementation of integer square root and cube root has been improved, so that Glulx's floating-point operations are used if available. This is faster and normally more accurate. (See bug report 0001547.)

* When releasing with an existing story file, this file can now be named:

Release along with an existing story file called "Zork1_sg.z5".

(Previously it had to be "Story.z8".)

* A clarification: a list is sayable if and only if its contents are sayable. In previous builds lists were always sayable, but would produce meaningless output if the contents weren't sayable (for example, for a list of topics).

* A clarification: creating kinds of direction is not allowed, and it now produces a problem message rather than failing more obscurely. (See bug 0001588.)

* A clarification: in past builds the documentation said that literal patterns could contain up to 4 parts; internally, the limit was 16, but would not always work correctly for high values; the limit is now set at 8.

* The "phrase" token works differently. This was undocumented and unsupported, and was to have been removed entirely in this build; but the extension "Hypothetical Questions by Jesse McGrew" turned out to use it regardless of its unofficial status, and the popular "Consolidated Multiple Actions by John Clemens" made use of this in turn. We have therefore retained it, a little reluctantly. Even so, its use has been somewhat restricted: it can't accept control constructs such as if, while, repeat, otherwise, now, or say. On the other hand it expands in a more predictable fashion, without generating braces which are problematic to deal with. It nevertheless remains an unsupported feature of Inform, and there's no guarantee it won't change.

§2.3. Inform for Mac OS X

Firstly, the Mac OS X application has made the transition to 64 bit only. This change only adversely affects users who are still running OS X 10.6.8 on 32 bit hardware. Users of Inform on OS X 10.7 and above are still fully compatible (because by definition they are already running on 64 bit hardware). Similarly, users still running OS X 10.6.8 on 64 bit hardware should remain compatible. This change is made to help improve stability and smooth future development.

New to this version is the Testing panel (which replaces the old Skein and Transcript panels of previous versions). The Testing panel is designed to help ensure the story consistently responds as expected while the development of the source continues. The Testing panel consists of ‘knots’ - all commands that have on previous occasions been played in the story with their associated response text. Knots are displayed in a branching fashion - knots lower down the panel are later in the story than those nearer the top. Each knot’s response text can be ticked (‘blessed’) to signify that it is correct (i.e. as expected). Any deviation from the blessed text in future plays of the story will be shown on the knot with a red star, and the differences highlighted in the response text itself. Each knot has a menu of options. Knots can be dragged and dropped onto other knots to be copied or moved, even onto other projects. Undo is supported. A Help section of the Testing panel describes each element. The Play All button allows all knots to be automatically played in the story.

Also new to this version are Extension Projects. Extension Projects are designed to help developers of Inform extensions. An Extension Project can be created from an existing extension or from scratch. The extension’s source can be edited, its ‘examples of use' played and tested individually, or all its examples tested automatically. The extension can then be installed or exported as required.

A smaller improvement is that the story is now only recompiled on ‘Go!' if needed, for example because its source text has changed.

Bug fixed (0000089): 'More...' overlay is not properly hidden.

Bug fixed (0000378): Bug with CocoaGlk and the Automap extension.

Bug fixed (0000538): Problems with Skein and Transcript panels - now rewritten and replaced with the new Testing panel.

Bug fixed (0000545): Problems with Skein and Transcript panels - now rewritten and replaced with the new Testing panel.

Bug fixed (0001076): Invisible characters in source text editor.

Bug fixed (0001093): glk_buffer_to_title_case_uni crashes in Mac IDE interpreter.

Bug fixed (0001111): CocoaGlk: The built-in interpreter becomes unresponsive after RESTART.

Bug fixed (0001189): CocoaGlk crash when measuring an unhinted style.

Bug fixed (0001404): Crash with VoiceOver enabled.

Bug fixed (0001437): Issues with 10.6.8 resolved.

Bug fixed (0001481): Issues with 10.6.8 resolved.

Bug fixed (0001641): Double-clicking the "Go!" button causes an I6 error.

§2.4. Inform for Windows

The progress bar shown when compiling a story (or downloading extensions) is now rather more prominent, and shown in the middle of the window.

The toolbar icons have been updated to match the OS X front end. This has also involved removing the "Stop" button from the main toolbar. Instead this can now be found as a button on the "Story" tab.

Two bugs have been fixed: 0001418 and 0001511.

§2.5. Inform for Linux

The GUI code is no longer hosted on SourceForge. The place to go is now GitHub (https://github.com/ptomato/gnome-inform7). The location for official downloads — the Inform website — has not changed.

Inform on Linux can be used in with a GUI in French and Spanish, following a bug fix. Those wishing to help translate the GUI into other languages can now visit Transifex (https://www.transifex.com/ptomato/gnome-inform7/).

* Packaging issues fixed; thanks to Vincent Petry and Bart Massey for contributing these fixes.

* Trying to open a nonexistent story from the recently-opened list will now remove that story from the list (0001732).

* Bug fixed (0001612) whereby the Public Library had stopped working.

* Bug fixed (0001446) whereby extensions marked "for Glulx only" were installed incorrectly when downloaded from the Public Library.

* Bug fixed (0001497) whereby code pasted into the story caused extra indentation to be inserted.

* Bug fixed (0001757) whereby some Inform 6 code was highlighted incorrectly.

* The correct version of Glulx Text Effects is included with this release (0001447).

* A few bugs fixed that caused crashes in certain circumstances: 0001286, 0001406.

[Chapter: Maintenance in build 6M62]

§2.6. Source text and punctuation

Bug fixed (0001520) whereby a source text opening with a colon would throw an internal error rather than a problem message.

Problem messages added (see 0001521) to catch various punctuation accidents: colons at ends of paragraphs or sentences, and semicolons at ends of sentences or following colons or full stops.

Bugs fixed (0001523, 0001529) whereby instances and rules whose names included brackets would sometimes throw internal errors rather than problem messages.

Bug fixed (0001797) whereby a plural consisting entirely of a bracketed text, such as "The plural of wug is (nothing).", would throw an internal error rather than a problem message.

§2.7. Extensions

Bug fixed (0001537) whereby overlong extension or author names in Include sentences would cause Inform to issue a problem message (correctly) and then end in exit code 2 or 11 rather than 1.

§2.8. Assertions and creations

Bug fixed (0001610, 0001617) whereby source texts making very repeated use of creation sentences would crash (e.g., at least 117030 copies of the sentence "Foo is a room.").

Bug fixed (0001588) whereby attempts to create nameless instances of subkinds of "direction" would crash Inform by repeating the same problem message until the stack ran out.

Bug fixed (0001600) whereby creating objects with very long names would lead to unexpected problem messages about quotation marks.

Bug fixed (0001571) whereby constants left undefined would sometimes lead to I6 errors rather than problem messages.

Bug fixed (0001572) whereby constants defined indirectly in terms of themselves would throw an internal error rather than producing a clear problem message.

Bug fixed (0001539) whereby names containing long I6 inclusions (which is a very odd thing to try to do) would sometimes lead to internal errors.

Bug fixed (0001411, 0001532, 0001686) whereby a sentence using a relative clause to equate things would in some cases (e.g. "Zog is a person that is false.") produce an internal error.

Bug fixed (0001643) whereby changing the meaning of the verb "to be", not perhaps the wisest course in any event, would fail to produce the problem message for inconsistent verb definitions.

Bug fixed (0001558) whereby "There is an object." was rejected, rather than doing something not very useful (creating a thing called "thing" and placing it nowhere) as it should.

Bug fixed (0001587) whereby assemblies which create qualified common nouns would sometimes produce a bogus problem message about circular kind definitions.

Bug fixed (0001662) whereby adjective definitions using object names in their domains could under some circumstances produce a "cannot establish position P" internal error.

Bug fixed (0001667) whereby a sentence creating something "(called the)" or "(called a)" would produce an internal error not a problem message.

Bug fixed (0001672) whereby a nonsensical assertion like "Edible has bar" could crash Inform rather than produce a problem message.

Bug fixed (0001675) whereby a redeclaration of, say, a scene as a variable could sometimes cause an internal error not a problem message.

Bug fixed (0001658) whereby assertions about map directions, which are vague about the origin, could throw an internal error if the subject of discussion had changed to something which wasn't an object (e.g. by creating a new kind).

Bug fixed (0001693) whereby assertions about map directions which give the destination as a value other than an object would (usually) be ignored rather than throwing a problem message.

Bug fixed (0001683) whereby the map might come out with confused connections if directions were declared in an unusual order, mixed in with sentences making map connections using them.

Bug fixed (0001691) whereby some sentences creating things would be allowed even though they were said to be never or seldom true: for example, "In the Dining Room is never a door."

Bug fixed (0001580) whereby bare existential sentences with multiple objects, such as "There are X and Y", giving no relationships between X, Y and anything else, would result in nothing being created.

Bug fixed (0001593) whereby implications whose premiss is a negated adjective would sometimes have their sense reversed: e.g. "Something not lit is usually edible" would be read as if it said "Something lit is usually edible".

Bug fixed (0001685) whereby assertions in the form "Home contains X with P.", where P is a property, would sometimes have P ignored.

Bug fixed (0001456) whereby adjectives could be defined over topics, but with unfortunate consequences. There's now a problem to defend against this.

§2.9. Model world

Bug fixed (0001560) whereby creating 10000 or more objects in a single story would result in a "far too many relatees" error. There is now no upper limit, except of course the boundary between sanity and madness.

Bug fixed (0001665) whereby creating infinitely large assemblies of things connected to other things would pause for a very long time after issuing the problem message. Technically not a hang, but not a good use of our limited time on this Earth either.

Bug fixed (0001670) whereby implicit contradictions in one-to-various or various-to-one relationships caused by assembly might not result in problem messages being issued.

Bug fixed (0001671) whereby recursive assemblies of non-object instances would sometimes fail to recurse as they should, thus halting early. (In practice this would mean that circular assemblies of this kind wouldn't result in problem messages.)

Bug fixed - or really, convention changed (0001586) - so that if a room is made using "X is D of Y", where D is a direction with no reverse, then X is assumed likely to be a room in the absence of other evidence. Previously this happened only if D had a reverse. (This was because the convention was that assumptions were made only about the destination Y: when D had a reverse direction, un-D, the above sentence implied also "Y is un-D of X", and so X was also a destination.)

Bug fixed (0001639) whereby timed events occurring close to midnight would sometimes never arrive if the clock had been altered to jump from before them to after midnight between turns, e.g., by replacing the advance time rule.

Bug fixed (0001597) whereby putting a region initially inside a room was being allowed - it should of course produce a problem message, and now does.

A problem message has been added (see 0001687) to catch the inevitably disastrous consequences of making "container" a kind of "supporter" or vice versa; similarly (0001692) for making "door" a kind of "backdrop" or vice versa.

Bug fixed (0001607) whereby a proper-named person would, if his/her printed name were changed at run-time, sometimes be given the capitalised form of the original name in some responses.

Bug fixed (0001603) whereby an item marked "undescribed" would nevertheless be described if it both provided an initial appearance text and was found on a supporter. (See the "initial appearance on supporters rule".)

Bug fixed (0001493) whereby an item hidden through the use of the "deciding the concealed possessions of" activity would nevertheless be mentioned in the bracketed part of a list of objects, as in, "You can see an aquarium (in which are some pebbles and a goldfish) here.": in previous builds the pebbles would have been included even if the activity had said otherwise.

Run-time problem added (0001463) for testing the adjacency relation with regions rather than rooms. (Previously this simply gave unhelpful answers.)

§2.10. Properties

Bug fixed (0001528) whereby "of" used with an either-or property would sometimes be rejected with internal errors rather than problem messages.

Bug fixed (0001538) whereby adjective names containing brackets or quotes were rejected with internal errors rather than problem messages.

Bug fixed (0001524) whereby properties with very long names might crash Inform on declaration.

Bug fixed (0001540) whereby absurdly long property names caused internal errors not problems.

Bug fixed (0001772) whereby attempts to assign by something like "now V is P", where V is a variable of kind K and P is a property holding K, now produce problem messages rather than failing to compile through I6.

Bug fixed (0001564) whereby a verb which means a property would cause run-time problems when tested or asserted with "now", if the owner of the property was something other than an object.

Bug fixed (0001530) whereby a nonsensical property value could be given in a property list and it would be ignored rather than reported.

Bugs fixed (0001530, 0001657) whereby a property list giving a value which involved "with" might lead to an internal error.

Bug fixed (0001620) whereby giving a nameless property to a single instance of a non-object kind such as "scene" or "narrative viewpoint" would lead to an internal error. (It's legal to do this, and now works.)

Bug fixed (0001673) whereby giving a condition to something whose name contained the word "from" could lead to an internal error.

Bug fixed (0001652) whereby a property list attached to something which can't have properties could in some cases lead to an internal error not a problem message.

§2.11. Relations

Bug fixed (0001540) whereby absurdly long relation names caused internal errors not problems.

Bug fixed (0001552) whereby some forms of implicit reference to relationships such as "equality" could cause an internal error.

Bug fixed (0001676) whereby trying to use a relation's bare name as a description of things in a list would lead to an internal error rather than a problem message.

Bug fixed (0001583) whereby typechecking of the universal relation would sometimes give unexpected results when applied to other unusual relations (such as provision).

Bug fixed (0001583) whereby the provision relation can now be tested a little more freely with properties identified by variable.

Bug fixed (0001550) whereby some indirect uses of some built-in relations could produce meaningless results; they now produce a run-time problem.

Bug fixed (0001553) whereby various-to-one relations cannot always relate 0 to something, or other values internally stored as 0 at run-time.

§2.12. Actions

Bug fixed (0001525) whereby deficiencies in action descriptions assigned to named behaviours would sometimes be reported at the wrong line of the source.

Bug fixed (0001651) whereby a description of actions consisting only of an article would throw an internal error not a problem message.

Bug fixed (0001660) whereby certain very malformed descriptions of actions would throw an internal error not a problem message.

Bug fixed (0001496) whereby actions written as constants, for example in entries in a table, and which contained arbitrary text topics, would sometimes have those text topics lost when tried at run-time.

Bug fixed (0001469) whereby Inform would sometimes wrongly decide which form of asking was intended (asking for, or about?) in a phrase like "asking or telling Bob about...".

Bug fixed (0001789) whereby Inform would guess past participles of action names wrongly in the case of present participles like "playing", "slaying", "preying" or "toying", where the vowel A, E or I occurs before YING. These now correctly produce "played", "slayed", "preyed" and "toyed".

§2.13. Rules and rulebooks

Bug fixed (0001527) whereby rulebook variables declared with nonsensical kinds would produce an internal error not a problem message.

Bug fixed (0001629) whereby a rule with "in... while..." clauses might lead to an internal error not a problem message if not understood.

Bug fixed (0001666) whereby a timed event rule whose name consisted only of an article such as "the" or "a" would cause an internal error.

Bug fixed (0001591) whereby a rule with a "during..." clause describing the scenes to which it applied would not have this scene description properly checked, so that nonsensical clauses like "during three scenes" or "during a scene which is in the paper bag" would be accepted but then either throw I6 errors or fail at run-time.

Bug fixed (0001541) whereby rulebooks could be declared with indefinite kinds such as "value based rulebook". There's now a problem message.

Bug fixed (0001642) whereby rules would sometimes be allowed to "substitute for" other rules with incompatible kinds.

Bug fixed (0001470) whereby rules based on actions whose actor's name included a participle (say, "tough-looking coach") would sometimes be misread.

Bug fixed (0001508) whereby the syntax for declaring first/last rules for rulebooks with names beginning with "for" could be slightly erratic.

Bug fixed (0001748) whereby rulebooks couldn't produce something referred to using an indefinite article, e.g., "an object-based rulebook producing a list of texts" was being refused because of the "a".

§2.14. Lists

Bug fixed (0001618, 0001619) whereby a long list of constant action names could slow Inform's parser down to a crawl, or in extreme cases cause Inform to halt as having allocated too much memory.

Bug fixed (0001723) whereby an attempt at run-time to resize a list to a negative size would print a brief error into the transcript, but not throw a formal run-time problem message.

Bug fixed (0001503) whereby, under unusual circumstances, it's possible for removal of an item from a list to lead, some time later, to memory allocation or other heap-related errors.

Bug fixed (0001741) whereby lists of constant stored actions would sometimes not be allowed, with the actions being rejected as non-constant.

§2.15. Tables

Bug fixed (0001595) whereby including a large number of tables, with some of them nameless, would sometimes cause I6 errors due to I7 accidentally using the same I6 identifier twice.

Bug fixed (0001464) whereby a table entry holding an action which used a variable parameter somewhere would be accepted by I7 but then lead to I6 errors; it now produces a problem message.

Bug fixed (0001519) whereby trying to create a value defined by a table outside of that table would throw a problem message if it happened before the table in the source, but not if it happened after.

Bug fixed (0001542) whereby amending a table used to define things would sometimes produce the amended property values, sometimes the old ones. This is now ruled illegal, and there's a problem message accordingly.

Bug fixed (0001664) whereby a failed table amendment might produce an internal error not a problem.

Bug fixed (0001653, 0001654) whereby a duplicated column name in a multiple table continuation might produce an apparent hang not a problem.

Bug fixed (0001555) whereby sorting a table in order of a column holding real numbers would sort in order of increasing positive reals, then of decreasing negative ones, rather than in the obvious numerical order.

Bug fixed (0001706) whereby names of phrases used as constants in table cells would sometimes result in the kind of the table column being inferred too vaguely (as "phrase value -> value"), rather than using their actual kinds, so that it would then be difficult to use the column for anything without throwing kind-checking problems.

§2.16. Scenes

Bug fixed (0001711) whereby a sentence like "Scene A ends when Scene B ends interestingly" occurring before the declaration of Scene B's interesting end would throw a problem message saying the ending in question was unknown.

§2.17. Kinds and typechecking

Bug fixed (0001601) whereby a kind with a very long name would cause a crash once either a notation or some instances were created for it.

Problem messages improved (0001575) in being clearer about names not yet defined.

Bug fixed (0001509, 0001778) to do with matching a list of K against a list of L when L is a kind of K.

Bug fixed (0001495, 0001425, 0001448) whereby Inform would allow a text value to be assigned to a topic variable, but the result would be an I6 error about a nonexistent routine called TEXT_TY_to_UNDERSTANDING_TY, or in some cases a Glulx virtual machine error. Such assignments aren't legal, and there's now a problem message for it.

Bug fixed (0001648) whereby long expressions of what look arithmetic but don't in fact contain meaningful terms would cause Inform to run very slowly, or eventually run out of memory, rather than produce a problem message quickly.

Bug fixed (0001570) whereby adjective Definitions could define over kinds of kinds such as "sayable value", leading to problems later since this isn't type-safe. There's now a problem message.

§2.18. Phrases and functional programming

A local variable can't have the same name as a non-object kind. This was previously only sometimes enforced, due to a bug: it's now always enforced.

Bug fixed (0001526) whereby a phrase token containing a quantifier, such as "N - three numbers", would produce an internal error not a problem message.

Bug fixed (0001576) whereby a phrase with more than 10 tokens in its definition could crash the compiler.

Bug fixed (0001567) whereby the functions with mathematical names (such as "abs function") could not be used as constants, because a mysterious problem message would appear claiming that their definitions in the Standard Rules were unrecognised.

Bug fixed (0001613) to do with generic programming and the interpretation of kind variables when a phrase is used as a value which itself involves those variables: see the bug report for more.

Bug fixed (0001533) whereby Inform would fail to recover after a problem message involving a function kind declared with codomain equal to an undeclared kind variable, and would issue an internal error as well.

Bug fixed (0001674) whereby an implicitly circular adjective definition such as "Definition: a big number is big if it is 123." would crash Inform rather than produce a problem message.

Bug fixed (0001645) whereby duplicated cases in an "if ... is: --" switch would be allowed without warning. (They now cause a problem message, since they can never be useful.)

Bug fixed (0001646) whereby named constants couldn't be used as cases in an "if ... is: --" switch.

Bug fixed (0001583) whereby conditions using the present perfect or past perfect forms of some verbs would not be understood - for example, "X had provided Y".

Bug fixed (0001514) whereby "value", or other kinds of kinds, could be accepted where definite kinds were expected, resulting in undefined behaviour at run-time.

§2.19. Equations, units and arithmetic

Bug fixed (0001417) whereby arithmetic producing a dimensionless result after calculating with dimensioned operands would sometimes wrongly use integer rather than real arithmetic, so that, for example, 1500m divided by 10m would print out as 1.12552 × 10^9 not 150.0m.

Bug fixed (0001569) whereby Inform would sometimes crash after issuing a problem message in the event of dimensionally impossible arithmetic in the optional parts of an action description.

Bug fixed (0001625) whereby more part names could be given than there were parts to name.

Bug fixed (0001625) whereby multiple part names might be slow to parse.

Bug fixed (0001625) whereby cumulatively over-long part names would be rejected with a misleadingly worded problem message.

Bug fixed (0001625) whereby multiple part names could be identical. These now produce problem messages.

Bug fixed (0001561) whereby attempting to scale units by non-positive amounts produced an internal error not a problem message.

Bug fixed (0001589) whereby an equation defining three or more variables as having the same kind (e.g. "where a, b, and c are numbers") might lead to internal errors.

Bug fixed (0001562) whereby giving a notation to specify an arithmetic kind of value, with example value as an integer but scale factor a real number, would silently ignore the scale factor. There's now a problem message saying how to fix this to get the intended effect.

Bug fixed (0001649) whereby an equation with no name and no number would throw an internal error, not a problem message.

Bug fixed (0001644) whereby incrementing a variable containing an unusual arithmetic kind of value could in some cases cause an internal error.

Bug fixed (0001573, 0001574) whereby equations whose solution would require fourth or higher-degree roots would produce a spurious problem message about that power not being a constant number, or which would calculate out with the wrong answer by mixing real and integer arithmetic.

Bug fixed (0001582) whereby equations working out I^R, where I is a number and R a real number, would sometimes assign this to a number variable without converting it back from real arithmetic.

§2.20. Understanding

Bug fixed (0001414) whereby "[something related by R]" would, for a few exotic relations R such as "provision", throw an internal error. There's now a problem message.

Bug fixed (0001451) whereby AGAIN on the first turn would not produce a sensible reply on Glulx, though it would on Z.

Bug fixed (0001500) whereby the low-level I6 routine UnknownVerb would be called only if the actor in a command was the player. (This didn't affect regular English-language stories, where I7 doesn't use UnknownVerb.)

Bug fixed (0001604) whereby malformed instructions for people other than the player would sometimes result in no response at all.

Bug fixed (0001661) whereby an "[any any thing]" token, with unexpected extra quantification, would give an internal error not a problem message.

Bug fixed (0001694) whereby the "after reading a command" rulebook was run after some disambiguation questions are asked and answered, but not others. It should now consistently be run.

Bug fixed (0001475) whereby the use of a command involving "[text]", followed by THEN and another command in the same piece of typing, would cause that text to become a row of spaces.

Bug fixed (0001568) whereby the use of the "if the player consents" phrase, which asks for a yes/no answer, would invalidate the contents of the "player's command" variable.

§2.21. Glulx issues, file I/O, figures, sounds

The implementation of the Memcpy utility has been made faster on Glulx.

Bug fixed (0001429) to do with file input/output disrupting the Glulx output channel, since writing to a file would fail properly to reset the channel when finished. (Thanks to Dannii Willis for the patch to fix this.)

Bug fixed (0001506 but see also 0001502) to do with sound channels not being properly identified after a restore or restart.

§2.22. I6 template layer and inclusions

Bug fixed (0001578) whereby seemingly inconsistent combinations of use options ("Use scoring and no scoring") could lead to I6 errors.

Bug fixed (0001631) whereby I6 inclusions of more than about 600000 characters at a time would produce internal errors rather than problems.

Bug fixed (0001759) whereby use in an I6 inclusion of "ÿ", the largely mythical letter needed only by the band Queensrÿche and its devotees, would result in a spurious I6 error ("MAX_QTEXT_SIZE exceeded").

Problem message added (0001535) to do with using I6 inline definitions for named functions without I6 functions backing them up.

Problem message added (0001594) for overlong I6 definitions of adjectives and the like.

Problem message added (0001596) for broken attempts at template hacking.

§2.23. Text, spacing and printing

Bug fixed (0001397) whereby text substitutions for adapting modal verbs required the modified verb to take the third person, not the infinitive: which for regular English verbs made no difference, but meant that you had to write "[might are]" instead of "[might be]", for example.

Bug fixed (0001577) whereby ridiculously nested multi-part text substitutions could crash Inform rather than produce a problem message.

Bug fixed (0001599) whereby "say" statements including comma-separated lists of more than 4097 terms to be printed would lead to an internal error. There's now no limit on this: enjoy.

Bug fixed (0001637) whereby assigning a text to itself could corrupt its value, e.g., writing "now T is T" where T holds text which Inform has had to store in written-out form. (This could also happen with stored actions and some other kinds of value, but was most likely seen with text.)

Bug fixed (0001663) whereby attempting to display the empty text as a boxed quotation could crash Inform. (There's now a problem message instead.)

Bug fixed (0001606) whereby the you-can-also-see rule would, if running in the second person perfect tense, produce "You has been able to see..." instead of "You have been able to see..."

§2.24. Indexing

Bug fixed (0001428) whereby the coloured folder links in the Extensions panel wouldn't work - i.e., they could be clicked on, but wouldn't show the relevant location in the file system.

§2.25. Testing commands

Bug fixed (0001430) whereby "Test <case> with ..." would cause I6 errors if the case name were given in quotes. There's now an explanatory problem.

Bug fixed (0001491) whereby the ACTIONS command's output would produce gibberish when printing out some actions involving "[text]".

§2.26. Releasing, bibliographic data, and cBlorb

Bug fixed (0001413, 0001499) whereby releasing along with a named file would in some cases cause an internal error.

Bug fixed (0001713) whereby releasing with an image or audio file whose filename ends in a space or full stop might, on Windows, cause its file format (e.g. JPEG versus PNG, or AIFF versus OGG) to be wrongly guessed.

Bug fixed (0001494) whereby releasing with an existing story file wasn't working.

§2.27. Extension maintenance

"Glulx Image Centering" updated to version 4, to maintain compatibility with other extensions.

§2.28. Examples maintenance

Two new examples, "Western Art History 305" and "The Best Till Last", demonstrate the use of the multiple action processing rulebook.

§2.29. Interpreter maintenance

Inform comes with browser interpreters built in, so that it can act on release instructions such as "Release along with an interpreter.", which tell Inform to make a website in which the current story is immediately playable.

Parchment has been updated to 2015-09-25, fixing a bug (0001426).

Quixe has been updated to 2.1.2, as compared with 1.3.1 in the last two releases of Inform. This is quite a large improvement, since it takes in four successive releases of Quixe.

Chapter 3: Build 6L38

§3.1. About build 6L38 (August 2014); §3.2. Minor new features in the language; §3.3. Inform for Mac OS X; §3.4. Inform for Windows; §3.5. Inform for Linux; §3.6. Inform for Android; §3.7. Uncategorisable; §3.8. Headings; §3.9. Assertions and creations; §3.10. Model world; §3.11. Properties; §3.12. Relations; §3.13. Rules and rulebooks; §3.14. Lists; §3.15. Tables; §3.16. Equations, units and arithmetic; §3.17. Understanding; §3.18. Text, spacing and printing; §3.19. Indexing; §3.20. Testing commands; §3.21. Releasing, bibliographic data, and cBlorb; §3.22. Extension maintenance; §3.23. Examples maintenance

§3.1. About build 6L38 (August 2014)

Unlike its predecessor, build 6L02, this release of Inform is aimed almost entirely at maintenance: it fixes around 150 bugs, most of them minor and related to recent changes. Users of 6L02 should be able to upgrade with no preparation needed; users of earlier builds, though, would be well advised to read the notes on the big changes in 6L02 before proceeding.

But there is one major development, all the same: for the first time Inform is released for a mass-market mobile operating system - Android.

§3.2. Minor new features in the language

It was realised soon after the release of 6L02 that the text substitutions "[those]" and "[Those]" were ambiguous, since if they're applied to an object which is a man or woman then they would have to be different in the accusative and nominative cases. Consider the two texts:

"But [we] [aren't] holding [regarding the noun][those]."
"But [regarding the noun][those] [aren't] available."

and suppose the noun is Andrew. Then "[those]" needs to expand as "him" in the first case but as "he" in the second. To distinguish these,

"[those in the nominative]"
"[those in the accusative]"

and similarly for Those. But what should plain "[those]" and "[Those]" do? We note that the Standard Rules used "[those]" in 7 responses, all accusative, and "[Those]" in a further 12, all nominative. Accordingly, Inform now defines "[those]" as equivalent to "[those in the accusative]" and "[Those]" as "[Those in the nominative]". This fixes bug 0001232, and though it's not a perfect solution, it's intended to be something we might revisit when Inform has a better idea of noun cases (as it will need for, say, adaptive German). Note that "nominative" and "accusative" are the two values of the kind "grammatical case"; "nominative" existed in 6L02, but "accusative" is new in this build.

The real square root function can now be applied to any numerical quantity for which the dimensions (in physics terms) are a perfect square. Thus, if we're using the Metric Units extension,

the real square root of 4 sq m

produces the length "2.0m". This also means that equations such as:

Equation - Pythagoras's Theorem
a = root (b^2+c^2)
where a is a length, b is a length, c is a length.

can be solved for "a"; this previously failed because "root" could be applied only to dimensionless numbers. (See also bug report 0001264.)

The following are now equivalent:

[1] A food is a kind of thing which is edible.
[2] A food is a kind of edible thing.

(Previously [1] was allowed, but [2] was disallowed.)

Action descriptions like the following are now rejected:

Instead of taking seven things: ...
Instead of taking the teddy bear on the dresser: ...

The first case is rejected because a single noun can't be "seven things", and the second because "the teddy bear", a proper noun, is being used as if it were a common noun. ("a thing on the dresser" would be fine.) Previous builds of Inform allowed these, but compiled misleading tests: e.g. the latter would simply test whether the teddy bear was on the dresser, regardless of whether or not it was the thing taken.

It is now officially illegal to create something new with one of the following reserved names:

action, condition, list-entry, now-condition, phrase, property-value, storage, table-reference, variable

These all have internal meanings and it's unlikely to be safe to create anything with these names, though in some cases one might be lucky. (The example "Greater Variety", for instance, created a table column named "action" in 6L02 and got away with it; this column has been renamed. See bug report 0001347.)

It is now officially illegal to define a phrase which looks like "X is (a relationship) Y". For example,

To decide whether (X - testval) is less than (Y - testval):

is now disallowed, because there's already a meaning of "To be less than". (See bug report 0001230.)

When replacing a heading from an extension, it is now possible to put the heading name in quotation marks for clarity. For example:

Section - Another Questions fix (in place of "Section 4 - Phrase used to ask questions in closed mode" in Questions by Michael Callaghan)

(Without quotation marks, the grammar is ambiguous, because of the "in" in the name of the heading. See bug report 0001239.)

It's now legal to test actions against kinds of actions in a more flexible way. For example:

Attacking is aggressive behaviour. Examining is inquisitive behaviour.
[1] Before aggressive behaviour: ...
[2] Before doing something other than aggressive behaviour: ...
[3] Before aggressive behaviour or inquisitive behaviour: ...
[4] Before aggressive behaviour or jumping: ...

Previously only rule [1] would have been allowed. (This was prompted by bug report 0001244, though that was arguably a suggestion in disguise.)

The "backtrace" problem messages arising from ambiguous possible phrases, which list what Inform was trying to read, have been redesigned a little.

The default contents of the following two responses have changed:

list writer internal rule response (R)
list writer internal rule response (T)

in each case to remove an open bracket at the beginning; this open bracket is instead displayed using list writer internal rule response (A) first. The practical effect of this is that only two changes are needed to make the list writer always use, say, square brackets instead of round ones:

The list writer internal rule response (A) is " [bracket]".
The list writer internal rule response (B) is "[close bracket]".

(See bug report 0001344, to which this is related.)

I6 template files can now be installed in Inform's external resources folder, in a subfolder called "I6T". Inform first looks for these in Project.materials/I6T, then in (external)/I6T, and lastly in its own built-in reservoir. This is a change nobody actually asked for, but it makes everything consistent since the same convention is followed for Language bundles, website Templates and Extensions.

§3.3. Inform for Mac OS X

6L02 introduced an almost entirely rewritten user interface, and inevitably there were a few bugs: the Installed Extensions list redrew awkwardly, flashing content (0001238); entering full screen mode could leave the Find dialog stranded behind (0001252); save panels from the Welcome window were not sufficiently explanatory (0001273); clicking on extension names to bring up their documentation worked badly (0001237); unchecking the "bind up into a Blorb file on release" option on the Settings pane had no effect (0001306); Inform crashed on launch under Snow Leopard (0001271); IFIDs were not persistent, defeating their purpose (0001278); headings at the top of the source text were not correctly rendered on screen (0001331). These are all fixed.

§3.4. Inform for Windows

A new option, "Generate Inform 6 debugging information", has been added to the preferences dialog. This option controls whether the command line used to run Inform 6 specifies that the debugging output file should be created, and defaults to "off".

The Extensions tab is now implemented, providing access to the Public Library.

"Create new project" buttons are present in the documentation, next to example projects.

The elastic tab-stops option is now "Auto-space table columns" in the preferences dialog, to match better how things work on OS X.

Bugs 0000210 and 0001362 have been fixed.

§3.5. Inform for Linux

We would like to thank Vincent Petry, who has helpfully contributed packages for OpenSUSE Linux.

§3.6. Inform for Android

For the first time, this build of Inform is available for Android: specifically, for Android 2.1 (Eclair) or later.

[Chapter: Maintenance in build 6L38]

Around 100 bug fixes are made in this build, and once again all known issues have been resolved.

The following lists only the more significant bug fixes: it excludes those categorised by the bug tracker as "cosmetic", mostly small improvements to problem messages, or which affect only the documentation. I'm nevertheless grateful to all those who submitted these bugs, and in particular this build benefits from reports 0001229, 0001234, 0001246, 0001251, 0001259, 0001262, 0001263, 0001281, 0001289, 0001295, 0001299, 0001303, 0001308, 0001311, 0001316, 0001318, 0001321, 0001324, 0001327, 0001333, 0001334, 0001341, 0001342, 0001345, 0001352, 0001388.

(A special mention to 0001336 and 0001337 for some close proof-reading of the manuals, and another to 0001275 for pointing out that we confused the Swedish country code (SE) with its language code (SV) when putting together icons to indicate the language of play, which resulted in the flag of San Salvador making an appearance.)

§3.7. Uncategorisable

Bug fixed (0001339) whereby a really large source text might compile to I6 code containing spurious space characters which, with bad luck, might fall in the middle of a keyword and thus cause I6 errors. (This is only ever known to have occurred on a 3.6 million word source.)

§3.8. Headings

Bug fixed (0001249) whereby headings with multiple bracketed stipulations

Section - Fruit (for use with Locksmith by Emily Short) (not for release) (for Glulx only)

would produce spurious problem messages.

§3.9. Assertions and creations

Bug fixed (0001309) whereby assertions to set rule responses would be misread if the rule names included the word "with" or "having".

Bug fixed (0001247) whereby assertions moving rules in rulebooks would sometimes be misread if the rule or rulebook names included the word "in".

Bug fixed (0001373) whereby "The Attic is above the Parlor" would work, but "The Attic is a room above the Parlor" would make a connection the wrong way (up from the Attic to the Parlor rather than vice versa).

Bug fixed (0001290) whereby some attempts to make map connections to constant values which aren't objects would be ignored (which is fair enough) but with no problem message (which isn't).

Bug fixed (0001260) whereby an oddly-phrased sentence such as

    X with the printed name "Cross" is a thing.

would be read even more oddly as a declaration that all things have this printed name.

Bug fixed (0001361) whereby the assertion "X is on top of Y" would sometimes be read as "X is on (top of Y)".

§3.10. Model world

Bug fixed (0001292) whereby the reaching inside/outside rules would not properly set the "person reaching" variable if the test were run other than via an action.

Bug fixed (0001363) whereby "the direction of D from R" would produce a bogus result for a one-sided door.

Bug fixed (0001243) whereby making scenery parts of a person would lead to a strangely worded problem message.

Bug fixed (0001359) whereby the text substitution "[the player's surroundings]" would produce empty text before play begins.

§3.11. Properties

Bug fixed (0001228) whereby attempts to refer to an impossible property of an object (a property, that is, which can only belong to an object of a different kind) would not always be caught at compile time.

§3.12. Relations

Bug fixed (0001364) whereby a relation defined by a condition involving a test which, to resolve, would require the expansion of a text substitution, would fail with an internal error. (Such a relation is quite legal and now compiles properly.)

Bug fixed (0001285) whereby route-finding through a various-to-one relation would fail to work in some configurations of the relationship. (That's probably being generous - when it did work, that was mostly luck.)

§3.13. Rules and rulebooks

Bug fixed (0001329) whereby a condition limiting the applicability of a rule might not be properly type-checked, causing internal errors in some cases.

Bug fixed (0001280) whereby an attempt to put just a "value" into a rule's preamble would cause an unclear problem message.

Bug fixed (0001323) whereby rules such as...

    Before doing something other than listening to or examining the creature:

...would be misunderstood as (listening) to (or examining the creature) rather than (listening to or examining) (the creature).

Bug fixed (0001296) whereby

    [1] Instead of taking the rock or looking: ... [2] Instead of looking or taking the rock: ...

[1] was reported as a problem (the actions can't mix because "looking" can't apply to the rock), but [2] wasn't. To avoid ambiguities, both forms are illegal.

Problem message improved (0001389) for getting the 'for...' and 'when...' clauses attached to a rule about actions in the wrong order.

Bug fixed (0001328) whereby rules based on a parameter which happens to end with the word "rule" would sometimes have the parameter ignored, making them more widely applicable than intended.

§3.14. Lists

Bug fixed (0001387) whereby Inform wasn't preventing constant lists or texts from being modified using text replacement, list sorting and so forth. All such attempts now result in problem messages.

§3.15. Tables

Bug fixed (0001322, 0001338) whereby creating objects via a table which contained additional blank rows would generate spurious I6 errors.

Bug fixed (0001360) whereby attempting to access a table row, where no row was selected, could cause TableLookUpEntry() to crash at run time. There's now a run-time problem message instead.

Bug fixed (0001255) whereby looking up texts, lists, etc., in a table which contained a blank row before the match would sometimes cause memory out of range crashes at run time.

Bug fixed (0001250) whereby it was possible to create the same column in two different tables with different kinds, provided that both columns started out empty; this resulted in mysterious type-checking problem messages.

Bug fixed (0001390) whereby attempting to read a blank entry of a table as if it held a value would throw a run-time problem (as it should) but then also in some circumstances crash the virtual machine.

§3.16. Equations, units and arithmetic

Bug fixed (0001302) whereby real-valued constants of some kinds, notably those defined by the Metric Units extension, couldn't be written with a minus sign.

Bug fixed (0001268) whereby local variables were not being promoted implicitly from "number" to "real number" when used in an equation. (The documentation half-promised that this would happen; well, now it does.)

Bug fixed (0001310) whereby comparisons between values of a kind other than "real number", but nevertheless stored as floating-point quantities, would wrongly be made using integer comparisons.

Bug fixed (0001257) whereby comparisons between real numbers and numbers would not always implicitly promote the numbers to reals before making the comparison.

§3.17. Understanding

Bug fixed (0001369) whereby a declaration of "Understand... as a mistake", with no error message text supplied, would sometimes crash Inform.

Bug fixed (0001265) whereby an "Understand... when..." condition would throw a problem about referring to the current action even when it in fact tested whether actions had taken place in the past.

Bug fixed (0001313) whereby a runtime error is thrown when the player's command is matched against the text "me", which doesn't qualify, on early turns only.

Bug fixed (0001325) whereby the Understand token "[any K]", where K is a kind of value but not a kind of object, could sometimes produce an internal error.

Bug fixed (0001301) whereby single-letter elements of literal patterns would fail to parse at the command line under Glulx if written in upper case. (Thus a command such as "heat the water by 5c" would work, but not "heat the water by 5C".) Note that this only affected commands typed by hand, because the TEST command flattens to lower case automatically.

§3.18. Text, spacing and printing

Bug fixed (0001242) whereby "blouse" and its derivations pluralized as "blmice", not "blouses".

Bug fixed (0001231, but see also 0001396) whereby the text substitution "[A list of...]" would only capitalise the first word of the output if it were an article, so for example it could produce "four gold coins" rather than "Four gold coins". And similarly for "[The list of...]", which could be fooled by proper nouns in lower case.

Bug fixed (0001258) whereby printing unusual indefinite articles using the "[A ...]" text substitution would produce a "library error 2" at run-time.

Bug fixed (0001319) whereby a text substitution defined with a slash to indicate alternate phrasings on the opening word would lose its case sensitivity.

Bug fixed (0001291) whereby string comparisons in the background would cause "[first time]..." text substitutions to behave unexpectedly when used in certain properties of rooms or things.

Bug fixed (0001370) whereby the string "[one of]..." compares as equal to the empty text "" before being first printed, even if it's never possible for it to be empty. For comparison purposes, it now is equal to the text value it will have when next printed.

Bug fixed (0001368) whereby spurious line breaks would sometimes appear in room descriptions including paragraphs arising from "writing a paragraph about" rules.

Bug fixed (0001365) whereby grouping items under a given text would not always work if that text included substitutions. It now does, and automatically performs the substitution at grouping time.

Bug fixed (0001344) whereby two oddball cases in the list-writer printed a close round bracket ")" directly, rather than printing it with the list writer internal rule response (B).

Bug fixed (0001283) whereby the past tenses of regular English verbs ending -ay, -ey or -oy were incorrect: thus play was plaied, annoy was annoied, and so forth.

Bug fixed (0001396) to do with capitalising "ÿ" in the Z-machine (Queensrÿche fans, beware).

§3.19. Indexing

Bug fixed (0001300) whereby the text "This text is not actually used" is actually used in the Actions detail view.

Bug fixed (0001335) whereby the adjective "substituted" was wrongly defined in the Lexicon index.

Bug fixed (0001332) whereby the Contents index was miscounting the number of words under some headings.

§3.20. Testing commands

Bug fixed (0001256) whereby the RESPONSES testing command would list responses from some extensions in more than one numbered chunk.

Bug fixed (0001236) whereby run-time problem messages would sometimes be hidden on screen if they occurred during the expansion of a text substitution.

§3.21. Releasing, bibliographic data, and cBlorb

Bug fixed (0001293) to make HTML generated by cBlorb slightly better at passing validators.

Bug fixed (0001253) whereby releasing along with the "introductory booklet" or "introductory postcard" had stopped working.

§3.22. Extension maintenance

Glulx Text Effects by Emily Short (now maintained by Dannii Willis) has been updated to give comprehensive support for all Glk text features, and to simplify how colours are set, by using web (CSS) colours like #8800FF. See the extension documentation for more details. An issue to do with deprecated phrases in the examples has been resolved (see 0001367). This update is not fully backwards compatible, but any changes will be easy to make.

Metric Units: removed documentation references to the limitations which existed before we switched to floating-point arithmetic in 6L02.

Epistemology by Eric Eve: Updated to version 8. This fixes a bug (which has oddly only just come to light after all this time, unless it’s a by-product of 6L02) by which backdrops weren’t being marked as seen. It also adds an (A) to label the response of the report epistemic status rule.

§3.23. Examples maintenance

Examples in the documentation which contained ampersands now paste correctly into the source panel (see 0001312).

Small revisions have been made to the examples Lethal Concentration 1 and 2 (see 0001341), Persephone (see 0001346), Terror of the Sierra Madre (0001340), Olfactory Settings (see 0001305).

The example "Lollipop Guild" has been rewritten to demonstrate removing implicit takes from a different action (since eating no longer mandates these); and it is more dentist-friendly into the bargain.

The tiny example "We" has been removed: responses and adaptive text have overtaken it (see 0001245).

The example "Greater Variety" has been renamed "Variety 2" to emphasise its sequelness (see 0001284).

Chapter 4: Build 6L02

§4.1. About build 6L02 (April 2014)

§4.1. About build 6L02 (April 2014)

This release is a major reform of a now-mature language which is widely used, and it has been over three years in the making. It has the following main objectives: to clarify and better enforce the syntax of the language (which is now formally documented); to have much greater linguistic flexibility, enabling stories to be written in any person and tense, and paving the way for translation to non-English languages; to remove phrases and features which have been deprecated for some years; to remove procedural rules, which were little used or understood and incurred a significant speed cost at run-time, in favour of simpler ways to substitute rule behaviour; to remove assumptions about the kind of narrative being written (i.e., that Inform is always making a "game" which is "won" or "lost" and has a "score"); to reform the rules handling "blocked" actions, such as listening; to redesign the Index, the in-application documentation, and the extensions index; to reform the handling of text, unifying "text" and "indexed text", and improving their performance; to introduce a simple but powerful system of "responses" allowing authors to change stock replies in the Standard Rules and other extensions, including third-party ones (and also to make it easy to translate these to non-English languages); and to implement full floating-point arithmetic in numerical kinds of value, at least on the Glulx virtual machine.

This will be a disruptive release. Existing source texts which use deprecated features will no longer work, and the improved syntax checking means that Inform will catch problems it previously missed. It should also be noted that the run-time implementation is different in numerous ways: story files are a little larger but will run a little faster. We believe that almost all Inform projects will be able to migrate to the new system with reasonable ease - for example, "Bronze", a large story written in the very early days of Inform 7, took about an hour's work to adapt. Nevertheless, authors of large existing Inform projects may want to be cautious in their approach to what is, we stress once again, an across-the-board reform of the language.

This release also refines the user interface for the Inform application. As in Inform 7's earliest days, new features are being piloted on Mac OS X, but will make their way to Windows and Linux soon - Toby Nelson, David Kinder and Philip Chimento are all working on these refinements. Search facilities are improved, but the big new feature is the Public Library, which automatically matches the user's collection of extensions against those on the Inform website, and allows the user to download or update them singly or en masse at the click of a button. There are no user accounts, no passwords; no data is held about Inform users at the server; and everything is free.

The existence of the Public Library will, we hope, be good news for extension writers - it will now be much easier to get your extensions out to users. We've always had a set of community standards for extensions, and Mark Musante, the Inform project's extensions librarian, has put in a good deal of work in recent years to look after all this. We now want to go further with that. The Inform website holds hundreds of extensions going back several years, but some of those are out of date, and many will contain deprecated phrases now removed from the language. So the rule is that the Public Library will contain only those extensions from the website which comply with the guidelines and which work properly on the 2014 Inform - we don't want new users, especially, to download obsolete code. Firstly, extensions should always use Responses to reply to the player's commands: this will make them more flexible and easier to translate to natural languages other than English. (At present German IF authors, say, have to "fork" extensions in order to translate them, and we want to avoid the need for that.) Secondly, these responses should where appropriate use adaptive text substitutions so that they will work in any person and tense, and will correctly cope with plural or proper nouns in all situations. An extension which does all this is called "adaptive". As from this build, all built-in extensions are adaptive, and we hope for quite a rapid takeup from third-party extension writers, too, since there is much to be gained and the changes are quite simple to make. Since adaptive versions of extensions will be incompatible with older builds of Inform, we are making arrangements to keep old non-adaptive versions of extensions online at the Inform website (just as older released builds are always available for download): those won't be on the Public Library, but they'll still be available for direct download just as they are now.

Note that a number of existing extensions to provide adaptive text facilities, such as Plurality by Emily Short, will now be redundant. But our build is indebted to this early work, particularly by Aaron Reed and David Fisher.

Lastly, a small announcement: for the first time since 1993, the default story file format for new projects created with Inform is the Glulx virtual machine, not Infocom's Z-machine. The Z-machine design is 35 years old this year, and it has done heroic service, but the time has finally come to move on. (Inform can still compile almost all of the examples to Z, but you'll have to choose Z explicitly in the project's settings to get this, and there's no longer much reason to do so.)

Chapter 5: The Inform application

§5.1. Materials becomes .materials; §5.2. Inform on Mac OS X; §5.3. Inform for Windows; §5.4. Inform for Linux; §5.5. Inform for Command-Line Linux

§5.1. Materials becomes .materials

Inform projects are traditionally accompanied by folders of resources: thus, "Example.inform" would be accompanied by "Example Materials". From 2014, this folder is now called "Example.materials" instead.

This was a change imposed on us by Apple's sandboxing security requirements: we would otherwise have been unable to have Inform available at the Mac App Store. But it applies across all platforms.

§5.2. Inform on Mac OS X

Andrew Hunter's original Inform application for OS X has been substantially rewritten and refined by Toby Nelson, who takes over as its maintainer from this build. Much work has been undertaken to modernise the application, to make it more stable, consistent, user friendly, and feature-rich. This was also an opportunity to introduce new features to Inform's "reference design" for the first time in some years, features which we hope to bring to Inform's other platforms later.

The price for this is that Inform runs only on Snow Leopard 10.6.8 or later, which means that it requires an Intel-processor Mac for the first time. That includes almost every computer manufactured by Apple in the last eight years, but we know it will leave a few Inform users out, and we're sorry for that. The rapid pace of change in Apple's operating systems is such that it has become difficult to have any kind of good user experience on 10.9 while still functioning on 10.5.

Mac App Store: Inform is now code-signed, i.e., digitally authenticated as being the work of an identifiable developer, and this means that Gatekeeper, the Apple security system in OS 10.8 and 10.9, no longer advises the user that the app is potentially dangerous to run. Inform is also sandboxed, which gives the user the assurance that it cannot access private data or make illicit communications. Our intention is to offer Inform both as a direct download from inform7.com (for OS 10.6.8 or later) and on the Mac App Store (for OS 10.8.3 or later), in versions which are identically featured and, of course, both free. Inform's App Store debut will be in a few weeks' time. This should be a help for users in education, where school IT departments are wary of allowing teaching staff to download apps from non-trusted sources.

Design: Inform now has a new clean modern look, with new application icons, document icons, toolbar buttons, images, and Retina screen support. It provides a full-screen mode for users of 10.7 or later (suggestion 3011916). The centrepiece of the toolbar is now a status window like the one used by Xcode and iTunes: this displays the task currently progressing, or the task most recently completed, and can control whether the story is running.

Launcher: Inform used to provide a three-button splash screen, but this has been replaced by a much more feature-rich "launcher" window. This can be toggled open or closed with Command-L: is shows a list of recent projects, lets you open or create new projects and extensions, provides sample projects for new users to play with, has links to useful resources and advice, and so on.

Search: The previous find systems have been replaced with more modern and feature-rich "Find" and "Find in Files" dialogs. "Find" (Command-F) searches the current page (whatever currently has focus). "Find in Files" (Command-Shift-F) is similar to "Find", but searches across chosen locations: Source, Extensions, Documentation (Main text, Examples, Phrase definitions) in any combination. Two search gadgets on the toolbar, one for source, one for documentation, provide quick access to this. Shortcuts are standardised, e.g. Shift-Command-G is now the shortcut for "Find Previous". Search results are much better displayed and sorted (for example, results in the Recipe Book are tinted yellow) and clicking on them jumps more accurately to their location. Documentation search is carefully scoped to search only what's relevant. Finally, both "Find" and "Find in Files" offer fully-featured regular expression search and replace.

Editing: A new text and syntax-highlighting engine has made syntax colouring and styling more accurate, much faster and less prone to crashing or hanging.

Extensions: A new pane, "Extensions", details what extensions are installed, and offers the new Public Library. This compares versions of extensions available at the Inform website against the installed extensions: it shows what's new and what needs updating. Updates and new installations can be made with a single click, or extensions can be installed en masse, with options to download all items or update all outdated versions.

Preferences: The app Preferences are much more clearly laid out, and give a fuller range of options on syntax colouring and styling.

These are the main highlights, but there are small enhancements throughout, and we suggest making a general tour.

(Suggestions 876091, 860939, 3011916, 839957, 846303, 847455, 789525 and probably others, too.)

Bug fixed (0000062): Find text in dialog no longer cleared when frontmost application changes.

Bug fixed (0000092): Open Recent fixed for user extensions.

Bug fixed (0000093): Auto indentation fixed

Bug fixed (0000118): Fixed crash when exiting.

Bug fixed (0000140): Check spelling as you type content menu option works as advertised.

Bug fixed (0000155): Tab-indenting and block commenting hotkeys work in extensions now.

Bug fixed (0000163): Fixed syntax highlighting of substitutions (square brackets).

Bug fixed (0000190): Install extension warning added.

Bug fixed (0000197): The Z-machine interpreter's command history fixed.

Bug fixed (0000200): The new project dialogs reworked, working correctly now.

Bug fixed (0000201): Fix for strange characters appearing in transcript.

Bug fixed (0000227): Fixed crash on Undo

Bug fixed (0000295): Breakpoints are not allowed in Inform 7 projects.

Bug fixed (0000297): Vertical scroll bar rendered underneath the right border if a pane is closed almost to nothing.

Bug fixed (0000298): I6 panes resize correctly.

Bug fixed (0000301): User can click on a raw ni file to view.

Bug fixed (0000310): A recursive printed name no longer crashes.

Bug fixed (0000317): Find all no longer crashes Inform.

Bug fixed (0000361): Elastic tabs now update properly

Bug fixed (0000385): Replace All now works correctly.

Bug fixed (0000424): Opening an extension twice doesn’t open two windows any more.

Bug fixed (0000425): Built-in extensions are no longer flagged as needing installing by the editor.

Bug fixed (0000426): Better help behaviour/messaging when requesting help while an extension window is active.

Bug fixed (0000427): IDE scrolls to error lines in extensions.

Bug fixed (0000428): Subcomments fixed.

Bug fixed (0000429): Contents are shown for stories without titles

Bug fixed (0000430): Fixed quotation marks on title for Contents page

Bug fixed (0000478): Toolbar search boxes can scroll text

Bug fixed (0000496): Tab Indentation is now shown correctly when opening a project.

Bug fixed (0000544): IDE removes the leading "the" when installing extensions.

Bug fixed (0000562): When multiple extensions are open, the keyboard shortcuts for switching windows now do select a story window.

Bug fixed (0000667): IDE always recompiles the game now.

Bug fixed (0000702): Name of elastic tabs has changed, and is now found in Editing Preferences ('Auto-space table columns').

Bug fixed (0000764): Long @opcode names are now coloured properly

Bug fixed (0000773): Extensions page is not open automatically on Lion.

Bug fixed (0000866): Text searching no longer causes a hang.

Bug fixed (0000910): Three dots are no longer converted to a single ellipsis character.

Bug fixed (00001048): Syntax highlighting long delay has been reduced significantly.

Bug fixed (00001090): Different line endings (CR/LF combinations) are handled better.

Bug fixed (00001173): Documentation is up to date.

Bug fixed (00001175): Documentation searches starting with a comma are now correct.

§5.3. Inform for Windows

Elastic tabstops are now available as an option in the Format menu. When elastic tabstops are enabled, tabstops are automatically sized so that columns in tables line up.

The font settings are now respected in the HTML based panes (that is, the index, errors and documentation) when Internet Explorer 9 is installed.

The front-end attempts to sensibly replace spaces with tabs in text that is pasted or dropped on the source tab: if a table is detected its elements are separated by tabs, and leading spaces are also converted to tabs.

The Glulx interpreters in the game tab now support the additions to Glk in versions 0.7.1, 0.7.2 and 0.7.3 of the Glk specification.

The front-end now calls the Inform 6 compiler with the 'k' switch, which enables generation of the Infix debugging information file.

Bug fixed (0000659) whereby the extensions menu could show only 200 installed extensions; it can now show 1000.

Bug fixed (0000859) whereby the Save As... menu item, although available during the time when a story is being compiled, didn't work properly then.

Bug fixed (0000919) whereby whitespace is sometimes trimmed when material is cut and pasted in the source text.

Bug fixed (0000733) whereby changing font to an exotically encoded font (e.g. for music notation) could in some circumstances crash the interface.

When editing the blessed Transcript, the effect of Enter and Ctrl+Enter has been reversed: the former puts in a carriage return, the latter ends editing. (See bug 0000532.)

There is now an Edit > Headings menu item for navigating the source when it's showing only one heading's-worth. (See bug 0000540.)

§5.4. Inform for Linux

The Transcript pane has arrived. This means that the Gnome front-end finally has all the same major features as the OS X and Windows front-ends. Also, finishing the Transcript led to many small bug fixes in the Skein, both structural and cosmetic.

The Spanish translation of the interface has been kindly updated as of 2012 by Jhames Bolumbero, and Stéphane Aulery has contributed a French translation.

The "indent wrapped lines" feature from the OS X and Windows front-ends has been added. This makes it easier to read the Story code when entire paragraphs are indented.

Inform project folders are now displayed in the file manager with Inform icons instead of regular folder icons, and the Materials folder has its own icon as well.

Instead of Ctrl+(Alt+)Left and Ctrl+(Alt+)Right for navigating between sections, the shortcuts now use the , and . keys as in the OS X front-end, so as not to conflict with the well-known Ctrl+Left and Ctrl+Right shortcuts for jumping to the next or previous word.

Matteo Settenvini contributed an improvement where application settings are stored using the Gnome platform's newer GSettings API, rather than the obsolete GConf which caused some problems (e.g. bug 0000600).

Attempted to make the program's error messages more understandable and clearer about how to solve the error.

Sound effects now play correctly in the Game panel, when playing a Glulx project which contains them. (See bug 0000464.)

Bug fixed (0000483) whereby editing extensions might lead to corruption.

Bugs fixed (0000678, 0000717) to improve the refresh speed of the Skein display when there's a large skein; bug fixed (0000677) to do with labels appearing in the wrong places.

Bugs fixed (0000522, 0000692) in the Extension installation process.

Bug fixed (0000529) whereby HTML links in Glulx games did not always work in the Game panel.

Bug fixed (0000653) whereby story files released in unblorbed form would incorrectly have Strict Debug checking left on.

Bug fixed (0000654) whereby the setting for the user's preferred glulx interpreter would sometimes be forgotten when Gnome Inform was quit and then restarted.

Bug fixed (0000676) whereby Find and Replace didn't get case sensitivity correct.

Bug fixed (0000681) whereby the interface would hang on reloading a source text which had been edited and saved in some other application while also open in Gnome Inform. Also, moved the notification displayed when this happens to the status bar, in order to be less intrusive.

Bug fixed (0000691) whereby the interface might crash if a Glulx project being played tried (in error) to use a picture which did not exist.

Bug fixed (0000702) changing "Elastic Tabs" to "Elastic Tabstops" as per the request of elastic tabstops' inventor, Nick Gravgaard.

Bug fixed (0000725) whereby the Contents tab displayed the headings hierarchy with incorrect structural indentation.

Bug fixed (0000731) whereby Gnome Inform crashed when changing the panel in which the Game ran, under some circumstances.

When opening a project which has been renamed so that the folder name no longer ends with ".inform", Gnome Inform now offers to put the ".inform" back again. (See bug 0000738.)

Bug fixed whereby Gnome Inform crashed when the debug log was not available to open. (Discovered through bug 0000999.)

Bug fixed (0001087) whereby a failure in opening a project from the welcome splash screen would quit the application instead of returning to the splash screen.

Bug fixed (0001109) whereby Gnome Inform crashed when encountering an empty directory in the user's installed extensions area.

Bug fixed (0001123) whereby Gnome Inform crashed when running a story where input was entered in more than one Glulx window.

Bug fixed (0001135) whereby Gnome Inform occasionally crashed when starting a story.

Bug fixed (0001187) whereby Glulx text effects persisted from one run of a story to the next.

Bug fixed (0001206) whereby headings surrounded by whitespace-only lines (rather than empty lines) were not included in the Contents pane.

The default spellchecking language is now English, rather than the user's system language. (See bug 0001209).

Bug fixed whereby Gnome Inform crashed when there was an error opening a project, instead of displaying an error message.

Bug fixed whereby Gnome Inform crashed when encountering an unknown command line option.

Bug fixed whereby the Documentation pane didn't load on the left-hand side.

Bug fixed whereby "paste code" icons on the Index pages didn't paste any code.

Bug fixed whereby closing the welcome splash screen did not quit the application.

In addition, many minor and cosmetic bug fixes to the build process, and removed legacy code that was required for compatibility with the now obsolete Debian Lenny operating system.

§5.5. Inform for Command-Line Linux

The number of supported architectures has dropped to four: Linux on x86_64, i386, ppc (32-bit), and arm6hf (e.g. Raspberry Pi). There are no longer ports to s390 or s390x, no armv5tel, and no Solaris support. There are no more separate downloads for the various architectures, either: the single I7_6L01_Linux_all.tar.gz is universal.

The Cheesy Perl IDE has been updated in the following ways: Any files found in the Extensions directory which lack an .i7x extension will have one added. Any project "Whatever Materials" folder will be renamed "Whatever.materials". Inform will no longer compile to z5 or z6; existing games using either of those settings will have their compilation targets changed to z8.

A bug identified by Simon Andersson, where i7 couldn't find its components if installed to a non-default location, has been fixed.

Chapter 6: Documentation and Index

§6.1. Books; §6.2. The Index

§6.1. Books

The documentation has of course been extended and modified to cover the changes in this new build of Inform, but beyond that:

From this build, the Inform documentation (the manuals "Writing with Inform" and "The Recipe Book") are released in EPUB format for the first time, and can be read on tablets such as iPads, or in ebook applications such as Apple's iBooks. The documentation HTML, which used to be coded in late-1990s idioms and was difficult to do much with, now passes XHTML 1.1 Strict and uses CSS for styling. (See suggestion 751034.)

A new "General Index" tab in the Documentation pane features an extensive A-Z index, hand-prepared by Andrew Plotkin: it's a refinement of the one he has for some years maintained online, and unlike a mechanical search tool it's based on human understanding of the material.

The other conspicious change is that the contents page for the documentation now presents the two books, Writing With Inform and The Recipe Book, side by side. Informal surveys had suggested that many readers never found the Recipe Book at all: we wanted to change that. New "expand all" buttons make it possible to see the entire detailed contents page at once. (See suggestions 860937 and 783273.)

The PURLOIN testing command is now documented for the first time. (See suggestion 752104.)

The syntax analysis layer in Inform was completely rewritten for this build, and as a side-benefit from that, we are for the first time publishing a complete specification of the language, mechanically generated from the source code for the compiler (along with an extensive commentary).

§6.2. The Index

The Index has been redesigned. It had gradually grown in coverage and depth, build after build, with a variety of designs used to navigate around it. In this build we've bitten the bullet and imposed a new design to recognise that each of the major Index sections (Contents, Actions and so on) has multiple "elements", and that we have a two-level hierarchy, not one. There's greater use of mouse-over highlighting to advertise links; note the dark grey bar to the left of the section banners, which takes the reader to a new Welcome home page - the so-called "Periodic Table" page, because it shows every element.

We have tried to make each element of the Index a little more detailed and a little clearer visually. For example, the Contents listing itemises how many words of source text fall under each heading. Indexed rules include a new icon which reveals their Responses (see below).

There are far too many changes to itemise, but the following are noted because they arose from Uservoice suggestions:

Command aliases are now indexed in individual actions. (See suggestion 937641.)

The Alphabetical action chart now tabulates requirements on light and nouns. (See suggestion 3265911.)

The Actions detail view now includes persuasion and unsuccessful attempt rules. (See suggestion 884661.)

Chapter 7: The Inform language

§7.1. Text; §7.2. Story viewpoint and story tense; §7.3. Adaptive text; §7.4. Verbs as values; §7.5. Non-English Inform; §7.6. Responses; §7.7. Variables and named constants; §7.8. Floating-point arithmetic; §7.9. Miscellaneous minor changes to the language; §7.10. Removal of procedural rules; §7.11. Removal of deprecated phrases

§7.1. Text

Previous builds of Inform supported two incompatible kinds of value for holding and dealing with text: "text" and "indexed text". "Indexed text" was much more flexible, but incurred speed and memory costs. Despite quite complicated semantics which allowed text to be converted into indexed text, with many such changes occurring silently so far as the author was concerned, this all made text handling more complicated than it needed to be. The author needed to remember to make some properties and variables indexed, others not, and so on; and some kinds of manipulation were impossible.

What does this mean? The short answer is: you can stop typing the word "indexed" and everything will be fine. For example:

let T be an indexed text;
let T be "Jinxed wizards pluck ivy from my quilt";

now doesn't need the first line in order to make T possible to alter or manipulate, and similarly for kind declarations in table columns. Inform still understands the term "indexed text", but it is synonymous with "text", and it has been removed from the Standard Rules throughout. Thus, for example, the phrase definition:

To decide what indexed text is line number (N - a number) in (T - indexed
    text): ...

has been rewritten as the more generally applicable:

To decide what text is line number (N - a number) in (T - text): ...

and many other existing phrases can similarly be applied in a wider setting.

Most textual properties in past builds of the Standard Rules were declared as "text", not "indexed text". So, for example, the following would have failed to compile, and could not have worked:

The Grange is a room. A green Citroen, a fisherman, a brace of pheasants
and a topiary duck are here.

The player carries an E-bomb.

After dropping the E-bomb:
    say "There is an almighty explosion!";
    remove the E-bomb from play;
    repeat with item running through things:
        replace the text "e" in the printed name of the item with "*".

It now does the following:

Grange
You can see a green Citroen, a fisherman, a brace of pheasants and a
topiary duck here.

>drop all
(the E-bomb)
There is an almighty explosion!

>l
Grange
You can see a gr**n Citro*n, a fish*rman, a brac* of ph*asants and a
topiary duck here.

Similarly, it's now easy to find the length of names:

When play begins:
    repeat with item running through things:
        say "[item]: [number of words in the printed name of
            the item] word[s]."

produces

yourself: 1 word.
E-bomb: 2 words.
green Citroen: 2 words.
fisherman: 1 word.
brace of pheasants: 3 words.
topiary duck: 2 words.

In particular, this means that many I6-level hacks used to determine the lengths of strings - such as those used by the "Basic Screen Effects" extension in past builds - can go.

From the language design point of view, there are really no disadvantages, but there is one complication. What should this do?

let X be (put either text or indexed text here);
now the score is 10;
now X is "Your score is [score].";
increase the score by 5;
say X;

In all past builds of Inform, this prints "Your score is 15." if X is a text, but "Your score is 10." if it's an indexed text. The difference hangs on when "[score]" is substituted: a text could hold unsubstituted material which would be substituted later (when printed), but an indexed text couldn't.

The new rule is as follows:

permanent substitution occurs immediately if the text refers to a local
variable which will soon no longer exist, and otherwise

permanent substitution occurs when the text is changed for the first time,
and otherwise

temporary substitution is made each time the text is printed.

Thus the above would print "Your score is 15." ("score" is referred to, but it's a global variable) but this:

now the score is 10;
let X be "Your score is [score in words].";
replace the text "e" in X with "*";
increase the score by 5;
say X;

prints "Your scor* is t*n.", not "Your scor* is fift**n.", because a permanent substitution occurred when the replacement was made.

On the whole we think this is what people would expect, and it means that existing code such as:

now the right hand status line is "Time: [time of day]";

continues to work as before.

But there may be times when people will want to fix the text now. So there's a new phrase:

substituted form of (T - text)

which produces T with all substitution made - which will leave most texts alone, but change "It's [time of day]." into "It's 9:13 AM.", and so on. A new adjective for texts, "substituted" vs "unsubstituted", will tell us whether a text is carrying a [bombshell] or not.

The rarely-used use option:

Use maximum indexed text length of at least N.

is now renamed:

Use maximum text length of at least N.

The maximum, of course, applies only if the text is in its substituted form.

That's it for the changes as seen by the writer of I7 source text, and the remainder of this section of the log gives some technical details for I6 hackers only.

At the I6 level, of course, things are drastically changed. The price we pay for the benefits above is that the old T/IT division was more efficient in its use of time and memory, because it made the user hand-optimise code by constantly choosing between T (fast and small) and IT (slow and large). The new text format is a hybrid, which involves some compromise.

(i) There's always a heap now. In past builds, I7 would only compile the storage for a run-time pool of available memory ("the heap"), and the code to deal with it, if it was actually needed. Technically that's still true, but since text has to use the heap now, and text is ubiquitous, in practice there's always a heap. This costs memory space.

There's something a little ironic about typing about 8K of memory usage in programs as complex as those compiled by Inform, especially since I do it while listening to a Crazy Horse song on a copy of iTunes currently claiming 442 MB of unpaged memory. But memory concerns are not frivolous, given that IF needs to run in a browser now. To mitigate this, reference-counting in the heap means that many fewer copies of data are stored than in past builds, and so Inform generally needs a smaller heap to handle lists, texts, and so on. For large source texts involving lots of list-handling and hacking with text, the new system may actually need less memory at run-time, and will also run substantially faster. The worst case scenario is a very large source text, pushing the limits of the Z-machine, but which never did any text-hacking and never used lists: that kind of story file may now have to move to Glulx. (This is exactly the fate of "Bronze", for example.)

(ii) In past builds, a valid I7 text had to be either a packed string or a pointer to a routine. For example, the I6 code:

x = "deerstalker";
y = Elementary;
...
[ Elementary; print "You know my methods, Watson. Apply them."; ];

creates what used to be valid I7 texts, but no longer. If you need to define a new text in I6 code being used with I7, you have several options. In an inclusion, or a template file, just use (+ and +). For example, at one point the Standard Rules says:

Include (-
    with saved_short_name (+ "yourself" +),
-) when defining yourself.

The effect of (+ and +) is that "yourself" is compiled by I7 into a valid text, rather than being left for I6 to get wrong.

If you can't do that, and you need a text variable, try this:

Array MyTextVariable --> PACKED_TEXT_STORAGE EMPTY_TEXT_PACKED;

(Don't use "": write EMPTY_TEXT_PACKED.) That's if it starts out blank; alternatively something like:

Array MyTextVariable --> PACKED_TEXT_STORAGE "briar pipe";

Then "MyTextVariable" is a valid I7 text.

If you have a constant piece of text, on the other hand, you can protect it from accidental damage and speed up its use slightly by writing:

Array MyTextConstant --> CONSTANT_PACKED_TEXT_STORAGE "Lestrade";

Don't mess with CONSTANT_PERISHABLE_TEXT_STORAGE and UNPACKED_TEXT_STORAGE.

(iii) If you need to change the value of a text variable, use BlkValueCopy:

BlkValueCopy(to, from);

where "to" and "from" are both texts. Note that "to" must already be a valid text: it's not sufficient for "to" to point to 2 words of memory somewhere. For example,

BlkValueCopy(to, EMPTY_TEXT_VALUE);

(iv) If you really need to generate texts on the fly, you can do so with:

x = BlkValueCreate(TEXT_TY);

which will be created empty. However, if so, then to prevent memory leaks you must subsequently:

BlkValueFree(x);

Don't mess with BlkValueDestroy.

(v) To print a text, use one of these:

TEXT_TY_Say(x);
print (TEXT_TY_Say) x;

Some old extensions call a routine called I7_String(x); this still exists, and does the same as TEXT_TY_Say. Another routine in past builds was called PrintText(x), and although this still exists, it has been renamed

PrintI6Text(x)

since it prints a packed string or calls an I6 routine, but won't work on the new I7 text value.

§7.2. Story viewpoint and story tense

A conspicuous difference between interactive fiction and a traditional novel is the point of view from which it's told. Inform usually produces text like:

You can see a grey cat in the basket.

where a novel would usually write:

He could see a grey cat in the basket.

Traditional IF is second person singular, and present tense, whereas most novels are told in the third person singular, and past tense. But these are just conventions - a few novels, for example, use the so-called present historic ("Napoleon looks up at the sky and sighs. Must Ney always be so doubting?"), and plenty are told in the first person singular ("I always get the shakes before a drop."). Inform now allows this too. The two values:

story viewpoint
story tense

control the style of the text produced. The story viewpoint has to be one of the values:

first person singular
second person singular
third person singular
first person plural
second person plural
third person plural

(from a kind called "narrative viewpoint"), while the story tense is one of:

past tense
present tense
future tense

(from a kind called "tense"). Combining these gives 18 possibilities in all.

Note that these settings change only the person and tense used by the texts produced by Inform as responses to commands; for example, they might change the dialogue

>EAST
You can't go that way.

to

>EAST
I couldn't go that way.

So in order to maintain the narrative voice, the author's own source text has to be written to match. For example:

The Taj Mahal is a room. "You stand and admire the Taj Mahal."

When play begins:
    now the story viewpoint is first person plural;
    now the story tense is past tense.

In short, tense and viewpoint switching is neat, but it isn't magic. (It can, however, be changed dynamically during play.)

If we want to write text which will work in whatever the current tense is, the following turn out to be useful little conveniences:

"[here]" produces "here" in the present tense, and "there" otherwise;
"[now]" produces "now" in the present tense, and "then" otherwise.

§7.3. Adaptive text

Paying attention to the tense and viewpoint is one reason why text might need to adapt. Another is that it might need to adapt according to whether nouns are singular or plural. For example, the following rule isn't ideal:

Instead of taking:
    say "[The noun] is pinned down by Dr Zarkov's force field."

Most of the time it's fine ("The V-ray is pinned down by Dr Zarkov's force field"), but then:

> GET ME
You is pinned down by Dr Zarkov's force field.
> GET CONDENSERS
The condensers is pinned down by Dr Zarkov's force field.

The correction is very easy:

Instead of taking:
    say "[The noun] [are] pinned down by Dr Zarkov's force field."

The result is much better: "The V-ray is pinned down..."; "You are..."; "The condensers are...". In fact, it's also convenient because it adapts to the story viewpoint and story tense: "The condensers will be pinned down..."; "He was pinned down...".

Note that "[are]" is not a specially-written text substitution. In fact Inform can do this with any verb that it has a definition of. For example,

"[The noun] [carry] too much static charge."

would also adapt itself - "The V-ray carries too much static charge", and so on. The Standard Rules know many such verbs already, and can adapt all of them. Here is section SR4/1 of the SR, at time of writing:

To seem is a verb. To pick is a verb. To lack is a verb. To put is a verb.
To need is a verb. To eat is a verb. To lead is a verb. To go is a verb.
To arrive is a verb. To get is a verb. To look is a verb. To see is a verb.
To find is a verb. To search is a verb. To discover is a verb.
To switch is a verb. To close is a verb. To talk is a verb.
To provoke is a verb. To wave is a verb. To lock is a verb. To give is a verb.
To open is a verb. To touch is a verb. To take is a verb. To may is a verb.
To wait is a verb. To feel is a verb. To happen is a verb. To push is a verb.
To pull is a verb. To turn is a verb. To achieve is a verb. To squeeze is a verb.
To smell is a verb. To sniff is a verb. To hear is a verb. To listen is a verb.
To taste is a verb. To jump is a verb. To rub is a verb. To pass is a verb.

Negative forms like "[are not]" are also available:

"[The noun] [cannot touch] the ionizer terminal."

might produce "The V-ray will not be able to touch the ionizer terminal.", for example.

As these examples hint, the verb adapts itself to the most recently printed object name. All of this only works if the previous object's name is printed from a substitution. So:

"[The condensers] [are] working."

will work -- correctly forming "The condensers are working.", "The condensers will be working." or "The condensers were working.", according to the story tense -- but

"The condensers [are] working."

probably won't work. Inform doesn't have any way to understand the raw text outside of the text substitution marks "[" and "]".

That object's identity is a value stored in "prior named object", which it's very occasionally useful to change by hand:

now the prior named object is the noun;
say "Oh, [are] [they]?"

which will produce "Oh, is it?", "Oh, are they?", or equivalents in other tenses, depending on whether the noun is singular or plural, even though the noun wasn't explicitly named in the text. Occasionally it's even useful to clear the prior named object altogether:

now the prior named object is nothing;
say "There [are] no room."

This forces the "[are]" to take a singular form - "is", "was", "will be". We need to do this because "There" in English is a sort of meaningless placeholder noun; it doesn't represent any object.

Something else to be careful with is the use of lists. If we write this:

"[The condensers] and [the V-ray] [are] smashed by Voltan's birdmen."

then Inform is likely to print:

The condensers and the V-ray is smashed by Voltan's birdmen.

because it looks at the most recently named object - the V-ray, singular - to decide whether to use "is" or "are". On the other hand, Inform gets this right:

"[The list of things on the bench] [are] smashed by Voltan's birdmen."

Because Inform constructs the list itself, it's able to appreciate that the things listed are jointly the subject of the verb, and it uses that information to decide on "is" or "are". So:

The condensers and the V-ray are smashed by Voltan's birdmen.
The Atomic Furnace shovel is smashed by Voltan's birdmen.

If we need an adaptive message with a verb which doesn't belong to Inform's built-in set, all we need do is declare it. For example:

To retrofit is a verb.

defines a verb without telling Inform what it means. Inform will throw a Problem message if we try to write text like "Flash retrofits the meteor beam" because, after all, it doesn't know what "retrofit" means. But it does still know how to print it, so this works:

"[The actor] [retrofit] the Mecha-Mole."

which might come out as "Dale retrofits the Mecha-Mole", or "Barin's archers retrofitted the Mecha-Mole", and so on.

This is especially neat for writing a single response to an action which works regardless of who the actor was. For example, the Standard Rules include:

say "[The actor] [put] [the noun] on [the second noun]."

And this can make either:

You put the revolver on the table.
General Lee puts the revolver on the table.

In second-person-singular IF, the player is always "you". Many messages look like so:

"You have twenty minutes remaining."

where the subject, or the object, of the sentence is "you". But what if we want to have this text adapt itself to multiple narrative viewpoints? The solution is to use the following:

"[We]" or "[we]"
"[Us]" or "[us]"
"[Our]" or "[our]"
"[Ours]" or "[ours]"
"[Ourselves]" or "[ourselves]"

For example:

"[We] [carry] the Queen's warrant."
"The birds drop pebbles on [us]. Right on [our] heads!"
"[Ours] [are] the burdens of office, which [we] take on [ourselves]."

(Notice that all five of these forms are differently worded, in English. That's the reason why we use the plural to write them - the traditional second person plural forms would be "you", "you", "your", "yours" and "yourself", so we wouldn't know if "[you]" was supposed to be the subject or the object of the verb. So the convention with all of these adaptive forms is that we use "we" and its variations. That's also why the verbs are written in the plural - "[are]", not "[is]"; "[carry]", not "[carries]".)

We have similar adaptive pronouns for objects other than the player:

"[They]" or "[they]"
"[Them]" or "[them]"
"[Their]" or "[their]"
"[Theirs]" or "[theirs]"
"[Themselves]" or "[themselves]"

For example:

Instead of examining in the Netherworld:
    say "[regarding the noun][They] [have] no clear outline in this
        misty netherworld."

produces:

> EXAMINE ME
You have no clear outline in this misty netherworld.
> EXAMINE MARK
He has no clear outline in this misty netherworld.
> EXAMINE DRUMS
They have no clear outline in this misty netherworld.

Note that we have to say "[regarding the noun]", not just start in with "[They]", because nothing has been named so far in the sentence - so Inform doesn't know what object it refers to. "[regarding the noun]" prints nothing, and simply tells the printing part of Inform that the subject has changed.

This isn't always needed:

"[We] [have] a look at [the noun], but [they] [are] just too big."

works fine, because printing "[the noun]" changes the subject to that, and then "[they]" agrees with it automatically. The text might come out, for example, as:

I had a look at Peter Rabbit, but he was just too big.
You have a look at the chessmen, but they are just too big.
We have a look at ourselves, but we are just too big.

There's also the peculiar impersonal non-object for English sentences like "It is raining" or "There are books":

"[It]" or "[it]"
"[There]" or "[there]"

These look pointless - but consider the two texts

"[We] [take] [the noun]. It [rain] harder."
"[We] [take] [the noun]. [It] [rain] harder."

The first one risks printing "We took the scissors. It rain harder.", because it makes "[rain]" agree with "scissors", which are plural. But the second text makes "[rain]" agree with "[it]". And, as a convenience:

"[It's]" or "[it's]"
"[There's]" or "[there's]"

do the obvious thing using the current story tense.

Next up, demonstratives: "[Those]" or "[those]" adapt as needed. For example,

"[We] really [are not] tall enough to reach [regarding the noun][those]."

might expand to

You really are not tall enough to reach that.
He really was not tall enough to reach those.
They really will not be tall enough to reach her.

with "[those]" expanding to "that", "those", "her" and so on as needed.

We can also adapt using "[Possessive]" or "[possessive]":

"[regarding the noun][Possessive] height"

might adapt to, say, "Our height" or "Alice's height" as appropriate.

For any verb V which Inform knows, we can form modal auxiliaries as follows:

"[can V]" or "[cannot V]" or "[can't V]"
"[could V]" or "[could not V]" or "[couldn't V]"
"[may V]" or "[may not V]" or "[mayn't V]"
"[might V]" or "[might not V]" or "[mightn't V]"
"[must V]" or "[must not V]" or "[mustn't V]"
"[should V]" or "[should not V]" or "[shouldn't V]"
"[would V]" or "[would not V]" or "[wouldn't V]"

For example, "Dale [cannot go] to the Cave." might adapt as "Dale could not have gone to the Cave." Most of the English modal verbs are defective in that they do not exist in all tenses or parts of speech - that's why you can't say "to must" or "I am musting" or "I will must" - so there are limits to how good Inform's adaption is, in some of these cases. The modal "can" even uses rewording: Inform says "Dale will be able to go to the Cave." to avoid having to say the impossible "Dale will can go to the Cave."

Finally, we can adapt English contracted forms of verbs:

"[aren't]"
"[don't]"
"[haven't]"
"[won't]"

So, for example:

Instead of taking something:
    say "[The noun] [are] pinned down by Dr Zarkov's force field.
        [They] [aren't] free to move. [They] [can't] move, and [they]
        [shouldn't] move. [They] [won't] move. [They] [haven't] a chance
        to move. Anyhow, [they] [don't] move."

can (depending on the viewpoint) produce variations like these:

The condensers are pinned down by Dr Zarkov's force field. They aren't
free to move. They can't move, and they shouldn't move. They won't
move. They haven't a chance to move. Anyhow, they don't move.

You were pinned down by Dr Zarkov's force field. You weren't free to
move. You couldn't move, and you shouldn't move. You wouldn't move. You
hadn't a chance to move. Anyhow, you didn't move.

(See suggestion 751226.)

§7.4. Verbs as values

Each verb known to Inform is also a value of the new kind "verb". For example:

showme the verb contain;
showme the verb might;
showme the verb provoke;

produces:

verb: verb contain
verb: verb might
verb: verb provoke

As this demonstrates, if V is the infinitive form of the verb, then "verb V" is a value of the kind "verb".

Two adjectives are provided for use with verbs: "modal" (or "non-modal") to pick out verbs like might, could, should, and so on; and "meaningful" (or "meaningless") to pick out verbs which have a defined meaning as an Inform relation. For example, in the Standard Rules, the verb contain is meaningful, the verb might is modal, and the verb provoke is meaningless.

If V has a meaning as a relation of objects, then "meaning of V" produces that relation. For example,

showme the meaning of the verb contain;
showme the meaning of the verb provoke;

produces:

"meaning of the verb contain" = relation of objects: containment relation
"meaning of the verb provoke" = relation of objects: equality relation

(As this demonstrates, if a verb has no meaning, or its meaning doesn't relate to objects, we get just the equality relation.)

In fact, Inform even defines a verb "to mean": it's meaningful, and its meaning is the meaning relation. Thus:

if the verb mean means the meaning relation...

is true. More usefully, we can search our vocabulary like this:

showme the list of verbs meaning the containment relation;

which produces:

"list of verbs meaning the containment relation" = list of verbs: {verb contain}

One use for verbs as values is that it enables adaption to other tenses or numbers. For example,

"we [adapt the verb provoke in the future tense from the first person plural]"

produces the text "we will provoke". In general, we can use:

"[adapt V]"
"[adapt V in T]"
"[adapt V from VP]"
"[adapt V in T from VP]"
"[negate V]"
"[negate V in T]"
"[negate V from VP]"
"[negate V in T from VP]"

for any tense T or viewpoint VP; these default to the current story tense and the current story viewpoint if not supplied. The verb doesn't have to be named explicitly, so for example:

To decide which text is the rendering of (V - verb) (this is verb rendering):
    decide on "[negate V in the past perfect tense]".

When play begins:
    showme verb rendering applied to the list of meaningful verbs.

produces:

"verb rendering applied to the list of meaningful verbs" = list of texts:
{"had not had", "had not related", "had not meant", "had not provided",
"had not contained", "had not supported", "had not incorporated", "had not
enclosed", "had not carried", "had not held", "had not worn", "had not
been able to see", "had not been able to touch", "had not concealed", "had
not unlocked"}

Lastly, we can obtain:

"[infinitive of V]"
"[past participle of V]"
"[present participle of V]"

For example, "[present participle of the verb incorporate]" is "incorporating".

§7.5. Non-English Inform

Intensive work has gone into making both the adaptive text system and Inform's syntax analyser flexible enough to work in languages other than English. For example, an experimental stab at French Inform has adaptive pronouns such as "[celui]", "[il]", "[le]", "[lui]", "[son]" and "[le sien]"; it supports tenses not existing in English, such as the past historic; and it can conjugate the whole gamut of French verbs, which are very much harder than English ones. For example, once the experimental French Inform extension is included, the sentence:

In French craindre is a verb.

will automatically create a text substitution "[craignis]" which can come out in about 100 different forms: "a crainte" (a female person has been feared), "craignirent" (third-person plural past historic active), and so on.

Inform's adaptive linguistics are specified by programming the new Inform syntax analysis layer using a grammar called Preform. French, for example, takes about 2200 lines of Preform grammar just to handle verbs properly. Preform is not documented in the main Inform manual, and it remains experimental, but see the newly published syntax specification.

Internationalising Inform 7 remains a long-term goal, but these are major steps towards it. The scheme is that a translator creates an extension called, say, French Language, and that this contains some material similar to that in I6's "language definition files" together with Preform grammar, translations of responses in the Standard Rules, creations of unusual tenses, and so on. The draft "French Language" extension, which is still incomplete in that it doesn't translate the Responses, is published alongside this build for the benefit of anybody interested.

§7.6. Responses

Many of the short texts written by Inform in play do not appear in the source text for the story, and come instead from extensions, and especially from the Standard Rules. They are often replies to commands:

> INV
You are carrying nothing.

Such texts are called "responses". The Inform 6 jargon here was "library messages", and a crude low-level way to alter these using I6 code was up to now the best way to customise the dialogue appearing in play. (In practice most authors used Inform 7 extensions to do this for them, but those extensions in turn relied on horrible I6 hacks.)

Inform now provides a flexible way for any extension to make its responses customisable, and every built-in extension has been rewritten to do so. We expect many third-party extensions to follow suit.

For example, many of the smaller rules in the SR are capable of producing one or two standard responses. These are now labelled with the rule's name and then a bracketed letter - (A), (B), (C), ... as needed so that every response has its own unique name. For example, the SR lays down:

Carry out taking inventory (this is the print empty inventory rule):
    if the first thing held by the player is nothing,
        say "[We] [are] carrying nothing." (A) instead.

which makes the familiar text "You are carrying nothing." a response named:

print empty inventory rule response (A)

These names are actually values, belonging to the kind "response". Because of that, if we try this:

say "Hmm: [print empty inventory rule response (A)]"

Inform will produce

Hmm: print empty inventory rule response (A)

since we gave Inform a value to print, and that's just what it then did. But:

say "Hmm: [text of print empty inventory rule response (A)]"

produces "Hmm: You are carrying nothing.", unless of course the response has been changed.

It's very easy to change responses:

The print empty inventory rule response (A) is "Your hands are, like,
totally empty. Lame."

and we can even do this dynamically during play:

now the print empty inventory rule response (A) is "Your hands ...";

just as if we were setting a variable.

In practice we can't change these responses unless we know what they're called. One way to find out is just to read through the extensions we're using, but that's a laborious process. A more practical answer is to type:

> RESPONSES

which replies by listing the sets of responses currently available; for example, it says that RESPONSES 1 is the set of responses for the Standard Rules. We can then type exactly that:

> RESPONSES 1
Standard Rules:
    block vaguely going rule response (A): "You'll have to say which
    compass direction to go in."
    print the final prompt rule response (A): "> [run paragraph on]"
    ...

and so on. This lists all of the responses, rule by rule, along with their current texts.

A more selective trick is to make use of the new activity "issuing the response text of". If we write:

Before issuing the response text of a response (called R): say "[R]: ".

we get dialogue like:

>WAIT
standard report waiting rule response (A): Time passes.

>NORTH
can't go that way rule response (A): You can't go that way.

(See suggestion 751870.)

§7.7. Variables and named constants

The customary way to create a variable in Inform is write something like:

The wolf count is a number which varies.

(Or "a number variable", equivalently.) This creates it and gives it the default value for whatever its kind is -- 0, in this case. So to give it a definite value takes a second sentence:

The wolf count is 31.

This is all rather a lot of typing, so a new way to do both steps in one is:

The wolf count is initially 31.

This creates "wolf count" as a number which varies, if it hasn't already been created, and gives it the initial value 31.

In the case of objects, it can be ambiguous what the kind is; Inform treats this situation in the same way it does when working out the kind of columns in tables, by being permissive rather than restrictive. For example:

Peter is a man. The accursed one is initially Peter.

This creates "accursed one" as an object which varies, to be on the safe side. Inform can see that it currently contains a "man" (Peter), but it doesn't know if the variable will later need to hold something else -- a woman called Jane, say, or even a black hat. If in fact the variable must be more restrictive, it's legal to write:

Peter is a man. The accursed one is initially Peter.
The accursed one is a man that varies.

thus telling Inform exactly what is intended.

It's also now possible to create named constants:

The speed limit is always 55.

makes "speed limit" a number constant. Any attempt to set this elsewhere, or change its value, will result in a Problem message, and moreover it can be used in contexts where variables wouldn't be allowed. For example,

The list of significant speeds is initially {30, the speed limit, 90}.

is legal, since the braced list is a constant, and produces

"list of significant speeds" = list of numbers: {30, 55, 90}

Similarly a named constant can be used as a table entry, and as the value of a property, so for example:

A person has a number called maximum comfort speed.
The maximum comfort speed of Trevor is the speed limit.

means that the SHOWME TREVOR testing command produces, among other data,

maximum comfort speed: 55

§7.8. Floating-point arithmetic

Inform has a new kind of value, "real number", which is only available for projects set to Glulx. "real number" behaves very like the "float" type in C, C++, Java and similar programming languages, since, like them, it follows the IEEE-754 binary32 standard for floating-point arithmetic.

It may seem odd to be creating a second kind of number, having just gone to great effort to unify two kinds of text, but the difference here is that arithmetic is fundamentally different for floating-point numbers.

Real numbers are typed much the way that they would be in science or mathematics textbooks. Thus:

let gamma be 0.5772156649;
let Avogadro's number be 6.022141 x 10^23;

(Inform will instead use notations like 4.32E-22 if the use option "Use engineering notation" is on, but by default it's off.)

The fundamental trade-off with computer representations of real numbers is that we compromise on the accuracy of numbers, but not their size, which can be enormously large or small. The range we can hold is roughly:

1.18 x 10^−38 to 3.4 x 10^38

The mathematical constants "pi" and "e" are built in to Inform, but must be typed in lower case.

Numbers can always be used where real numbers are expected: for example, "cosine of 2" does the same as "cosine of 2.0" and produces -0.41615. The standard arithmetic operations work on numbers unless one of the values worked on is a real number, in which case the real-number calculation is done instead. Thus "3 / 2" is 1, because the whole number 2 goes into 3 only once, but "3 / 2.0" and "3.0 / 2" both produce the real number 1.5.

On the other hand, real numbers can't be used in place of numbers, so e.g.:

word number 1.6 in "The Great Wall of China"

is not allowed. But conversion can be made explicitly: "1.6 to the nearest whole number" produces the number 2.

For details on real arithmetic, and on how infinities and non-numbers are represented, see "Writing With Inform".

Text substitutions make it easy to print real numbers in the form needed:

"The semicircle is roughly [pi to 3 decimal places] paces around."
"[1.23457 x 10^8 in decimal notation]"
"[the reciprocal of 137 in scientific notation]"

and so on. Real numbers can similarly appear in Understand grammar. An extensive suite of mathematical functions is provided:

real square root of X [unlike "square root of", which produces a number]
floor of X
ceiling of X
absolute value of X
reciprocal of X
X to the power Y
exponential of X
logarithm of X [which is a natural log]
logarithm to base Y of X
X degrees [which converts X from degrees to radians]
sine of X
cosine of X
tangent of X
arcsine of X
arccosine of X
arctangent of X
hyperbolic sine of X
hyperbolic cosine of X
hyperbolic tangent of X
hyperbolic arcsine of X
hyperbolic arccosine of X
hyperbolic arctangent of X

And these conform to IEEE-754 in the usual way.

Inform has always been able to create arithmetic kinds of value; for example:

Weight is a kind of value. 10 kg specifies a weight.

Now that there are two ways to perform arithmetic, Inform needs to decide which to use in each case. It decides on the basis of whether floating-point numbers are used in the notation. Above, for example, "10 kg" looks like a whole number of kilograms, so Inform uses number arithmetic. But this:

Weight is a kind of value. 1.0 kg specifies a weight.

looks real, so Inform uses real number arithmetic. This allows, for example,

1.9891 x 10^30 kg [the mass of the Sun]
9.109383 x 10^−31 kg [the mass of an electron]

and enables reasonably accurate scientific calculations to be made. The built-in extension Metric Units has been completely rewritten to use real arithmetic throughout.

Inform has for some years supported "equations" - calculations written out as formulae - but up to now they have used only the basic four functions on a calculator: addition, subtraction, multiplication, division.

In this build, arithmetic phrases can be used in abbreviated form in equations. For example:

let x be given by sin x = 1 where x is a real number;

works out x as pi divided by 4, which is to say, 90 degrees. The Phrasebook entries on the mathematical functions give their abbreviations, but here they all are as a list:

abs, root, ceiling, floor, int, log, exp, sin, cos, tan,
arcsin, arccos, arctan, sinh, cosh, tanh, arcsinh, arccosh, arctanh

("root" automatically means the real-number form of square root operation.) As an example, here's the definition of arcsinh given in the Standard Rules:

To decide which real number is the hyperbolic arcsine of (R - a real number)
    (this is the arcsinh function inverse to sinh):
    let x be given by x = log(R + root(R^2 + 1)) where x is a real number;
    decide on x.

The final bracketed clause "this is the arcsinh function inverse to sinh" tells Inform two useful things - to call this "arcsinh" in equations, and that it can solve implicit equations like "arcsinh x = 1" using the inverse function, viz., by performing "x = sinh 1". It's quite legal to create new mathematical functions in this way.

§7.9. Miscellaneous minor changes to the language

** It's conventional for web pages to provide "alt-text" for significant images displayed, so that partially sighted or blind users can get an idea of what is being shown. Inform adopts the March 2014 extensions to the Blorb format and the Babel standard in order to provide such text for figures and sounds. The author simply adds short paraphrases in brackets, like so:

Fugue is the file "Bach.ogg" ("A church organ playing a Bach fugue.").

Figure 2 is the file "butterfly.jpg" ("A red admiral butterfly.").

Release along with cover art ("A cathedral at sunset.").

** In previous builds it has been legal to mark headings with "(not for release)" to say that the material inside shouldn't be included on a release; it's now legal to do the reverse, using "(for release only)" to mark material which is only included on a release. (See suggestion 999953.)

** The I6 code generated by Inform now includes comments noting which paragraphs of the template originate which I6 code. This makes no difference to the effect of the code, but may help debuggers and template hackers. (Not suggested on Uservoice, but by Andrew Plotkin in the Inform 6 maintenance mailing list.)

** In previous builds all commands starting with a given verb could be removed:

Understand the "take" command as something new.

It's now also legal to clear out all the commands leading to a given action:

Understand nothing as taking.

Note that other senses of "take" - for taking off clothes, for example - would be unchanged, as would other senses of "get" - for getting out of rooms, etc. (See suggestion 751396.)

** When defining phrases, Inform has for some years allowed "one/two/--" to mean that the word in question can be "one", "two", or omitted altogether. The same is now true when giving slashed alternatives in Understand grammar. Thus:

Understand "brief underwood/urquhart/--" as briefing.

matches BRIEF, BRIEF UNDERWOOD, or BRIEF URQUHART. (See suggestion 751366.)

** A new use option, "Use unabbreviated object names", instructs Inform not to recognise names in the source text other than in full. For example,

West of the Kitchen is the Roaring Range. South of the Range is the Pantry.

is ordinarily read by Inform as constructing three rooms (Kitchen, Roaring Range, Pantry); but with this use option set, it makes four (Kitchen, Roaring Range, Range, Pantry), in two disconnected pieces of map. Namespace purists have asked for this option, which makes Inform behave a little more like a conventional programming language; but it is very much off by default.

Note that this has no effect on what commands are recognised in play, and affects only how Inform reads the source text of the project. (See suggestion 751458.)

** New phrases have been added to make it easier to see the contents of tables as they change:

To showme the contents of (T - table name): ...
To say the/-- current table row: ...
To say row (N - number) in/from (T - table name): ...
To say (TC - table column) in/from (T - table name): ...

These are intended to authors with testing, not for players to see. The typical output for a full table is:

Table of Frogs
(row 1) | 13 | fish |
(row 2) | 21 | toad |

while a column comes out as a comma-separated list "fish, toad". (See suggestion 751330.)

** In past builds, if authors wanted an action to have a past participle then this had to be specified by hand:

Photographing is an action with past participle photographed, applying
to one thing.

The "with" was optional. It is now compulsory, but in any case, past participles are automatically generated using the adaptive linguistics tricks discussed above - in most cases "-ing" is replaced with "-ed", but Inform knows some 460 irregular exceptions, such as caught, fled, crossbred, taken, woven. In all likelihood, past participle declarations can simply be removed from existing source text.

** The RULES ALL testing command now works better, fixing a bug causing it not always to list all inapplicable rules, and giving a brief reason why such rules are inapplicable.

** Rulebooks were previously limited to 10 named outcomes (each); there is now no limit.

** The construction "list of D", where D is a description, now allows the description to include references to "let" and loop variables. Thus for example:

let L be the list of things in Downton Abbey;

always worked, but

let the place be Downton Abbey;
let L be the list of things in the place;

only now works. (See suggestion 751032.)

** Inform's understanding of the "-where" words has been improved: that is, the words somewhere, anywhere, nowhere and everywhere. Inform considers anywhere to be the same as somewhere, so there are really three cases here.

In previous builds, "somewhere" and "nowhere" meant, roughly speaking, "a room" and "no room". Sometimes this was sensible ("if somewhere is visited, ..."), but it gave sentences like these a strange reading:

if the marble is somewhere, ...
if the marble is nowhere, ...

with the first asking if the marble is a room (no) and the second if it is not a room (yes). Past builds did understand "if B is everywhere", in the case where B was a backdrop, but that was a special case.

In the new build, "-where" words as objects of the copular form of "to be" refer to the room which something is in. To put that another way, sentences such as

if somewhere is visited, ...

mean just what they did before; but

if the marble is somewhere, ...
if the marble is nowhere, ...

now tests whether the marble is (indirectly) in a room. This is the same test which used to be called "on-stage" and "off-stage", which still work fine, but we prefer the new wording in the documentation. These are linguistically more interesting than adjectives, and we could write, for example:

if the marble is somewhere dark, ...
if the marble is somewhere which is not dark, ...

Note that the place referred to by "somewhere" is the room which ultimately contains the marble. For example, if a glowing marble is in a closed wooden box on a table at the bottom of the Coal Mine, then it is still "somewhere dark", even though there's light inside the box. Note also that:

if the Coal Mine is somewhere dark, ...

continues be true, and that the meaning of "to be in" has not changed. Thus

if the marble is in a dark room, ...
if the marble is in somewhere dark, ...

both continue to talk about what the marble is immediately inside - the wooden box, which is not a room, so both are false.

It's legal to use the -where words in assertions, too:

Godot is a man. Godot is nowhere.

in which case Godot begins off-stage - not in any of the rooms. At the opposite extreme:

The stars are a backdrop which is everywhere.

(Only backdrops can be everywhere.) Moreover, these can be changed with "now":

now the Lady is nowhere;

duplicates the effect of the old phrase "remove the Lady from play", which, again, we now prefer not to use, but which still works. This works for backdrops too:

After sleeping:
    say "It's a bright new day!";
    now the stars are nowhere.

After waiting:
    say "Darkness falls rapidly here.";
    now the stars are everywhere.

Writing "now the marble is somewhere" is not allowed, since this is too vague about where.

(See the discussion following suggestion 1286087.)

** On Glulx-compiled projects, you can now have up to 256 temporary values ("let" and "repeat" variables, etc.) at a time. Previously the limit was 15, and for Z-compiled projects it still is, since this is a restriction from the virtual machine itself. (See bug report 0001092, a blatant and successful attempt to pitch a suggestion under cover of the bug report database.)

** The Understand tokens

[anything]
[anybody]
[anyone]
[anywhere]

are now equivalent to "[any thing]", "[any person]" and "[any room]". Note that "[anything]" was previously read as equivalent to "[something]", and "[anybody]" and "[anyone]" as "[someone]": the crucial difference is that "[any thing]" matches any named thing anywhere in the story, whereas "[something]" is restricted to the player's vicinity.

** Five new values have been added to the kind "command parser error", specifically:

can't again the addressee error
comma can't begin error
can't see whom to talk to error
can't talk to inanimate things error
didn't understand addressee's last name error

This routes five of the parser's errors through the "printing a parser error" activity for the first time. (See bug report 0000525.)

** Last and very much least, it is now legal to write a sentence like:

"Madame Fanny has rules." is a text.

though there is really no good reason to do so. (See problem 0000685 from the bug tracker.)

§7.10. Removal of procedural rules

In June 2010 it was announced that Inform's procedural rules would be withdrawn in the next major release. We have had some minor releases in between, but the time has now come.

Procedural rules were originally designed to provide a last-resort way to alter the working of the Standard Rules (and of other extensions) by allowing certain rules to be ignored, substituted and so on. In practice, they caused confusion in use, and incurred significant run-time overheads in terms of both memory and running time.

There is therefore no longer a "procedural rulebook", and attempts to create rules such as this:

Procedural rule: ignore the print final score rule.

will produce problem messages.

The functionality provided by procedural rules wasn't needed often, but it remains useful to have a last-resort mechanism. The following is available instead:

The print final score rule does nothing.

The rule continues to be listed in any rulebook it would normally be listed in, but now it doesn't do anything. More usefully, we can attach a condition:

The print final score rule does nothing if the score is 0.
The print final score rule does nothing unless the score is 100.

We can also substitute a rule of our own:

This is the print fancy final score rule:
    say "Oh my, you scored a mammoth [score]!"

The print fancy final score rule substitutes for the print final score rule.

and once again a condition can be applied:

The print fancy final score rule substitutes for the print final score
rule when the score is greater than 100.

The following phrases, which could be used only in procedural rules, have been removed from the built-in set:

ignore (rule)
reinstate (rule)
reject the result of (rule)
accept the result of (rule)
substitute (rule) for (rule)
restore the original (rule)
move (rule) to before (rule)
move (rule) to after (rule)

Anybody who never used procedural rules will never notice that these have gone, but one other related change might affect them. There used to be two subtly different ways to make a rule or rulebook apply:

follow the print fancy final score rule;
consider the print fancy final score rule;

The difference was arcane and had to do with procedural rules, which were taken into consideration for "follow" but not "consider". This difference has now vanished, and to avoid confusion "consider" is being withdrawn. In all cases it can simply be replaced by "follow".

What do we gain by these changes? The language becomes simpler, and the new syntax is easier to read; run-time memory and stack usage is reduced for everyone, even people not using procedural rules in the first place; and, similarly, there are significant run-time savings in speed (in one test, of about 15%). It's also now possible to index the effects of rule manipulation, making it possible to see from the Rules Index page what has been altered. (See suggestions 751182 and 837651.)

§7.11. Removal of deprecated phrases

In June 2010 it was announced that a number of Inform's built-in phrases would be withdrawn in the next major release. That day has dawned.

This means there is every chance that upgrading to the new build will cause existing source text, including perhaps in extensions, to cause Problems. (They will either cause Problem messages or will work as normal - they won't behave differently in a secretive, difficult-to-detect way.)

Before upgrading, we recommend that any user concerned about this should try adding the following to source text:

Use no deprecated features.

In builds from 6E59 onwards, this causes Inform to produce Problem messages for any of the usages we are now withdrawing, and points to documentation on how to make the change. That advice has now been removed from the documentation, but is reproduced below instead.

award (number) point/points

    Use "increase the score by 5" or similar instead.

change (a stored value) to (value)
change (object) to (enumerated value)
change (object) to (property)
change the/-- player to (object)

    Use "now the score is 10" or similar instead; that is, try "now ... is"
    in place of "change ... to".

consider (rule)

    Use "follow" instead (see above).

delete (a table entry)

    Use "blank out" instead of "delete".

end the game in death

    Instead, use: end the story saying "You have died";

end the game in victory

    Instead, use: end the story finally saying "You have won";

end the game saying (text)

    Use the word "story" instead of "game".

if (a condition) then (a phrase)

    Use a comma instead of "then", or use a colon and put the phrase
    on the next line, indented one stop inward.

if game ended in death:

    Use: if the story has ended and the story has not ended finally, ...

if game ended in victory:

    Use: if the story has ended finally, ...

if game is in progress:

    Use: if the story has not ended, ...

if game is over:

    Use: if the story has ended, ...

if in (object):

    Use "if the location is the Hall of Mists" or similar instead.
    Note: don't use "if the player is in the Hall of Mists", because
    that will fail if the player is inside a container in the Hall.

if it is after (time):

    Use "if the time of day is after 6:00 PM" or similar instead.

if it is before (time):

    Use "if the time of day is before 6:00 PM" or similar instead.

if using the/-- (use option):

    Use "if the American dialect option is active" or similar instead.

resume the game

    Use "resume the story" instead.

say "[contents of object]"
say "[the contents of object]"

    Use "[list of things carried by Darcy]" or similar instead.

set pronouns from possessions of the player

    Use the following:

        repeat with item running through things held by the player:
            set pronouns from the item.

while (a condition) repeatedly (a phrase)
while (a condition), (a phrase)

    Use the block version of "while" instead:

        while a person (called Muggins) is in the Hall:
            move Muggins to the Y2 Rock Room.

Chapter 8: The Standard Rules

§8.1. Actions and the world model; §8.2. Implicit taking; §8.3. Story conclusion and scoring; §8.4. Miscellaneous minor changes to the Standard Rules

§8.1. Actions and the world model

In describing actions, Inform now distinguishes between:

(a) doing something other than taking the apple
(b) doing something other than taking to the apple

To see the difference, suppose the action is "going north". In all builds of Inform, that fails (b): it certainly isn't performing an action on the apple. But in past builds, it also failed (a), because Inform couldn't distinguish the two meanings. In the new build, "doing something other than taking the apple" matches absolutely any action (by the player) which is not "taking the apple", so it does indeed match "going north".

(See bug report 0000784, though I think this was really a suggestion.)

If an action takes place as a result of persuasion, "after" rules are now called on the persuasion action as well as the generated action. For example:

Persuasion rule for asking Bob to try doing something: rule succeeds.
After asking Bob to try waiting:
    say "You asked Bob to wait!"; continue the action.
After Bob waiting: say "Bob did wait!"; continue the action.

now results in the following in response to "BOB, WAIT":

[asking Bob to try waiting]
[(1) Bob waiting]
Bob did wait!
Bob waits.
[(1) Bob waiting - succeeded]
You asked Bob to wait!
[asking Bob to try waiting - succeeded]

(Previously, the "After asking Bob to try waiting" rule could never have effect.)

The property "publically-named" has been respelled "publicly-named". The spelling "publically", which GN habitually uses, is in fact archaic; it has also been corrected in the Inform manuals.

(See suggestion 905217.)

The following rules have been renamed and moved:

the block tasting rule
the block smelling rule
the block listening rule
the block jumping rule
the block waving hands rule
the block rubbing rule

Each rule has become a Report rule, not a Check rule; and "block" in the name has become "report" - for example, we now have the "report tasting rule". These are all cases where the Standard Rules printed a message suggesting that the action had taken place but with no interesting effect; but because the messages were produced by Check rules blocking the action, it was considered to have failed rather than succeeded. It now succeeds.

This change will cause a few existing source texts to fail because they explicitly removed the old rules, for instance like so:

The block smelling rule is not listed in any rulebook.

In some cases sentences like this won't be needed any more, and in others they can simply be replaced by:

The report smelling rule is not listed in any rulebook.

Note that as a result of these changes, other actors can also succeed in these actions, and this means there are new "library messages" to report that: for example,

> JUMP
You jump on the spot.
> CLARK, JUMP
Clark Gable jumps on the spot.

The second version here is new. Note also that Inform's default response used to be "You jump on the spot, fruitlessly." - we have removed "fruitlessly". Similarly, on waving hands, the player is no longer "feeling foolish".

Because the rubbing action now succeeds, people can now in principle rub each other. This of course is not unknown in real life, but it's socially loaded enough that we shouldn't allow it without the author's intervention. So there is a new rule:

can't rub another person rule

to block this ("Keep your hands to yourself.").

(See suggestion 750970.)

The "singing" action has been removed from the Standard Rules. In cases where it was useful, it was a nuisance to modify in order to make its responses appropriate - simply writing a singing action fresh is easier and clearer. The main case for removing it was that beginners often forgot to do anything about the "singing" action at all, so that singing would be possible in the most unlikely circumstances -- swimming underwater, creeping up on somebody, and so on.

(Again, see suggestion 750970.)

The "swearing strongly" and "swearing mildly" actions have been removed from the Standard Rules, and by default, Inform story files no longer respond to swear-words at all. This change is made partly because they weren't useful enough actions to belong in the Standard Rules core set, and partly because of concerns about the use of Inform in education.

(See suggestion 873945.)

The "dropping" action has a new rule:

can't drop body parts rule

which provides a better response to attempts to do so ("You can't drop part of yourself." rather than "You haven't got that.").

(See suggestion 751260.)

The "entering" action has a new rule:

can't enter if this exceeds carrying capacity rule

which means that if the player puts an apple on a table with carrying capacity 1, then tries to stand on the table, she will be prevented on the grounds that there's not enough room.

(See bug report 0001062.)

The "eating" action no longer requires the noun to be carried. This allows people to graze on giant mushrooms, eat berries straight from the bush, and so on, and it also gets over awkward situations over commands like "EAT SOUP" when the soup is a thing on a dining table. What now happens is that an implicit taking action occurs if the food is portable, but not otherwise. (Because of the rule ordering, it also only happens if the supposed food is in fact edible.) For realism's sake, we also, by default, block the eating of food carried by other people.

There are two new rules:

can't eat other people's food rule
can't eat portable food without carrying it rule

and there's also a new "library message" covering the first of these.

(See suggestion 750956.)

The "can't put onto something being carried rule" has been removed. There are already ways in which it's possible for a supporter to continue to hold something up while being carried -- for instance, the tray created thus:

The tray is a portable supporter. On the tray is a bottle of absinthe.

can be picked up. The effect of removing this rule is that it's now possible to, say, put a glass onto the tray while still holding the tray, which seems reasonable enough.

(See suggestion 1564863.)

In effect, we're now saying that it's within the rules of the world model for people to carry supporters which are in use as such. Initial situations like this one:

The player is carrying the tray. On the tray is a bottle of absinthe.

are therefore now allowed; in previous builds the tray would have been assumed to be fixed in place, being a supporter, but now it's assumed to be portable, being carried.

Supported items can now have initial appearances, or rather, their initial appearances are now made use of. For example:

An old oak tree-stump is here. A golden acorn is on the tree-stump.
"A gleaming gold acorn shines out from the gnarled wood of [the tree-stump]."

enables the following:

A gleaming gold acorn shines out from the gnarled wood of the old oak tree-stump.

>get acorn
Taken.

>look
Forest Glade
You can see an old oak tree-stump here.

This is enabled by a new rule:

initial appearance on supporters rule

If unwanted, the new behaviour can be removed by removing this rule.

(See suggestion 1615745.)

The "taking off" action, for removing articles of clothing, used to mandate that the article in question be carried. This sounded sensible, since after all you could hardly take off a hat which was already on the floor. But it had the unfortunate side-effect that typing REMOVE HAT in this situation would cause an implicit action of taking the hat before going on to tell the player that he can't remove it because he's not wearing it. Taking off now doesn't require the article to be carried as part of the specification, and instead it includes the disambiguation hint:

Does the player mean taking off something worn: it is very likely.

(See suggestion 2899370.)

A new activity, "printing inventory details", exactly parallels the existing activity "printing room description details" - but, of course, it prints additional information about items in inventory listings, not in room descriptions. For example:

> INVENTORY
    a flaming branch (providing light)

The bracketed addition here was added by this activity.

As example rules:

Rule for printing inventory details: stop.

gets rid of these addenda; and

Rule for printing inventory details of something edible:
    say " (yummy!)[run paragraph on]".

adds a new one.

(See suggestion 868581.)

§8.2. Implicit taking

"Implicit taking" is what happens in situations like this one:

In the wooden bread-bin is a croissant.
> EAT CROISSANT
(first taking the croissant)
Delicious.

Although the command doesn't directly call for a taking action, it's implicit, and Inform pauses the eating action while a taking action is tried first.

The business of this is carried out by an activity called "implicitly taking". This has existed for some time, but only as hook on which to hang rules. That is, you could modify how implicit taking was done, but you couldn't change the circumstances under which it was done. This is no longer true, and you can now write rules like this:

Check an actor eating (this is the can't eat portable food without
    carrying it rule):
    if the noun is portable and the actor is not carrying the noun:
        carry out the implicitly taking activity with the noun;
        if the actor is not carrying the noun, stop the action.

which is, in fact, how the Standard Rules makes the dialogue above happen. Note that if the activity doesn't succeed in taking the item, it's expected to print some text explaining this, which is why we don't need to say anything further.

This reform also means that the following rules:

can't insert what's not held rule
can't put what's not held rule

now generate implicit takes properly, using the activity, rather than simply imitating this (as they did in previous builds).

The implementation of the activity has changed as part of this process. It used to be empty by default - containing no rules, that is, except any which the user chose to add. But it now contains a "for" rule as the last rule in "for implicitly taking":

standard implicit taking rule

This prints the text "(first taking ...)" and then silently tries the taking action. (See suggestion 1207603.)

§8.3. Story conclusion and scoring

In previous builds, Inform produced story files which kept score (and showed the score in the status line, and so on) by default: it only removed scoring if the option

Use no scoring.

was used. This was a hangover to the days when all IF was game-based, and we now think it's out of date. So by default Inform now has no score; the new option

Use scoring.

has to be used to put it back. If this isn't done, and the source text ever changes the "score" variable, Inform issues a problem message; so in practice Inform won't silently compile existing source text which expects scoring but doesn't get it.

In story files with no scoring, Inform previously defaulted to showing the turn count in the right hand part of the status line. We don't think this is useful any more, either, so the right hand status line is now blank for no-scoring stories (by default). The status line's appearance for scoring stories is unchanged.

(This implements suggestions 1564911 and 1565295.)

§8.4. Miscellaneous minor changes to the Standard Rules

** It has always been the case that if the author doesn't specify the room where the player begins, Inform assumes the player begins in the first room created. In past builds, however, it was possible for that to be a room created in an extension, since "Include..." sentences tend to come early on. In this build, Inform gives preference to the main source text, and will only put the player (by default) into a room created by an extension if there are no rooms created by the main source text. In practice this rarely arose because very few extensions need to create rooms, but for those which do, it could lead to quite some confusion.

** The property "mentioned" is used to mark items which have been named already in the course of a room description, but it used to apply only to naming after the room's main description was printed. It now applies either since the beginning of the turn, or since the current looking action began to be carried out, whichever is more recent. So:

The Grange is a room. "Welcome to the home of [the fisherman]."
The fisherman and the green net are here.

produces:

Welcome to the home of the fisherman.
You can see a green net here.

rather than "You can see the fisherman and a green net here."

The following restores the previous behaviour:

A first before printing the locale description rule:
    repeat with item running through things:
        now the item is not mentioned.

Whereas the following makes the new behaviour even stronger:

The declare everything unmentioned rule is not listed in the carry out looking rulebook.

so that "mentioned" would mean "named somewhere since the start of this turn". (See suggestion 831441.)

** In previous builds of Inform, the rules on touchability applied rather oddly to two-sided doors. This only really showed up when non-players were trying actions outside the player's location, but that case led to a number of bug reports (0000886, 0001163, 0001164). These anomalies have been removed, and doors are now subject to the same rules on touch and reach as anything else. I'm noting that here because a few source texts just might depend on the old way: the example "Rope" had to be modified because it relied on trying an opening action on a door a long way from the player (at the other end of the rope), which worked in the old build because Inform wasn't checking for touchability. In the new build, "reaching inside" rules had to be added to make the door touchable.

** Previous builds of Inform had two actions to handle swear-words typed in at the command prompt, for mild and strong obscenities, respectively. These had to be handled a little coyly in the Index to avoid Inform being considered a "mature audiences only" program, which would get in the way of classroom use. But they were also inappropriate for many games, and added nothing of any great value to the world model; they have now been withdrawn.

(This doesn't implement suggestion 873945 from the forum as such, but it does resolve the unsatisfactory situation this drew attention to; see also suggestion 751338.)

** There's a new rule, the -

exclude people from drop all rule

which does just what it says, using the "deciding whether all includes" activity. (See the maintenance section below under 0000433.)

** There's a new rule, the -

can't push from within rule

which stops people getting into vehicles which are also pushable between rooms and then pushing them in some direction from the inside. One can imagine a few such vehicles - a bobsleigh, maybe, or a punt - but they would probably be better modelled a different way in any case. (See bug report 0000630.)

** New rules:

can't exceed carrying capacity when taking off rule
can't exceed carrying capacity when giving rule

defend against sneaky ways to exceed peoples' carrying capacity. (See bug reports 0000787, 0000788, 0000804.)

Chapter 9: Other features

§9.1. Extensions; §9.2. Releasing

§9.1. Extensions

Inform builds projects from both the source text typed by the author and from Extensions; one of these, the Standard Rules, is always included; others are added as authors please. About 20 are "built-in" to Inform, meaning that they are stored inside the application and always available. Others must be "installed", and each Inform user will have a folder somewhere on his computer which contains these. Users typically download these from inform7.com and then use an Install Extension menu option in the application, which then squirrels the file away. Installed extensions are then available to any projects that user may be working on.

It is now also possible to have extensions available to just one project. These must be stored in the Extensions subfolder of the .materials folder, but otherwise are arranged much the same as installed extensions - there's an outer folder for each author's name, and extensions are named with a ".i7x" extension within. For example:

Mourning Hypercritical.inform
Mourning Hypercritical.materials
    Extensions
        John Siracusa
            Fixing The Finder.i7x

When Inform needs to find an extension, it looks here first, then in the installed area, then in its built-in area. That means that you can make your own revised or hacked version of an extension, put it in the .materials area, and then have it take precedence over the installed or built-in one.

We expect this to be useful in several situations: (i) for people who want to have all of their extensions somewhere where a source-control utility like Subversion can conveniently get at them; (ii) for people who want to keep snapshots of extensions as they were at a given point in time; (iii) for people who like to circumvent the Inform application's source editing window and keep all of their source text for a large project in a string of extensions instead; and (iv) for extension authors who want to have an experimental, not-ready-for-release version of their extension to play with in a test project, without disturbing their installed stable version. (See suggestion 751172.)

Extensions are now required to be filenamed with a ".i7x" extension. This was previously usual but not required, and unextended filenames caused problems with the Subversion source control system. (See suggestion 834467.)

§9.2. Releasing

There's a new "release along with" option:

Release along with an introductory postcard.

which bundles Andrew Plotkin's IF postcard as part of a release.

(See suggestion 1240511.)

There's also the release option:

Release along with the file "filename".

This includes the named file, but without listing it as a browsable item on any generated website. For example,

Release along with a file of "Butterfly painting" called "butterfly.jpg".
Release along with the file "butterfly.jpg".

do exactly the same thing as each other except that the first lists "Butterfly painting" on the sidebar menu of a released website, and the second doesn't. We can also file it away in a subfolder:

Release along with the file "butterfly.jpg" in "hidden_images".

so that it ends up as

Release/hidden_images/butterfly.jpg

rather than

Release/butterfly.jpg

The new release options:

Release along with Javascript "whatever.js".
Release along with style sheet "how_may_you.css".

cause Inform to add inclusions of these scripts (of which there can be any number) to any web page generated in the release; and automatically also achieve the effect of:

Release along with the file "whatever.js".
Release along with the file "how_may_you.css".

thus copying them into place.

The new release options:

Release along with separate figures.
Release along with separate sounds.

cause any figures or sounds created by the project to be copied into the Release folder explicitly: in fact, to Release/Figures and Release/Sounds respectively. This makes them more accessible to hybrid website/IF projects than if they were only embedded in the Glulx story file, and thus invisible to external Javascript or HTML.

Bibliographic data for a project is now allowed to contain Unicode text substitutions. Thus:

Include Unicode Character Names by Graham Nelson.

The story headline is "Adventures in [']68[unicode 8211]79".

The story description is "This is a sentence[unicode 8212]with a parenthetical in dashes[unicode 8212]because 8212 is the Unicode number for an em-dash. But for example, 'pawn to [unicode black chess bishop]4' draws in a black chess bishop, so it works with names, too."

(This was absolutely a suggestion, not a bug, in spite of generating bug reports 0000913 and 0000926.)

Chapter 10: Maintenance

§10.1. Core Inform maintenance; §10.2. Uncategorisable; §10.3. Source text and punctuation; §10.4. Headings; §10.5. Extensions; §10.6. Assertions and creations; §10.7. Model world; §10.8. Properties; §10.9. Relations; §10.10. Actions; §10.11. Activities; §10.12. Rules and rulebooks; §10.13. Lists; §10.14. Tables; §10.15. Scenes; §10.16. Kinds and typechecking; §10.17. Phrases and functional programming; §10.18. Equations, units and arithmetic; §10.19. Understanding; §10.20. Glulx issues, file I/O, figures, sounds; §10.21. I6 template layer and inclusions; §10.22. Text, spacing and printing; §10.23. Indexing; §10.24. Testing commands; §10.25. Releasing, bibliographic data, and cBlorb; §10.26. Extension maintenance; §10.27. Examples maintenance; §10.28. Interpreter maintenance

§10.1. Core Inform maintenance

More than 400 bug fixes are made in this build, addressing almost every known defect in its predecessors.

The following lists only the more significant bug fixes: it excludes those categorised by the bug tracker as "cosmetic", mostly small improvements to problem messages, or which affect only the documentation. I'm nevertheless grateful to all those who submitted these bugs, and in particular this build benefits from reports 0000409, 0000461, 0000527, 0000661, 0000674, 0000679, 0000701, 0000782, 0000785, 0000789, 0000791, 0000796, 0000797, 0000798, 0000805, 0000815, 0000816, 0000820, 0000821, 0000822, 0000823, 0000833, 0000854, 0000862, 0000864, 0000867, 0000869, 0000875, 0000881, 0000893, 0000917, 0000920, 0000933, 0000936, 0000941, 0000944, 0000948, 0000952, 0000964, 0000965, 0000984, 0000985, 0000996, 0001009, 0001022, 0001027, 0001028, 0001030, 0001032, 0001043, 0001053, 0001058, 0001066, 0001071, 0001068, 0001074, 0001082, 0001089, 0001096, 0001098, 0001102, 0001115, 0001118, 0001140, 0001141, 0001173, 0001174, 0001180, 0001182, 0001194, 0001196, 0001198, 0001201, 0001205, 0001208, 0001211, 0001220. See also suggestion 4858913.

§10.2. Uncategorisable

Bug fixed (0000999) whereby, on some platforms, an accented character in the directory path to an Inform project would cause translation to fail, usually with a problem message about failure to create the debugging log, or the .materials folder.

Bug fixed (0000916) whereby "any" could not be use used as a determiner, e.g. in a condition such as "if any animal is in the Observatory".

Bug fixed (0000479) - or, clarification made, perhaps - so that "almost all" will no longer apply to a situation in which all but one item qualifies when there are four or fewer items.

Bug fixed (0000480) whereby the determiners "all but" and "all except" were not being recognised, contrary to the documentation's claim that they are legal. (They are.)

Bug fixed (0001060) whereby the determiners "less than" and "greater than" measured <= and >=, not < and >. ("More than" and "fewer than" did work. They're now synonymous in the context of determiners.)

Bug fixed (0000632) whereby certain awkward double relationships involving known objects would be misread, e.g. in the cases of

(1) things enclosing the player that encloses something
(2) things that enclose something enclosed by the player

Now (1) chooses the x such that x -> player -> (a thing), whereas (2) chooses the x such that player -> x -> (a thing).

Bug fixed (0001065), if it's a bug exactly, to move problem message text from "stdout" to "stderr" when I7 is being run as a command-line tool.

Bug fixed (0000863) whereby Inform would fail with I6 errors if the system clock were set to a date before AD 2000; which sounds harmless enough, but on laptops with failed batteries, or after some kinds of hard crash, it's not unknown for Mac OS X to boot into the year 1969.

§10.3. Source text and punctuation

Bug fixed (0000412) whereby a semicolon placed at the end of a sentence consisting otherwise of a double-quoted text, and followed by another sentence, which Inform therefore (correctly) read as one joined-up but incorrectly written sentence, led to an unhelpful problem message.

Bug fixed (0000553, 0001056) whereby the apostrophe quotation mark rule would not be applied properly with letters from extended Latin alphabets.

Bug fixed (0000588) whereby a missed full stop after one sentence ending with a double-quoted text and before another one referring to the same thing, e.g.:

"It has printed name "Large cavern" It is west from Low passageway."

...could lead to an internal error.

§10.4. Headings

Bug fixed (0000553) whereby apostrophes written ['] couldn't be used inside the double-quoted story title at the start of the source text.

Bug fixed (0000635) whereby sections couldn't be marked both as unindexed and also "in place of" other sections.

§10.5. Extensions

Bug fixed (0000377) whereby extension documentation which contains paste buttons would sometimes omit the closure "-)" of any I6 inclusion syntax included in the source text being demonstrated.

Bug fixed (0000379) whereby extensions could contain spurious sentences after the "ends here" line, sometimes leading to internal errors; a problem message is now issued.

Bug fixed (0000847) whereby run-time problems arising in extensions would be reported only as being in "the source text", rather than identifying which extension is at fault.

Bug fixed (0000781) whereby documentation would not be correctly generated for extensions whose title, or author name, included certain non-ASCII characters.

Problem message added (0001126) to catch the case of a heading replacement subordinate to another heading replacement, so that its destination is at best ambiguous.

§10.6. Assertions and creations

Bug fixed (0000549) whereby using "Here" to place something abstract, e.g., "X is a kind of value. Here is an X.", would produce an internal error. It now produces a philosophical sort of problem message.

Bug fixed (0000582) whereby incorrect assertions in the form

Let A be the B that relates to C by D.

(which really could hardly be more wrong) might in some cases lead to a compiler crash rather than a problem message.

Bug fixed (0000671) whereby incorrect assertions like

The description of Y during X is "".

(incorrect because properties can't be given values specific to the duration of scenes) might, in the case where X is ambiguous, lead to an internal error instead of a problem message.

Bug fixed (0000703) whereby creating a new value whose name coincides with that of an existing variable would sometimes lead to an internal error as well a problem message.

Bug fixed (0000735) whereby declaring "Every X incorporates a Y", when Y is not a kind, led to an unhelpful problem message.

Bug fixed (0000778) whereby Inform issued an internal error when trying to implicitly create a rulebook via a relation it has to an existing rulebook (which is entirely legal).

Bug fixed (0000794) whereby creating one half of a pair of opposed directions in an implicit way crashed the compiler.

Bug fixed (0001117) and problem message improved for circular creations which cause something to be indirectly a part of itself.

Bug fixed (0000932) and problem messages added for assertions involving "nothing", such as "Nothing is in the box.", and for "nothing" said to be "here", as in "Here is nothing."

Bug fixed (0001083 mentions this) whereby calling a room (say) "storage" or some other keyword with an internal meaning might lead to problems.

Bug fixed (0001038) whereby an assembly of a part of a nameless object could crash Inform while it was trying to work out a name for the part.

Bug fixed (0001116) whereby creations such as the following would fail:

A colour is a kind of value. The colours are red and blue.
A tile is a kind of thing. A tile has a colour.
Workshop is a room. Workshop contains a red tile.

Bug fixed (0000888) whereby declarations like so:

The filter is a description of numbers that varies.

would be misread as an attempt to set a "description" property value.

Bug fixed (0000521) whereby multiple sentences in succession of the form "South is nowhere. East is nowhere.", etc., would sometimes give problem messages for all but the first.

Bug fixed (0001040), or you could argue this is a small feature added, so that

Ideal Home Exhibition is a region. A kitchen is a kind of room.
A kitchen is always in the Ideal Home Exhibition.

will work. ("All kitchens are in the Ideal Home Exhibition" already worked; this hangs on the difference between "always" as a measure of likelihood and "always" as quantification.)

Bug fixed (0001128, 0001169) whereby assembled objects attached to proper-named objects would sometimes cause I6 run-time errors on trying to print their capitalised names.

Bug fixed (0000803) whereby plurals would be oversensitive about articles, in that "The plural of a vertex is vertices." would fail to pluralise "vertex". This is now equivalent to "The plural of vertex is vertices."

Bug fixed (0000769) whereby it was possible to redefine an existing constant value (say, a rulebook) as also being a kind of value, in such a way that problem messages would crop up later and a bit misleadingly, rather than straight away.

Bug fixed (0000861) whereby directions would sometimes have their uses as objects and as relative clauses confused, so that e.g.:

A direction can be planar. A direction is usually planar.
Up, down, inside, outside are not planar.

would cause Inform to think "inside , outside" was a reference to something being inside ", outside".

Bug fixed (0000924) whereby the source could define verbs with capitalised words ("To Hoover implies..."), but these verbs wouldn't then be parsed correctly. There's now a problem message to catch this.

Bug fixed (0001219) whereby attempted proper nouns misread as spatial locations would sometimes produce internal errors rather than problem messages.

Bug fixed (0001217) whereby "action of X", when used as a noun phrase in an assertion, would require the word "trying" to be used if the actor in question wasn't the player, whereas in other contexts Inform would allow "trying" to be omitted. For example, the following would work only if "trying" were inserted between "Pete" and "waiting":

The best idea yet is a stored action that varies.
The best idea yet is the action of Pete waiting.

Bug fixed (0001156) whereby a contradiction would be reported between "A K is always improper-named.", where K is a kind of object, and "X is a K", where X has no article; Inform correctly inferred that X is probably proper-named, but then incorrectly didn't overrule this with the certain knowledge it ought to have about all Ks being improper-named.

Bug fixed (0000693) whereby naming a room Something would lead to confusion with the determiner "something".

Bug fixed (0000638, 0001142) whereby assertions about "the player" wouldn't always refer to Fred if the sentence "The player is a man called Fred" occurred in certain places in the source.

Bug fixed (0000655) to do with assemblies applying to a player which had been changed to a named character with a kind more specific than "person": for example, if "The player is a man called Robert." then assemblies applying to men but not people in general might not properly be applied to Robert, and even if they were, they might be misnamed.

Bug fixed (0000824) whereby "There is... called..." would sometimes get confused by prepositions in the first clause.

§10.7. Model world

Bug fixed (0000589) whereby defining a one-sided door so that its exit direction was the same as its entry direction caused a misworded problem message.

Bug fixed (0000852, 0001007) whereby it was possible for the player to be created as, changed into, or made a part of something else. This is not allowed, and breaks many assumptions. There's now a problem message and a runtime problem.

Bug fixed (0001031) whereby it was possible to have the player get on top of a supporter, or inside a container, and then move that off-stage, leaving the player indirectly in limbo. This is not allowed, and now produces the run-time problem "Attempt to move the player off-stage". (That unfortunately breaks version 5 and earlier of the extension "Transit System by Emily Short", so you'll need version 6 or better.)

Infelicity fixed (0000598) whereby an attempt by an actor to enter himself failed the "can't enter what's already entered rule", rather than the "can't enter what's not enterable rule".

Bug fixed (0000723) whereby "resume the story" could not undo a story end once the final question ("Would you like to RESTART, RESTORE a saved game, ...") had been asked.

Bug fixed (0000602) whereby UNDO would be forbidden on the second command if the first command produced an out-of-world action; but OOW actions can indeed be undone, so this was needlessly restrictive.

Bug fixed (0000376) whereby implicit searches through possible enclosing objects (that is, those which satisfy the enclosure relation) would search only things, not rooms.

Bug fixed (0000604) whereby a player in a vehicle being driven by another character would move rooms without "location" being immediately updated, causing problems in some cases for light, two-sided doors and so on.

Bug fixed (0001168) whose report begins "If an object is on a supporter inside a closed transparent container that is part of a backdrop..." and goes on that way, but concerns the rules on touchability.

Bug fixed (0000806) whereby if an action is tried in the before rules for an exiting action, and that first action causes a transition from darkness into light, then the report of the player's new location after the exiting will spuriously mention darkness and then immediately correct itself.

Bug fixed (0000807) whereby if the player begins the story as a named character who is in darkness inside a closed container, then darkness remains even when he or she emerges.

Bug fixed (0000827) whereby the missing nouns supplied by default for the commands LISTEN and SMELL would always be the location, even if the player is within a sealed container in that location. They now supply the outermost object which the player can touch from the inside.

Bug fixed (0001164) whereby non-player people can sometimes not touch a two-sided door when on the other side of it from the player.

Bug fixed (0000870) whereby the phrase "direction of D from R" would give misleading answers if D is a two-sided door whose facing directions are not opposite to each other, e.g., for:

The red rock stair is east of the Orchard and above the Undertomb.

"direction of the red rock stair from the Undertomb" would evaluate to "west", not "down" as it probably should (and now does).

Bug fixed (0000565) whereby changing the player from a nameless default "yourself" to somebody else renders that other person unable to refer to "former self" in commands.

Bug fixed (0001042) to clarify the meaning of "X is regionally in R" when X is a backdrop or two-sided door: it's now true if and only if X is in any one of the rooms contained in the region R. In particular, note that a two-sided door can be regionally in two different regions at once.

Bug fixed (0000694) to make the "front side" and "back side" of a door the first and second rooms it connects to in source text sequence, rather than in inference priority sequence (which is often but not always the same).

Bug fixed (0001069) whereby an object can be said to be "here" more than once in the source text, which may implicitly lead to contradictions, since "here" may have a different meaning in different sentences.

§10.8. Properties

Bug fixed (0000374) whereby Inform wasn't properly checking that condition properties shared between different, not-inheriting-from-each-other kinds were being consistently defined for each kind.

Bug fixed (0000435) whereby Inform's problem message for giving a property the same name as its own kind was unhelpful. ("Movie has a theme called theme.")

Bug fixed (0000517) whereby Inform's problem message for trying to give an object a nameless number or text property was unhelpful.

Bug fixed (0001103) whereby creating a nameless property whose kind is a proper subkind of object would fail.

Bug fixed (0000567) whereby attempts to give one of the three properties mentioned, privately-named or pushable between rooms to a kind of value as well as a kind of object would lead to I6 errors. (For complicated run-time reasons this would be rather difficult; a specific problem message now catches this. No other properties are affected.)

Bug fixed (0000590) whereby Inform's problem message for giving a property an unspecific kind (such as "relation") did not reference the source text at fault.

Bug fixed (0000669) whereby declaring an either/or property with the name of an article (such as "a" or "the") would lead to an internal error as well as a (deserved) problem message.

Bug fixed (0000712) whereby usages such as "the X of a random Y", where Y is not a kind but a single object, or a non-existent object, would lead to an internal error as well as a (deserved) problem message.

Bug fixed (0001154) to do with adding relations as properties fixed. (This looks like, but is not quite, 0000582, which is also fixed.)

Bug fixed (0000539) whereby adding properties to new enumerated kinds, i.e., before any values were enumerated, would wrongly cause a problem message saying that the kind couldn't have properties. (Bug 0000523 was, though not obviously, a duplicate.)

Bug fixed (0001063) whereby adjectives defined by measuring property values would sometimes fail if the kind in question was (e.g.) a list. For example, "Definition: a thing is fooey if its foo is {28, 34}." would perform the wrong test.

Bug fixed (0001192) whereby testing such adjectives on constant values might fail, either giving a wrong answer or throwing I6 errors.

Bug fixed (0000854) whereby defining the same adjective twice over the same domain now throws a problem message if both definitions occur in the source text, or both in the same extension. If not, the source text version always prevails. This means you can, for example, write

Definition: a number is positive if it is -6.

in the source text, and override the definition in the Standard Rules, if you really, really want to. But you can't write:

Definition: A thing is a doggie-snack if it is edible.
Definition: A thing is a doggie-snack if it is the newspaper.

Bug fixed (0000434, 0000498) whereby declaring that a further kind can have an existing either/or property, but giving them the wrong way around, would disrupt the working of the property on the original kind.

Bug fixed (0000935) whereby it was possible to make kind-unsafe property assertions in relation to the kinds room, container, supporter and thing. For example, the following is actually incorrect, because Inform isn't told either implicitly or explicitly that "House" is a room, and so it's a thing; but the bug meant that no problem message was produced, and instead an unsafe value was stored in "home of Martha".

The Garden is a room. A person has a room called the home.
Martha is a woman. The home of Martha is House.

Bug fixed (0000459) whereby the values of "printed name", for anonymous objects, would sometimes mysteriously fail to be equal to each other even when their texts looked the same.

Bug fixed (0000533) whereby defining an adjective over two domains, one a specific object of kind K and another a kind L which is not K or a kind of K, would produce a spurious problem message about the domain being unrecognised.

Bug fixed (0000576), or problem message improved, really, for certain attempts to use the same adjective both as an either/or property and as one value in a many-valued condition.

§10.9. Relations

Bug fixed (0000515) whereby making use of various-to-one relations of things to values could sometimes lead the compiler to crash when constructing the initial state of play, though only in unusual cases.

Bug fixed (0000779) whereby problem messages, arising from a description value involving a relationship to another value held only in a local variable about to go out of scope, were unhelpful.

Bug fixed (0000925) whereby a relation set up with a wrongly named property would sometimes crash rather than issue a problem message.

Bug fixed (0000568, 0000581, 0001113) whereby relations would in some cases be looked up back to front as seen by phrases like "the X which relates to Y by R".

Bug fixed (0000578) whereby fast route finding, if enabled, would sometimes get the wrong answer when searching a source-defined relation.

Bug fixed (0000670) whereby relations involving specific kinds of object would not be very well defended against usage with the wrong kind of object at run-time. For example, if:

Application relates various devices to one thing.
The verb to be applied to implies the application relation.,

then at run-time "now the noun is applied to the second noun" (say) would produce mysteriously wrong results, I6 programming errors, etc., if the noun and second noun were objects other than a device and a thing. It is now safe to read the relation for any kind of object, but the result is "false" if the kind is wrong. It causes a run-time problem to write the relation for the wrong kinds.

Bug fixed (0000994) whereby relations asserted between values which, though nouns, could also be used adjectivally, would fail. For example,

Faction is a kind of value. The factions are friendly, passive, hostile.
Hating relates various factions to various factions.
The verb to hate implies the hating relation.
A person has a faction.
Hostile hates friendly.

would produce a spurious problem message on the last sentence, because Inform misconstrued "hostile" and "friendly" as adjectives applying to people, not as nouns of kind "faction".

Bug fixed (0000726) whereby relations used as property values, as initial values of global variables, etc., would not be mutable.

§10.10. Actions

Bug fixed (0000512) whereby, when an action failed at the Instead stage, the "reason the action failed" would sometimes wrongly implicate another rulebook when looked at from entirely outside the action machinery.

Bug fixed (0000560) whereby creating action or rulebook variables without specifying their names would cause an internal error rather than a problem message.

Bug fixed (0000583) whereby "Instead of jumping for fewer than 4 turns" (say) wouldn't be accepted, but "...less than..." would. Both are legal.

Bug fixed (0000401) whereby attaching variables to actions, and marking them as "(matched as X)", would result in them being matchable in practice only if the kind of the variable was "object" or one of its subkinds.

Bug fixed (0000908) whereby a description of an action using an optional matched-by clause would not be accepted as part of the definition of a kind of action. For example, this would fail to define "leaving town":

Going west from Example is leaving town.

Bug fixed (0001148) whereby a description of an action applied to a region would sometimes be tested on objects by seeing if the object was in that region, rather than seeing if it was equal to it.

Bug fixed (0001044), or perhaps it's more of a clarification of the design: it's legal, though probably unwise, for an out-of-world action to "try" an in-world action, and that action will indeed be in-world, and subject to the full in-world action processing. This slightly affects the GONEAR testing command, which runs as out-of-world but tries looking; it therefore now runs (e.g.) the after rules for looking, which previous builds did not. However, it doesn't run the "every turn" rules.

Bug fixed (0000872) whereby the "standard implicit taking rule" would print clarifying text like "(the fox first taking the eggs)" if an implicit take was caused by something like "try the fox eating the eggs" even when the fox could not be seen by the player at the time.

Bug fixed (0000506, 0000937) whereby a requested action which, when accepted, caused an action to be transferred back to the player by conversion, would sometimes run the wrong check and carry out rules. (E.g., on the command DAPHNE, ASK ME FOR BRENNA, with Daphne and Brenna both being people, there would mysteriously be no text indicating that Brenna has not in fact been taken.)

Bug fixed (0001099, 0001107) whereby a calling in a condition which fails can leave the variable in question holding a kind-unsafe value. For example,

if attacking a device (called the mechanism): ...

when the current action is "attacking Peter", the condition will fail because Peter is not a device, but the "mechanism" variable would hold Peter anyway - despite its kind being "device". It now reverts to "nothing" in this case.

Bug fixed (0000956) whereby a description of an action containing a name which could refer either to a variable or a constant would always be resolved in favour of the constant, which could lead to some strange effects: notably, the rule here -

Player Alice is a person.
Instead of examining the player: ...

would fire on examining Alice, because "player" could refer either to the global variable, or to player Alice. Inform already gave priority to local variables, and now gives priority to global ones too.

Problem message added (0001186) to catch conditions like this:

if we have examined the grail for the fifth time:

which are impossible to satisfy since "we have examined the grail" is false until it's true, and then stays true forever, so that there cannot be five distinct periods of time in which it's true. Since this does not conform to our ordinary English understanding of this condition, and since the condition cannot be useful, a problem message seems the best response. (Previously there was a hacky workaround for this, giving the condition a different meaning, but it had too many demerits and caused confusion as to what "for the fifth time" meant.)

Due to a mistype in its catalogue of irregular English verbs, Inform previously believed the participles "spinning" and "spining" had past forms "spinned" and "spun" respectively; it now realises they are "spun" and "spined".

§10.11. Activities

Bug fixed (0001083) whereby an activity rule applied to an internal keyword such as "storage" would cause an internal error.

Bug fixed (0000884) whereby a rule with a while condition which refers to an activity with a non-thing kind attached would fail to compile.

Bug fixed (0000885) whereby a rule with a while condition relating to an activity would handle "(called X)" in a bogus way; in fact, for the moment anyway, Inform can't handle this, and it now issues a problem message saying so.

Bug fixed (0000453) whereby Inform would allow the creation of activities on values of an indefinite kind, such as:

Enunciating something is an activity on values.

Bug fixed (0001112) whereby the list-writing activities would sometimes fail to say "nothing" when a list of objects was empty only because none of the (at least one) possible candidates qualified, rather than because there were no candidates. (For example, when opening a container to reveal only invisible scenery objects, this bug caused odd messages like "You open the box, revealing .")

Bug fixed (0000634) whereby, similarly, when such a list was "nothing" the "prefacing with is/are" option would sometimes be ignored.

§10.12. Rules and rulebooks

Bug fixed (0000513) whereby passing the number 0 (only) to a number based rulebook (only) using "consider" would in some cases pass a different number instead.

Bug fixed (0000543, 0000484) whereby a rule referencing the past in terms of a temporary value which didn't exist in the past would produce a problem message, correctly, but then crash.

Bug fixed (0000619) whereby Inform crashed when comparing the specificity of two rules, in quite unusual circumstances.

Bug fixed (0001077) whereby Inform produced an I6 error if a rule name included the @ character. (Which is perfectly legal, if odd.)

Problem message added (0001139) to be more explanatory about why "This is the rule:" is not allowed.

Bug fixed (0000894) whereby large numbers of rules attached to the same rulebook and having usage tests - say, 5000 copies of "Before eating when yourself is yourself: do nothing." - would in some cases cause memory usage and/or running time to spike dramatically, though Inform would still produce correct code in the end.

Bug fixed (0001181) whereby attempting to place a rule before or after itself in a rulebook would cause an internal error, rather than a problem message.

Bug fixed (0000763) whereby attempting to change the default outcome of some action-specific check, carry out or report rulebooks would not in fact change their default outcomes (though for others it would).

Bug fixed (0000500) whereby rules which ambiguously contain "when" in their conditions, but where it isn't in fact a condition but part of a noun, would cause problem messages.

Bug fixed (0001006) whereby the "no outcome" rulebook outcome couldn't be printed using "say".

Bug fixed (0000550) whereby some name-clashes between rulebook variables and other named constants would be disallowed unnecessarily, which made it possible for the Standard Rules not to compile in some cases.

§10.13. Lists

Bug fixed (0000662) whereby duplicate problem messages would sometimes be issued for unrecognized list elements.

Bug fixed (0000836, 0001190) whereby phrases dealing with lists which were never in fact used, since the source never contained any lists, would fail to compile in I6.

Bug fixed (0001052) whereby sorting would sometimes get the wrong answer with high values due to numerical overflows; this would probably not have been seen on Glulx, but could more easily happen on Z.

Bug fixed (0001047) whereby use of a temporary variable in a list constant passed out of its scope would result in an internal error rather than a problem message.

Bug fixed (0000968) whereby the list L in a "repeat with X running through L" loop would be recalculated each time around, which besides being a little inefficient would also go wrong if the expression for L was not deterministic - e.g., if it made a random selection, or if it altered as a result of side effects of what was being done in the loop body.

§10.14. Tables

Bug fixed (0000444) whereby Inform would sometimes ignore an explicit kind declaration for a column and impose the kind "object" if that declared kind was a subkind of object (such as "person").

Bug fixed (0000446) whereby Inform would not allow some kinds of value in parenthetical kind declarations for columns, wrongly considering them to be bad syntax.

Bug fixed (0000448, 0001049) to do with Inform not always correctly inferring the kind stored in a column when its only examples had differing kinds (e.g. man, woman) which could only be implicitly united under a single kind (e.g. thing).

Bug fixed (0000931) whereby the kind of a column would be weakened to "object", etc., if it were given only as a general description in the top row, rather than an explicit declaration in the heading.

Bug fixed (0000537) to do with Inform being over-finicky about the kind of a column indicated only by a rule used as a value.

Bug fixed (0000571) whereby tables could not be given alphanumeric names such as Table C2, which was a bit embarrassing, given that the documentation used exactly that as an example Table name.

Bug fixed (0000587) whereby long text entries in certain tables were sometimes truncated; this showed up in use of the Basic Help Menu extension, but was not otherwise related to it.

Bug fixed (0000690) whereby names of kinds could sometimes appear where names of things were expected, in table cells, with no problem being reported.

Bug fixed (0000716) whereby the problem message for an empty table would sometimes be followed by an internal error if that table in fact also had a continuation table.

Bug fixed (0000718) whereby the problem message for an empty table lacked a reference to the source location.

Bug fixed (0001010) whereby an internal error rather than a problem message resulted from an improper column name - e.g. one using brackets, commas, consisting only of an article, etc.

Bug fixed (0000707) to do with looking up text vs indexed text entries in tables, though this is now moot since text and indexed text are now the same kind.

Bug fixed (0000624) whereby blanking out entries containing stored actions would sometimes obscurely fail.

Bug fixed (0001195) whereby blanking out entries corresponding to values in another column would sometimes zero them, not blank them.

Bug fixed (0001222) whereby a table column whose name consists only of an article would result in an internal error, not a problem message.

Bug fixed (0000939) - or maybe it's a suggestion - providing a problem message for the table column name "location", since people sometimes wrongly use this thinking it will determine the initial position of things; whereas in fact it overrides the meaning of many of the Standard Rules.

Bug fixed (0000407, 0000708) whereby looking text, stored actions, etc., up in a table containing blanks would sometimes cause the Z-machine to throw a "programming error", or cause Glulx to halt.

Bug fixed (0000683) whereby the run-time problem for accessing a nonexistent table entry would sometimes not appear in time to prevent an illegal memory access.

Bug fixed (0000801) whereby an attempt to set an entry which was a list, or indexed text, etc., corresponding to another value, would sometimes fail with a "deep copy failed" error at run-time.

Bug fixed (0000802) whereby text allocation would allocate too little memory. Though not really to do with tables, it manifested itself only when looking up indexed text in a table.

Bug fixed (0000696) whereby items created by table would sometimes not allow figure names as property values if those figures had yet to be declared.

§10.15. Scenes

Bug fixed (0000856, and cf. 0001147) whereby a rule firing "When a scene ends" would fire twice if a scene ended in a specialised way. To clarify, the following shows what ought to happen, but previously the "happen last" text appeared twice.

Once Upon a Time is a scene.
Once Upon a Time begins when play begins.
Once Upon a Time ends bouncily when jumping.

When Once Upon a Time ends:
    say "This should happen second.";

When Once Upon a Time ends bouncily:
    say "This should happen first.";

When a scene ends:
    say "This should happen last.";

Problem message improved (see bug report 0000575) for attempts to mix scene ending conditions.

§10.16. Kinds and typechecking

Bug fixed (0000445) whereby the run-time problem message for attempts to set a variable to the wrong kind of value would be issued with the text of a quite different problem message as explanation.

Bug fixed (0000493) whereby text didn't always dynamically expand as it should in Glulx projects.

Bug fixed (0000497, 0000617) whereby Inform checks the kinds of what a relation relates better, so that problems can be reported earlier and in a more explanatory way.

Bug fixed (0000644) whereby some legal if exotic kinds such as

a phrase (phrase number -> (phrase number -> number)) -> nothing

would fail to be recognised and lead to a spurious problem message.

Bug fixed (0000727) whereby Inform produced an internal error when invited to create a "let" variable whose value was the name of a property having a complex kind (such as "relation of things to numbers").

Bug fixed (0000728) whereby problem messages would sometimes talk about the misworded name of a relation as if it were a property, because in fact that misworded name was the correctly worded name of the property used to store the relation data; such problems have been clarified.

Bug fixed (0000739) whereby problems for concatenated phrases which involved a potential mismatch of kinds at an intermediate stage were not as helpful as they might be.

Bug fixed (0000750) whereby problems involving kind mismatches of the basis of a rule were not as helpful as they might be.

Big fixed (0000751) whereby some assignments of property names to variables holding property names led to mis-compiled I6 code.

Bug fixed (0000809) whereby use of a phrase which produces an object, in a context where some more specific kind of object is required, would produce I6 errors if the phrase usage in question involved double-quoted text as one of its arguments.

Bug fixed (0000967) whereby Inform would sometimes allow conditions like

Instead of going to a room when the room is not visited: ...

in which "the room" intends to refer back to the one implicitly referred to by "a room", but where Inform misread it as:

Instead of going to a room when a room is not visited: ...

with misleading results. Inform now issues a problem message in such cases. (See suggestion 754190. It would, of course, be better to attempt to understand "the room" in line with the writer's expectations, but this begins to take us into the notorious "donkey anaphora" problem in structural linguistics. The sentence above is not very hard, but we're wary of trickier cases. So for now, at least, this kind of anaphoric reference produces an explanatory Problem message.)

Bugs fixed (0000906, 0000907, 0000911) and problem messages added to stop people making the fundamental spatial kinds "thing", "direction", "region" and "room" not fundamental any more: for example, "A room is a kind of door." has chaotic results since it means in particular that a room is also a thing. (It also causes the indexing code to hang, which was the specific cause of 0000911.)

Bug fixed (0001110) whereby one implicit reference to a loop which contains another, such as "whether or not a random thing unlocks a door", would under some circumstances fail to kind-check properly, and in others might crash the compiler.

Bug fixed (0001097, 0001121) whereby it was possible to increment or decrement non-arithmetic kinds of value, generating either bad I6 code or an internal error; there's now a problem message to pick this up.

Bug fixed (0000366, 0001004), relatedly, whereby Inform would allow instructions to change lists or texts which are constant: "remove 2 from {1, 2, 3}", for instance. There's a problem message for this, too.

Bug fixed (0000834) whereby a case value "-- V" in an "if" construction would not always be typechecked if it were defined by a polymorphic phrase whose arguments were wrong; in particular if V is some text making no sense but containing the word "before" or "after" in the middle, then Inform would throw an internal error rather than explain why this is wrong.

Bug fixed (0000759, 0001095) whereby phrases in the Standard Rules to do with rules would not accept nothing-based rulebooks, so that e.g. "follow the after reading a command rules" would not work.

Bug fixed (0000838) whereby global variables and properties couldn't be created of the kind "rulebook outcome" unless their explicit values were given.

Bug fixed (0000839) whereby "rulebook outcome" wasn't listed in the Kinds index. In fact this was intentional, since users aren't really intended to make use of "rulebook outcome"; but in view of 0000838...

Bug fixed (0000621) whereby the kind of a rule, treated as a constant, was sufficiently vague that "let" (for example) couldn't use it as a value.

Bug fixed (0000452) whereby oddball conditions like "if an object is an object" would throw a run-time problem claiming that Inform "can't implicitly repeat through the values of this kind".

Bug fixed (0001070) whereby "nowhere" used as a value of kind "description of rooms" would sometimes be read as if it were "somewhere"; and, relatedly, problem message added to catch attempts to quantify over a range within a single value, such as writing "three rooms".

Bug fixed (0000436) whereby text, stored action, list, etc., variables created inside loops and given no explicit value would not be found to be initialised to their default values on iterations after the first.

Problem messages improved or added to clarify that descriptions can't be used as first-class literal values (yet); see bug reports 0000899, 0000887, 0000888, 0000889, 0000891.

§10.17. Phrases and functional programming

A refined method for resolving ambiguous phrase usage gets several cases of apparent name clashes better (e.g., 0000599, 0000613).

Bug fixed (0000360) whereby the problem message for a case of an "if" missing its colon wasn't as helpful as it might be.

Infelicity fixed (0000442) whereby the generated I6 code for some deferred propositional tests included spurious commas, which looked strange, and were ignored by I6 anyway.

Bug fixed (0000490) whereby the problem message for using a local variable which had gone out of scope wasn't as helpful as it might be.

Bug fixed (0000491) whereby the problem message for using too many local variables in a phrase would in some cases be followed by a spurious internal error too.

Bug fixed (0000501) whereby the problem message for indenting a Python-style phrase entirely right of the margin wasn't as helpful as it might be.

Bug fixed (0000557) whereby the problem message for an "otherwise:" used to follow a single-line rather than blocked "if" wasn't as helpful as it might be.

Bug fixed (0000628) whereby the problem message for a malformed "every turn" condition was reported at the wrong line of the source text.

Bug fixed (0000777) whereby Inform crashed at the I6 stage if asked to define a phrase with a synonym consisting of a double-quotation mark.

Bug fixed (0000813) whereby use of "[any thing]" as a value of kind "topic" in a phrase argument would issue a misleading problem message about the past tense if used other than in a rule definition. (The correct behaviour is to issue no problem at all: this is quite legal.)

Bug fixed (0000877) whereby a mysterious internal error about "binding and substitution" would sometimes appear in response to conditions which require multiple substitutions when their logical form is being simplified: e.g. "if X which is related-in-some-way to Y is Z" where the nature of the relation implies knowledge about X given Y.

Bug fixed (0001153) whereby a complex "now", involving searching or systematic changes, which involed a text substitution in some way, would sometimes lead to a "Too late for further text substitutions" internal error. Such phrases now correctly compile.

Bug fixed (0001057) involving the use of "called" to identify phrase arguments whose kind involved parentheses.

"Bug" fixed (0000473, 0000946) whereby phrases to decide a condition would have the kind "phrase X -> nothing" - really this was a poor design decision, not a bug as such; anyway, the kind is now "phrase X -> truth state". (It's consequently legal to return in such phrases with "decide on T" for a truth state T, as an alternative to "decide yes" or "decide no".)

Bug fixed (0000688) whereby a phrase to decide a value, which in fact took no decision, would result in the value internally stored as 0, which was not always kind-safe. It now results in the default value for the kind in question.

Bug fixed (0000825, 0000830) whereby ambiguous phrases such as "dispatch based on item", given multiple definitions to go on where one involved a qualified description, e.g.:

To dispatch based on (X - a thing): say "Fail."
To dispatch based on (X - a thing that is yourself): say "Pass."

...would result in correct code being generated the first time they arise, but not subsequent times, when the qualified case (here "thing that is yourself") would be overlooked.

Bug fixed (0001079) to clarify that it's not legal to overload the return kind of a phrase, so that:

To decide what number is my special value: decide on 4.
To decide what person is my special value: decide on the player.

is a conflict which now produces a problem message.

Bug fixed (0000591) whereby the use of slashes to give alternative wording would cause the definitions of say phrases to lose case sensitivity.

Bug fixed (0000584) whereby the condition "if ... for 0 turns" would be miscompiled to something which is always true when the condition holds, rather than only true if it has only just become true.

Bug fixed (an offshoot of 0000818) whereby adjectives used as filters on lists would sometimes be read as applying to the wrong kind of value, if no kind was explicitly given.

Bug fixed (0000362, 0000747) whereby phrases with inline I6 definitions could nevertheless be given names as constants; this resulted in I6 compilation errors. It now causes an explanatory problem message.

Bug fixed (0000753, and see also 0000648) whereby phrases could be given definitions whose kinds could not in practice be determined through their usage, e.g. "To decide what value is bar: ...".

Bug fixed (0000904) whereby phrases involving kind variables could be invoked with kinds which could not be worked out by supplying them with the empty list written as a constant.

Bug fixed (0000768, 0000771) whereby a phrase to decide a topic, which returned what looked like constant text, would indeed return that and not a topic at all.

Bug fixed (0000452) - or, really, it suggested that Inform should have tighter syntax, which is now provided - so that using a kind variable as if it were a noun produces a problem message. For example, "if K is L" throws this problem; but "if a K is an L" doesn't, because "a K" is a description matching multiple values, whereas "K" on its own looks as if it might be a single value.

Bug fixed (related to 0001001) whereby definitions which give a return kind in terms of unset kind variables weren't being rejected - for example,

To decide which K is acclaimed by (x - value of kind J): do nothing.

does not determine K, and presumably the author meant J. This now produces a problem message.

Bug fixed (0000998) whereby phrases marked with "instead" wouldn't always quit their rules if they required run-time kind checking to perform.

Bug fixed (0000873) whereby a generic phrase whose tokens contained stipulations about property provision, as in this example:

To say foo (C - sayable value that provides the property
indefinite article):

...would not always correctly be applied.

Bug fixed (0001080) whereby a selection of overlapping phrase definitions distinguished only by descriptions of one or more tokens would sometimes be given incorrect mutual precedences.

Bug fixed (0000799) whereby the looking-up of a random value involving callings would result in those callings not being made, e.g., after

let foo be a random person in a room (called bar);

"foo" would be set but not "bar". They now both are.

Bug fixed (0000368) whereby phrases whose tokens were required to be specific other phrases would not always be correctly called.

Bug fixed (0000817) whereby descriptions of phrases would not always be accepted as filters on lists of phrases.

Bug fixed (0000463) whose circumstances were obscure, but which seemed to occur when named say phrases were used as terms in a relation.

Bug fixed (0000469) whereby "break" did not, as claimed, escape the innermost loop but would instead escape an "if X is... -- V: ..." construction (i.e., a switch case) if that were innermost.

Bug fixed (0001101) whereby local variables with the same name as a kind would be misunderstood in descriptions of actions.

Bug fixed (related to 0001101) whereby local variables were allowed to have some pretty strange names - punctuation, say.

Bug fixed (0000410) whereby rules taking effect on some condition which involves rulebook variables would sometimes cause spurious problem messages when in the presence of other rules in the same rulebook of an apparently similar logical priority.

Bug fixed (0000417) whereby two rule headers in a row, where the first therefore had no body to define it, would misleadingly be legal.

Bug fixed (0000900) to do with misreading ambiguous names of variables: see bug 0000956 below, though they aren't quite duplicates.

Bug fixed (0001106) whereby "(called X)" could be added after a token in a phrase which wanted only the name of a kind, not an instance of that kind.

Problem message added to catch creations of variables which have such a short life-span that they vanish immediately they're made - as in the following example (if X does not already exist):

if the location is the Casimir Effect Demo Area, let X be 1;

§10.18. Equations, units and arithmetic

Bug fixed (0001021) whereby square roots of integers with the top non-sign-bit set would be incorrectly evaluated as -1.

Bug fixed (0000850) to do with rounding negative numbers to the nearest value.

Bug fixed (0000548) to do with choosing an appropriate literal notation to print negative values of a unit.

Bug fixed (0000441) whereby arithmetic performed on times could push them out of range. This arose semi-intentionally, because Inform slightly improperly but conveniently uses the same kind for times of day as for durations, and a duration of "minus 10 minutes" makes sense but a time of day of -10 doesn't. Inform now renormalises the result of all arithmetic on times to force them into range.

Accuracy slightly improved when printing awkwardly-scaled units using only 16-bit integer arithmetic (see 0000547).

Problem message added (0000399) to catch attempts to solve an equation for a constant rather than a variable.

Problem message added (0000737) to catch integer scalings of units so wide that they can't safely be represented in the 16-bit Z-machine.

§10.19. Understanding

Bug fixed (0000561, 0000485) whereby Problems in conditions attached to Understand sentences would misreport type-checking errors.

Bug fixed (0000564) whereby Problems from sentences like "Understand "fooble" as the player." would be unhelpful.

Bugs fixed (0000647, 0001075) whereby using a "[something related by...]" token in an Understand sentence produced an internal error rather than problem messages when the relation was to a value rather than a thing. (0001075 occurs slightly differently, but was fixed at the same time.)

Bug fixed (0000698) whereby sentences like "Understand the P property as describing X" sometimes caused internal errors rather than problem messages if P is a value rather than either/or property.

Bug fixed (0000808) whereby placing items in scope could cause a hang at run-time when trying to match the name of something visible only if something is visible.

Bug fixed (0000957) whereby a too-many-activities run time problem could be generated from Understand grammar such as:

Understand "[person] spot" as the parking spot.

since this would mean that no object name could be parsed without checking to see whether it was the parking spot by this rule; but then, first the text must be checked to see if it begins "[person]"; and that would mean parsing an object name, which... and so on. Inform now checks that the "[person]" condition applies before rather than after parsing for it, which means that in the case of the parking spot object - which is not a person - no recursion occurs, and all is well.

Bug fixed (0000719) whereby the token "[something related by reversed wearing]" or "[something related by reversed carrying]" (but no others) would fail, in some cases causing a hang.

Bug fixed (0000636) whereby, at run-time, the response to incomplete commands (and where no "does the player mean" rule supplied suggestions) would be unhelpful ("I didn't understand...") rather than asking a clarificatory question.

Bug fixed (0001160) whereby, relatedly but differently, incomplete commands endin with multiple bogus prepositions (e.g. "DROP ROCK ON INTO") gave strange replies ("What do you want to drop the rock on those things?").

Bug fixed (0000767) whereby testing whether a command includes a snippet would sometimes fail if that snippet contained alternatives marked with a slash, and where the test occurred in a rule condition rather than in a phrase.

Bug fixed (0000814) whereby passing a topic as a phrase argument, which contains one of the special tokens such as "[someone]", would produce a spurious problem message about "[text]" not being allowed.

Bug fixed (0000437) - or, arguably, small feature added - so that it's now legal to have a range of aliases for objects or values, in which some aliases produce values, and others don't. For example:

Colour is a kind of value. The colours are red and blue.
A cube is a kind of thing.
Understand "[colour]" as a cube.
Understand "box" as a cube.

allows "red", "blue" and "box" all to refer to any cube. Previously, this would have thrown a problem message as being inconsistent, because one alias works out a value ("[colour]") and another doesn't ("box").

Bug fixed (0000433, 0001054) whereby the "deciding whether all includes" wasn't being consulted when only one object qualified for "all". It's arguable whether this is a bug, but the change makes the activity stronger, and better able to reject "DROP ALL" inferring the player when there's nothing else around, for example.

Bug fixed (0000865) whereby the snippet "player's command" would sometimes omit words added to the command as a result of followup disambiguation questions.

Bug fixed (0000765) whereby use of the token "[any D]", where D is a description of a kind which is otherwise not called for by any other token, would result in an I6 compilation error.

Bug fixed (0000700) to do with the names of things described by numerical properties.

Bug fixed (0000633, 0000943) whereby apparently unnecessary disambiguation questions were issued when trying to parse "put X in/on Y", with "does the player mean" rules not being properly consulted.

Bug fixed (0001002) whereby "does the player mean" rules would not always be consulted if a command ended with a full stop ("examine green." instead of "examine green", say).

Bug fixed (0000744) whereby "does the player mean" rules would not always be consulted on an ambiguous noun where the second token of the line consisted of "[text]" rather than an object.

Bug fixed (0000835) whereby what look like numbers, followed by a full stop, would sometimes not be read as objects even when that's what they are - e.g., if "one" could mean issue 1 of a magazine, "take one." would fail even though "take one" would work.

Bug fixed (0001011) whereby verbless commands with full stops dividing them could, sooner or later, cause crashes or hangs at run-time.

Bug fixed (0000642, 0000959) whereby matching text against tokens involving the names of objects could cause the value of "noun" to be corrupted, thus causing rulebook processing to go wrong.

Bug fixed (0000489) whereby literal patterns set up with an optional minus sign in front, and which could have two or more parts, would have the minus sign accepted but ignored by Understand tokens.

Bug fixed (0000680) whereby disambiguation questions would sometimes give the choices of object in the opposite order to that expected.

Bug fixed (0000396) whereby apparently incomplete commands beginning with a direction (and thus with a "go" implied) could be wrongly reported back by the parser error "I only understood you as far as..."; the text of which has also been improved in this case.

Bug fixed (0000800) whereby "GET ALL FROM X" would sometimes produce a peculiar reply if nothing was in X, but exactly one item had been explicitly placed in scope by a "deciding the scope" rule in the source text.

Bug fixed (0001134) whereby some "PERSON, SOMETHING" commands would not properly interrupt a disambiguation question.

Bug fixed (0000942), or at any rate the algorithm improved, so that Inform is better able to parse ambiguously worded properties by which objects are to be understood.

Bug fixed (0000460) whereby parsing names identified by number properties would sometimes, when it failed, cause a misleading choice of parser error.

Infelicity fixed (0001216) whereby I7 compiled references to the I6 variable "parser_trace" even in Release builds, where it's always 0.

Problem and run-time problem message added (in response to 0000580) to tell the player why one can't have "[text]" followed by something more flexible than fixed wording.

Problem message added (0000745) for an attempt to "Understand the command ... as ..." with a multiple-word command given. Previously this was accepted but did nothing, which could mislead authors.

Problem message added (0000555) to help prevent newcomers from writing sentences like:

Understand "yourself" as Bob while asking Bob to try doing anything.

where the condition depends on an action which has yet to be fully parsed, so that the condition can never meaningfully test anything.

Problem message added (0001204) to catch multiple uses of the "things" tokens in a single command line, as in:

Understand "put [things] in [things]" as inserting it into.

§10.20. Glulx issues, file I/O, figures, sounds

Bug fixed (0000756) whereby asking an "if the player consents" question would not update the status line first on Glulx, even though it would do on the Z-machine. (It now does on both.)

The template's embedded copy of "infglk.h" is now updated to one which was generated automatically for Glk API 0.7.4. (See bug 0001215, though this really wasn't a bug.)

§10.21. I6 template layer and inclusions

Bug fixed (0000487) whereby the problem message for a reference to an unknown I7 noun in (+ ... +) markers inside an I6 inclusion gives a source text reference to the wrong place.

Bug fixed (0000748) whereby a Z/Glulx opcode written in I6's @notation and placed on column 1 of its file would cause an internal error rather than a problem message.

Bug fixed (0000882) whereby the "ineffectual" use option had the effect of causing code to fail to compile in I6; it should of course have no effect.

Infelicity fixed (0000754) whereby the Parser.i6t routine I7_ExtendedTryNumber was never called. It's now removed.

Infelicity fixed (0000757) whereby some template code in letter (E) of Parser.i6t was redundantly duplicated.

Infelicity fixed (0000760) whereby calls to FollowRulebook in Parser.i6t were written misleadingly.

Infelicity fixed (0000626) whereby usages of the deprecated I6 syntax "for (;;)" were still used in the template code.

Problem messages added in place of internal errors for misapplication of certain undocumented internal syntaxes. (See e.g. bugs 0000775 and 0000831.)

Bug fixed (0000883) whereby problem messages citing an I6 inclusion (-...-) would, in the words of the reporter, "shortchange the author one smiley cyclops".

Bug fixed (0001104) whereby I6 code inserted after the last named part of a template file would lead to a problem message rather than the code actually being inserted.

Bug fixed (0000832) whereby use options with numerical values spelled out in words rather than numerals would be 0, not the value given.

Bug fixed (0000618) whereby Inform wasn't checking that the meaning of a "Use ... translates as ..." is meant to be just a single fragment of I6.

§10.22. Text, spacing and printing

Bug fixed (0000849) whereby Inform wouldn't complain at out of place "[otherwise]" or "[otherwise if]" substitutions.

Bug fixed (0000845, 0000912) whereby Unicode output on Glulx would bypass glulx's filter mechanism, which Inform doesn't use directly, but which authors willing to do some glulx assembly in I6 inclusions might use.

Bug fixed (0000384) whereby looking up a value decided by a rulebook could cause a spurious newline to be printed; this manifested itself in blanking out the status line, for example.

Bug fixed (0000743) whereby silent actions tried while a line of printed text was still incomplete would sometimes produce newlines even when they generated no text themselves, having worked.

Bug fixed (0000715) - or if not a bug, this was a request to clarify and make consistent the handling of tabs and newlines inside quoted text. The change made is that two or more newlines followed by tabs or spaces are now interpreted as a paragraph break, just as they would be if they weren't followed by tabs or spaces. So, for example:

say "Hello

there."

was always read as a paragraph break inside the text; and

say "Hello

    indented a little."

is now also read that way. (The white space following the newlines is soaked up.)

Bug fixed (0000605) whereby use of character class escapes in ranges in regular expressions would match either their meaning or their letter code, so e.g. "<x\p>" would match an "x", a punctuation character, or a "p". It now matches just "x" or the punctuation character.

Bug fixed (0001155) whereby the "printing the name of" activity would sometimes get confused about indefinite articles if a rule needed to use the indefinite article of something else in the course of its work.

Bug fixed (0001046) whereby relations arising from properties of the kinds "room", "region" or "direction" would not be searched properly by an implicit search.

§10.23. Indexing

Bug fixed (0000502) whereby the World page didn't properly map backdrops in their locations.

Bug fixed (0000577) whereby Inform would halt with a file-system error if the Index subfolder of a project had been manually removed between runs. Inform now repairs the thing with the silent patience of a saint.

Bug fixed (0000826) whereby the Contents page of the index would take too much memory and time to render, especially on Windows, if there were more than 1000 or so figures. Inform now displays thumbnails only for the first 50 figures by default, but provides the use option "Use index figure thumbnails of at least X." to raise this as needed.

§10.24. Testing commands

Bug fixed (0000871) whereby the RULES ALL testing command wouldn't list some rules whose conditions of applicability failed.

Bug fixed (0000505) whereby the RULES testing command wouldn't list rules with no applicability tests. This was actually a deliberate decision, the idea being that you didn't need to be told, but I now think the added verbosity is worth it for the sake of consistency.

Bug fixed (0000356) whereby the RELATIONS testing command would give wrong answers or, in some cases, crash on a one K to various texts relation.

Bug fixed (0000860) whereby "does the player mean" rules would not always be run for some commands in a TEST script.

§10.25. Releasing, bibliographic data, and cBlorb

I'm grateful to David Griffith for supplying a little code to allow cBlorb to produce I6 constant declarations like those generated by the older tool perlblorb, for the benefit of I6 projects developed outside the I7 framework.

Bug fixed (0000551) whereby releasing with source text after including some extensions (notably the GPL3 licence one) caused cblorb release errors.

Bug fixed (0000597) whereby releasing with source text including a multiline footnote with extra white space would lead to badly formatted website.

Bug fixed (0000615) whereby releasing a project whose title ends in a question mark failed (though on Windows only).

Bug fixed (0000714) whereby releasing with an existing Z-code story file caused I6 errors related to "VPH_Class".

Bug fixed, or suggestion adopted (0000746), to do with values of the bibliographic variables "release number", "story headline" and "story genre" when these are not set by the source text.

§10.26. Extension maintenance

All of the built-in extensions have been made adaptive (see above).

A new extension, Inanimate Listeners by Emily Short, has been added to the built-in selection to provide for objects like microphones which, though inanimate, can be talked to.

(See suggestion 750934.)

A new extension, Skeleton Keys by Emily Short, has been added to the built-in selection to provide the built-in implementation of locking (a one thing to various things relation) with a more generous but memory-consuming implementation (various things to various things). This means that it is possible to have multiple keys that open the same lock. It is compatible with, but does not require, the new version 12 of Locksmith by Emily Short.

(See suggestion 819431.)

Metric Units by Graham Nelson has been completely rewritten to use real arithmetic, and now performs more accurate physical calculations.

A new extension, Approximate Metric Units by Graham Nelson, is essentially the previous version of Metric Units under a new name, and performs calculations with scaled integer arithmetic as before.

Complex Listing by Emily Short: misleading code in second example improved.

Bug fixed (0000929) making lists of rooms fail to "prepare" in Complex Listing by Emily Short.

Bug fixed (0001003) causing period removal to fail in Punctuation Removal by Emily Short (on Glulx only, and with different symptoms on different interpreters).

§10.27. Examples maintenance

Nine new Examples have been added to demonstrate new features: "Fun With Participles", "Greater Variety", "History Lab", "Narrative Register", "Olfactory Settings", "Relevant Relations", "Responsive", "Variety" and "Wesponses". Contrariwise, "Odins" has been removed, since it demonstrated adaptive text tricks now done much more easily with features built in to the language.

Of the 447 Examples in the previous build, some 114 have been slightly tweaked to make better use of modern Inform syntax; procedural rules have been removed, and so forth. An itemised list would be tiresome.

The sense of "Verbosity" has been reversed: it used to demonstrate how to make room descriptions verbose, but now that conventions have changed, it instead demonstrates how to make them not verbose.

Bug fixed (0000687) whereby the beverages in "Disenchantment Bay 12" would respond to OPEN with a run-time problem.

Bug fixed (0000689) whereby the hats in "Hatless 3" would sometimes appear to miss one of the quartet out, because the remaining hat would be placed on the player's head instead.

Bug fixed (0000697) whereby the "Circle Of Misery" baggage carousel was inadvertently portable.

Bug fixed (0000720) in "Lanista 2" whereby a run-time problem was produced just as the player died upon the sands.

Infelicity fixed (0000721) in "Odyssey" to remove side-effects on "every turn".

"Bogart", "Persephone" and "What Not To Wear" given slightly better modified inventory rules, in case people borrow these for their own stories. (Suggestion 5252251).

Minor bugs, turned up by 0000967, removed from "U-Stor-It", "Otranto", "Reflections", "Shipping Trunk", "Trachypachidae Maturin 1803".

Bug fixed (0001055) whereby TAKE ALL in "Low Light" would pick up the shadow.

Bug fixed (0001146) whereby "MRE" allowed multiple foods to interfere with each other's nutritional value.

Bug fixed (0001176) whereby the light-meter in "Unblinking" did not always disappear after use.

Bugs fixed (0001202, 0001212) to do with commentary in "Terror of the Sierra Madre" and "The Facts Were These".

Finally, from the department of might-have-been, Emily Short's epic espionage game Counterfeit Monkey came out: http://www.emshort.com/counterfeit_monkey Which we mention here since it began life in 2008 as what was going to be a three-star Inform example.

§10.28. Interpreter maintenance

Inform comes with browser interpreters built in, so that it can act on release instructions such as "Release along with an interpreter.", which tell Inform to make a website in which the current story is immediately playable.

** Parchment, by Dannii Willis (the interpreter for projects with the Z-machine setting):

Updated to "Parchment for Inform 7 (2014-04-21)". This replaces the old Gnusto interpreter core with a new one, ifvms.js, which is both faster and smaller, and is now licenced under a new BSD licence (rather than the GPL as it was before.)

Any updates to Parchment made between builds of Inform 7 can be found at: https://github.com/curiousdannii/parchment/

** Quixe, by Andrew Plotkin (the interpreter for projects with the Glulx setting):

Updated version to "Quixe for Inform 7 (v. 1.3.1)". Supports accelerated functions, access to real date and time, line input terminator keys, line input echo control, and resource streams; also various bug fixes and optimizations.

Any updates to Quixe made between builds of Inform 7 can be found at: http://eblong.com/zarf/glulx/quixe/

** Vorple, by Juhana Leinonen (a Z-machine interpreter for projects using the Vorple suite of extensions for multimedia):

This is included with the main Inform distribution for the first time, as part of what we hope will be much greater integration in future. See vorple-if.com for more.

Chapter 11: Earlier builds

§11.1. What was new in builds 6E59 and 6G60 (June and December 2010); §11.2. What was new in build 5Z71 (April 2009); §11.3. What was new in build 5U92 (September 2008); §11.4. What was new in build 5T18 (April 2008); §11.5. What was new in build 5J39 (December 2007); §11.6. What was new in build 5G67 (November 2007); §11.7. What was new in build 4X60 (August 2007); §11.8. What was new in build 4W37 (July 2007); §11.9. What was new in build 4U65 (April 2007); §11.10. What was new in build 4S08 (March 2007)

§11.1. What was new in builds 6E59 and 6G60 (June and December 2010)

As this release was being prepared, the world's largest census was taken, in India; the Eyjafjallajökull volcano in Iceland cut off air routes to Europe; in Ireland, pubs in Limerick opened on Good Friday, and a grey seal which had escaped from London Zoo was found in the seaside town of Skerries; element 117, ununseptium, was created inside atomic reactors; the Vatican declared that the Turin Shroud was not a forgery, but a mystery beyond human artistry; Lactococcus lactis became Wisconsin's official State Microbe following the passing of Assembly Bill 556 (Wisconsin's State Dance, incidentally, is the polka); Lady Gaga became the first singer to break one billion plays on YouTube, while Rukidi IV of Toro came of age and inherited his kingdom; and Cambridge had its revenge in the 156th Boat Race, defeating Oxford.

In the world of Inform, the Release mechanism was improved, with better feedback and a new ability to generate websites in which the project can be played in-browser. The system of kinds was made much more flexible and expressive, and phrase definitions gained in power as a result. A new chapter on Advanced Phrases was added to the manual, covering functional and generic programming. Properties, assemblies and relations were all reworked to be applicable much more consistently across the whole range of values, rather than being restricted only to objects, simplifying the language. Limits on the lengths of names of relations, verbs, prepositions, and directions were all lifted. The documentation and the Phrasebook index were revised and harmonised.

The 6G60 build followed six months later, to correct bugs and improve the Index, but the language itself did not change.

6E59 (12 June 2010)

This is a major release of Inform: the first in a little over a year, and
with a change log well over double the previous record size - large enough
to need a table of contents for the first time. Inform has new icons, and
a slightly revised design; more than 250 bug reports have been closed, so
that it currently has no issues open. There are minor surface enhancements
right across the language, and these are (mainly) the result not of fiddling
but of substantial rewrites of the underlying compiler. Many exceptions
have gone, and the language's design is more uniform as a result. 6E59
contains many changes from 5Z71 and it may take authors a day or two to
adapt their existing source text to these changes, but it should also prove
a stronger and more reliable Inform to work with. For the first time there
was a substantial third-party exercise in beta-testing the release, and
as from this build we are also launching a public suggestions forum and
an open bug-tracker.

Contents:
	1. INFORM FOR OS X
	2. INFORM FOR WINDOWS
	3. INFORM FOR GNOME ON LINUX
	4. RELEASING
	5. RELATIONS
	6. ASSEMBLIES
	7. KINDS
	8. MAP, FILTER AND REDUCE
	9. GENERIC PHRASES
	10. PROPERTIES
	11. SCENES
	12. RULEBOOKS
	13. INFLECTIONS
	14. MINOR NEW FEATURES
	15. WORD LIMITS ON RELATIONS, VERBS, PREPOSITIONS AND DIRECTIONS
	16. ACTIONS IN THE STANDARD RULES
	17. DOCUMENTATION, PROBLEMS AND INDEX
	18. DEPRECATED PHRASES
	19. MAINTENANCE
	20. EXAMPLES
	21. BUILT-IN EXTENSIONS
	22. A NOTE ABOUT FIGURE AND SOUND NAMES
	23. A NOTE ABOUT EXTERNAL FILES

1. INFORM FOR OS X

The user interface has been tidied up in a number of small but, we hope,
pleasing ways, and the menu structure should be easier to navigate,
especially for newcomers:

	File  Edit  Format  Play  Replay  Release  Window  Help

The preferences have similarly been reorganised, and the Settings panel is
more explanatory. Numerous features useful only for I6 projects are now
invisible for I7 projects, which makes the system much easier to learn.
(But it won't take experienced users long to find everything again.)

A new setting, for Randomness, makes it possible to fix the random numbers
generated within Inform so that repeat runs produce the same "random" outcomes,
which sometimes makes testing easier. (This only applies within the application,
and it's switched off by default; it never affects a Released story file.)

2. INFORM FOR WINDOWS

The code for the source tabs has been rewritten to make use of the open
source text editing component "Scintilla". This allows a number of missing
features to be implemented, and will allow further changes to support all
of the features available in the OS X version of the application.

Making a selection in the contents pane now causes the source pane to show
that selection only. The old behaviour, of showing the whole source but
going to the selection, can be obtained by holding down the shift key when
selecting.

Wrapped lines are now slightly indented by default, and new lines start
auto-indented to the same extent as the line above: both these options can
be disabled from the preferences dialog.

The new Format menu allows lines to be indented left and right.

Editing the skein now marks the project as being changed.

The background colours in the transcript now follow the same logic as
for the OS X application. The left hand column, showing the output
from the game, is coloured light blue if the output is the same as the
previous run-through of the game, and light red if the output now differs.
The right hand column, showing the "blessed" transcript, is coloured blue
if the transcript matches the game's output, red if it differs, and
yellow if it differs but only due to trivial whitespace changes.

The "Replay Commands Blessed in Transcript" option, which is on the new
Replay menu, now plays all skein threads that contain at least one blessed
knot. After playing, if any blessed knots fail to match, the skein shows
the first such knot.

On the new Replay menu are commands to show the last played command in
the skein and the transcript, and to change the selected knot in the
transcript to step through changed commands and commands for which the
transcript does not match the blessed text.

The new Release menu has commands to open the Materials folder in a new
Explorer window, and to export the game's iFiction record to a new file.

The Window menu has been re-arranged so that access to all tabs, and all
the Index sub-tabs, is available from sub-menus and shortcut keys.

Pressing F4 now shows the whole of the source text in the Source tab. This
is equivalent to bringing up the Contents view and clicking on the very
top heading.

3. INFORM FOR GNOME ON LINUX

The menus and dialogs have undergone various rearrangements similar to
those of the OS X version.

The Glulxe and Git interpreters that run in the Game tab have been updated
to version 0.4.5 and 1.2.6 respectively. Likewise, the Gargoyle system that
runs them has been updated to a more recent revision, which supports
hyperlinks, and copying and pasting from the Game tab.

The Documentation tabs now always show scrollbars, to prevent the "next"
arrow from changing places when you are paging through the documentation
quickly and land on a section that is short enough to fit on one page.

If an error message references an extension, then clicking on the arrow
next to it will now open the extension and highlight the offending line.

Various minor bugs and memory leaks have been fixed.

4. RELEASING

Feedback after clicking the "Release" button has been much improved, with
Inform either producing a report on what has happened or a legible list of
problems. Inform has always been able to release a project with supplementary
material added, right up to a mini-website for housing it, and in this build
we add the ability to create a web page making the project playable
in-browser. The new syntax:

	Release along with an interpreter.

causes Inform to bundle up a customised copy of a Javascript interpreter,
along with a suitably encoded story file, so that the eventual player can
just visit the page in any modern browser and begin playing. We believe that
giving Inform a one-click way to make such web pages will help IF authors
to reach out to casual gamers on the web.

There has been great interest in browser-based story file interpretation
recently; as recently as a few years ago this would have been prohibitively
slow, but continuing increases in processor speed - and intensive work by
browser manufacturers in optimising Javascript performance - have made this
a genuinely workable option today. Projects such as "Silverglulxe", "Leaflet"
and "Parchment" have made considerable progress, and we would like Inform to
help this development.

Inform ships with "Parchment" built in. At present this supports only
projects using the Z-machine story file format, but we have made every effort
to help Inform to accommodate future developments, and to enable it to be
used with other interpreters, too:

(a) Interpreters are stored by Inform in almost exactly the same way as
website templates are. Each must have a name; the default is "Parchment",
just as the default website template is called "Standard", but it's easy
to specify something different:

	Release along with the "Urbzig" interpreter.

(b) Exactly as with website templates, Inform looks for these first in the
"Templates" subfolder of the current project's "Materials" folder; then in
the "Templates" subfolder of the Inform folder on the user's computer (the
details vary with platform, but for instance on Mac OS X this is the folder
"~/Library/Inform", where "~" is the user's home folder); and lastly in its
own built-in stock, hidden away inside the Inform application. "Parchment"
is undergoing rapid development; placing any new copy of it in one of the
two locations above enables the user to get its benefits straight away,
without having to wait for some future build of Inform to incorporate the
update.

(c) An interpreter is stored as a folder of Javascript and/or CSS files
and/or images, together with a file called "(manifest).txt" which describes
it and how Inform should put together a story file for it to play. The
manifest for "Parchment" is heavily commented, and should help provide a
model for other interpreter-writers to use. We very much hope that authors
of other Javascript-based interpreters will find it straightforward to use
this system, and we will be very happy to look at any problems they have.

Another notable change is that "Release" now always releases the story
file into the "Release" subfolder of the project's "Materials" folder -
creating these if they do not already exist. In previous builds, it almost
always did so; but would put up a Save... dialogue box if the release
contained only the story file and nothing else. In practice, most
serious releases are going to involve at least some material beyond the
story file, and for consistency's sake we've got rid of the Save...
dialogue box and gone for the "Release" folder in all cases.

Miscellaneous small changes have been made to the "Release" mechanism
throughout; for example, a problem to do with Skein files which have lines
over 10K in length has been removed (the threshold was raised to 50K and
warnings about trimming have replaced errors), and a more serious bug to
do with projects containing around 500 or more images (which affected
Windows users but not OS X or Linux) has been fixed.

5. RELATIONS

Relations are central to Inform. Every verb's meaning is a relation, and
Inform's model of the world is based on relationships holding between objects
and/or other values.

This build makes it possible to define relations on any kinds of value (not,
as before, only on finite kinds and even then with petty restrictions); to
use relations as first-class values in their own right; and to create
relations on a temporary basis.

(a) Relations on any kinds of value:

We can now define relations between more or less anything:

	Partnership relates various texts to various texts.

	The verb to belong with (he belongs with, they belong with) implies the
	partnership relation.

	"cheese" belongs with "crackers".
	"clam" belongs with "chowder".

And this allows us to create large and varied data structures. A relation is a
natural generalisation of an associative array (an "associative hash" in Perl,
a "dictionary" in Python, a "table" in Lua, and so on - the idea goes back
at least to Smalltalk and the mid-1970s). In fact, an associative array is
exactly a various-to-one relation in Inform terms.

There are two caveats:

	(i) Previous builds would have rejected this because the domain
	(texts) is simply too big. The new build makes use of hash tables
	dynamically built in allocated memory to cope with this (using
	run-time code generously contributed by Jesse McGrew) - as such it
	really only works efficiently when the Settings for the project
	are set to the Glulx virtual machine.

	(ii) Inform isn't good at reasoning with relations when the domains
	are too big to make search loops practicable, so some constructions
	like "if 5 tallies with an even number" - where "tallies with" means
	a various-to-various relation of numbers to numbers - aren't allowed.
	But see below.

(b) Extracting values from relations:

Suppose we've defined the example partnership relation above. How could we
find out what, if anything, "caviar" belongs with? It would be impractical
to keep trying

	if "caviar" belongs with "aardvarks", ...
	if "caviar" belongs with "abacuses", ...
	...

Instead:

	if "caviar" relates to a text by the partnership relation, ...

tests whether or not it relates to anything; and if it does,

	a text which "caviar" relates to by the partnership relation

will produce one such text. Of course, there might be many: so

	list of texts which "caviar" relates to by the partnership relation

will produce them all. And we can also look at this the other way round:

	if a text relates to "caviar" by the partnership relation, ...
	a text which relates to "caviar" by the partnership relation
	list of texts which relate to "caviar" by the partnership relation

Still more interesting are the slightly tongue-twister-like:

	list of texts which the partnership relation relates
	list of texts which the partnership relation relates to

If we had written:

	"cheese" belongs with "crackers".
	"clam" belongs with "chowder".

then these lists might be { "cheese", "clam" } and { "crackers", "chowder" }
respectively. (For efficiency reasons, there are no guarantees about what
order the lists have - but they can of course always be sorted when found.)

(c) Relations as themselves values:

Relations have always been values, but in past builds their kind was simply
"relation", which made it impossible to distinguish, say, the visibility
relation (can one person see another?) from, say, these:

	Parity relates a number (called N) to a number (called M) when N minus M
	is even.

	Joint magnitude relates a number (called N) to a number (called M) when
	N plus M is greater than 7.

In any case, little could usefully be done with relations as values, because
there was no good way to test or assert them other than explicitly.

In this build, a relation has the kind "relation of K to L", where K and L are
the kinds of the two things it relates. For instance, "joint magnitude relation"
has the kind "relation of numbers to numbers"; though it's also allowed to
write just "relation of numbers", because Inform assumes both kinds are the
same if only one is given. We can now write, say:

	To chart (R - a relation of numbers):
		repeat with N running from 1 to 5:
			repeat with M running from 1 to 5:
				if R relates N to M, say "[N] <=> [M]   ";
			say "[line break]";

and now "chart parity relation" will work nicely, but "chart visibility
relation" will be rejected (as it should be). More ambitiously:

	When play begins:
		let L be { parity relation, joint magnitude relation };
		repeat with R running through L:
			chart R;

Here the kind of L is "list of relations of numbers to numbers".

In general, we can write

	if R relates X to Y, ...
	now R relates X to Y;
	now R does not relate X to Y;

to test, set and unset a relation R between two values, though of course
Inform checks that the values have the right kind and produces a problem
message if not.

(d) Adjectives applying to relations:

The following are now defined:

	"empty" - nothing relates to anything else
	"symmetric" - by definition X relates to Y if and only if Y relates to X
	"equivalence" - this is a relation "in groups", or an "equivalence relation"
	"one-to-one" - it relates one K to one L
	"one-to-various" - similarly
	"various-to-one" - similarly
	"various-to-various" - similarly

So for example it's possible to ask

	if R is a symmetric one-to-one relation of texts, ...

With some relations, it's possible to clear them out by writing:

	now R is empty;

and with temporary relations (see below), it's even possible to change their
valencies (one-to-one vs. one-to-various, etc.) using "now", but only when
they are empty. The exceptions where "empty" can't be used are those which
can't be changed at all, and a few built-in cases such as "support",
"containment" and "incorporation", where emptying would dissolve the model
world in a disastrous way.

(e) Making temporary relations:

In past builds of Inform, the relations were all created explicitly by the
source text. The stock of relations which exist at the start of play could
not be changed; the relationships might change - sometimes Red Riding Hood
would be in the Woodcutter's Cottage, sometimes not - but the relations
themselves (in this case, containment) were eternal.

This is no longer true, and it's now easy to create relations as dynamic
data structures, like lists or indexed texts. For example:

	let the password dictionary be a relation of texts;

This makes a purely temporary various-to-various relation between texts,
which lasts as long as the temporary value "password dictionary" lasts.
By default, relations are various-to-various, but we could instead write,
say:

	let the nicknames catalogue be a various-to-one relation of texts;

Such a relation exists only in the current phrase, and is destroyed when
the phrase finishes, like any other "let". Of course there's no verb whose
meaning in this relation, but that's no obstacle, because we can manipulate
it using "relates":

	now the nicknames catalogue relates "Trudy" to "Snake-eyes";

(At present such a relation cannot be used outside its own phrase, but we
hope to enable this in future builds by means of closures.)

6. ASSEMBLIES

Up to now, assemblies like this:

	A signpost is a kind of thing. Every room contains a signpost.

have been deprecated as not always reliable - it was a bad idea to make
constructions on the basic kinds "room", "container", "supporter", "door"
or "thing", the above being an example of an assembly on "room". That
restriction is now lifted, and the above works as it looks as if it should.

Assemblies can now involve values as well as objects. For example, if we
start from:

	A colour is a kind of value. The colours are red, green and blue.
	Liking relates various people to various colours.
	The verb to like (he likes, they like, it is liked) implies the liking relation.

then the assembly:

	Every person likes a colour.

will produce an initial situation like so:

	>relations
	Liking relates various people to various colours:
	  You  >=>  your colour
	  Daphne  >=>  Daphne's colour

Here the assembly process has created two new colour values. Had the assembly
instead been written:

	A person likes every colour.

then the result would be:

	Liking relates various people to various colours:
	  The person  >=>  red
	  The person  >=>  green
	  The person  >=>  blue

where this time three new people have been created. Note that these people have
no fancy names. But we can arrange for that with another new feature:

	A person (called its fan) likes every colour.

Which would instead produce:

	Liking relates various people to various colours:
	  Red's fan  >=>  red
	  Green's fan  >=>  green
	  Blue's fan  >=>  blue

Similarly,

	Every person likes a colour (called his favourite colour).

produces:

	Liking relates various people to various colours:
	  You  >=>  your favourite colour
	  Daphne  >=>  Daphne's favourite colour

Just as "its" (or "his" or "her" or "their") expands out to a possessive form
of the name of the owner, so to speak, so "it" (or "he" or "she" or "they" or
"him" or "them") expands out to the name itself. Thus:

	A person (called the world's leading fan of it) likes every colour.

produces:

	Liking relates various people to various colours:
	  World's leading fan of red  >=>  red
	  World's leading fan of green  >=>  green
	  World's leading fan of blue  >=>  blue

All of these callings can of course be made for standard assemblies of
objects too; for example,

	Every room contains a vehicle (called its buggy).

would make a whole lot of suitably named buggies.

The rule on what happens if there's no "(called ...)" text might be worth
spelling out exactly:

	(1) If we are assembling a value of kind K, then the calling text is
		taken as if it were "(called its K)" - for instance, "(called its
		colour)" in the first example above, which resulted in names like
		"your colour" and "Daphne's colour".

		However, if that results in a name which already exists, a number
		is suffixed to make it a unique name; for instance, if there were
		six anonymous people, then "Every person likes a colour" would
		result in names like "person's colour 2", "person's colour 3", and
		so forth. (It's a bad idea to write assemblies where this could
		ever matter.)

	(2) If we are assembling an object of kind K, then no name is attached
		unless the relationship is incorporation - i.e., being a part of
		something - and the object being attached to already has a name;
		in that case, the calling text is again "(called its K)".

The reason that the convention differs between objects and values is that
objects are allowed to have names clashing with other objects, or no name at
all, whereas values have to have names belonging to themselves alone.

7. KINDS

As a convenience for debugging awkward phrases, the following:

	showme V;

works for any value V, and prints out V, its kind, and then (unless it is a
constant) its current value. For example:

	When play begins:
		showme indigo;
		showme location;
		showme the list of vivid colours;

might open play by printing up:

	colour: indigo
	"location" = object: Lille Conservatoire
	"list of vivid colours" = list of colours: {red, indigo, chartreuse}

This is intended purely for testing. In a Release version, "showme" is always
silent, so that if any "showme" phrases are left in by accident, they'll never
be seen by anyone else.

Almost every kind has a "default value", that is, a value used when Inform
knows that a variable or table entry should contain something of this kind,
but doesn't know what it is. The phrase

	default value of K

evaluates to this value, for any named kind K. For example,

	showme default value of time;

produces the output:

	"default value of time" = time: 9:00 am

This can be useful when the default value is needed, but has no convenient
natural-language name; for example, "default value of table name", or
"default value of sound name".

Enumerated kinds have always had phrases to make it easier to trawl through
their values: for instance,

	the colour after C
	the colour before C
	a random colour
	a random colour between orange and blue
	a random colour from orange to blue

(The last two are synonymous.) To these, we now add:

	the first value of colour
	the last value of colour

If, for example:

	Colour is a kind of value. The colours are red, orange, yellow, green,
	blue, indigo and violet.

then "the first value of colour" produces "red", and "the last value of colour"
produces "violet".

It is now possible to change how kinds relate to each other, but only if no
previous statements are contradicted by doing so. For example, the Standard
Rules say that "container" and "supporter" are kinds of "thing"; now supposing
we type:

	An enclosure is a kind of thing.
	A container is a kind of enclosure. A supporter is a kind of enclosure.

This is now allowed. Containers and supporters are still things; they have
merely become more specialised, and there is no contradiction. On the other
hand, this is incorrect:

	An enclosure is a kind of region.
	A container is a kind of enclosure. A supporter is a kind of enclosure.

This is a contradiction, since regions are not things, and Inform rejects
it with a problem message.

The "description" kind has been removed. In its place is a more expressive
one: "description of K" for any kind K - for example, "description of numbers",
which would be matched by "even numbers".

This may mean changing a small amount of existing source text; the change
should be as simple as replacing "description" by "description of objects".
(We apologise for the nuisance, but "description" was always a poor choice
of name, clashing with the property called "description", for instance.)

Given any two kinds K and L, the kind "relation of K to L" is now a kind.
More concisely, "relation of K" means the same as "relation of K to K".

Given any two kinds K and L, the kind "phrase K -> L" is now a kind. (This
is meant to look like a mathematical function arrow.) For example, the
phrase defined by

	To decide which number is the square of (N - a number): ...

has the kind "phrase number -> number". Brackets and commas are used if the
phrase combines several values: thus

	To decide which indexed text is (T - text) repeated (N - a number) times: ...

would have kind "phrase (text, number) -> indexed text". The word "nothing"
is used if there are no values in, or no value out - thus

	To decide which number is the magic target: ...

has kind "phrase nothing -> number", and

	To dig (eastward - length) by (northward - length): ...

has the kind "phrase (length, length) -> nothing".

Thus phrases can be stored in variables, properties and so on. We can give
any phrase a name like so:

	To decide what number is double (N - a number) (this is doubling):
		decide on N plus N.

This is the same syntax used to name rules, and the idea is the same. If we
try "showme doubling", the result is

	phrase number -> number: doubling

But there's no advantage to storing a phrase if it can't be used, so:

	showme doubling applied to 2;

produces

	"doubling applied to 2" = number: 4

There are versions of "applied to" for phrases applied to 0 to 3 arguments:

	F applied
	F applied to V
	F applied to V and W
	F applied to V and W and X

For phrases which do not produce a value, we use "apply":

	apply F;
	apply F to V;
	apply F to V and W;
	apply F to V and W and X;

The default value for "phrase K -> L" is a phrase which, no matter what value
of K it applies to, always produces the default value of L. It's a sort of
equivalent of the zero function in mathematics - indeed that's exactly what
it is, if L is "number". These trivial phrases have no names, but can be
referred to using "default value of...". Thus:

	let Q be a phrase numbers -> times;
	showme Q;
	showme Q applied to 4;
	showme Q applied to -7;

might produce:

	"q" = phrase number -> time: default value of phrase number -> time
	"q applied to 4" = time: 9:00 am
	"q applied to -7" = time: 9:00 am

Here Q is set to the default phrase because we didn't give it any other
value; it has the name we might expect ("default value of phrase number -> time")
and it works as advertised, producing 9:00 am no matter what number is fed in.

More ambitiously:

	let R be a phrase numbers -> (phrase numbers -> colours);
	showme R;
	showme R applied to 3;
	showme (R applied to 3) applied to 2;

might produce:

	"r" = phrase number -> (phrase number -> colour): default value of phrase
	number -> (phrase number -> colour)
	"r applied to 3" = phrase number -> colour: default value of phrase number
	-> colour
	"( r applied to 3 ) applied to 2" = colour: red

In the case where L is "nothing", we get a phrase which does nothing and
produces no value. For example, if we write:

	let S be a phrase numbers -> nothing;

then

	apply S to 17;

does nothing at all, but it's perfectly legal.

Just as phrases now have kinds, the same is true of the other "active" gadgets
within Inform: activities, rules and rulebooks.

For any kind K, "activity on K" is a kind. If we write:

	Tweaking the nose of something is an activity.
	Refreshing the screen is an activity.

then the first is an "activity on objects", and the second an "activity on
nothing". That was true in previous builds of Inform, too, though there was
no way to express the difference, and so Inform didn't typecheck it. (Indeed,
it turned out that a minor error in the Standard Rules was going uncaught as a
result.) But we can now write, say:

	Announcing something is an activity on numbers.
	Rule for announcing a number (called N): say "Ladies and gentlemen, [N]."

and then

	carry out the announcing activity with 12.

This won't be useful for many people, but it's more flexible and consistent,
and activities on pictures and sound effects may be a nice interface for
multimedia extensions to provide.

(The word "activity" is now an abbreviation for "activity on value", that is,
any kind of activity. It's unlikely that anyone will need to change existing
source text.)

Rules and rulebooks now have kinds which can be written as follows:

	rulebook
	K based rulebook
	rulebook producing L
	K based rulebook producing L

(and similarly for "rule"). See the RULEBOOKS section below for more; if you
have source text which makes use of values produced by rulebooks, you will need
to modify it, as those are now typechecked for the first time, and some syntax
changes have been necessary to make this reliable.

Finally, two of Inform's ways to store values are similarly extended, though
in practice it's rare to mention kinds of either sort explicitly in source
text, so people will mainly not notice.

	K valued property
	K valued table column

As a piece of syntactic sugar, writing "either/or property" is equivalent to
writing "truth state valued property".

Given that Inform now has seven constructions on kinds - lists, descriptions,
relations, activities, rules, rulebooks and phrases - some interesting
combinations are now open:

	phrase (relation of numbers to colours, number) -> list of colours

Brackets can be used to clarify matters:

	phrase (phrase number -> (phrase number -> number)) -> nothing

Nothing will make that a simple idea, but it's unambiguous and can be puzzled
out with practice.

The following sentences now have identical effect:

	Concept is a kind.
	Concept is a kind of object.

Previously Inform rejected the second form, but it's now being allowed for the
sake of consistency of syntax. Similarly:

	The green leather sofa is an object.

is now allowed; previously Inform would have demanded that it be said to be
a thing, a door, etc. (In the absence of other information, it will come out
as a thing, in fact.)

The kind "table name" can now be the kind of a variable whose value is not
explicitly declared.

The kind "action name" can now be repeated through, which means it's now
legal to form, say, "the list of action names".

The kind "use option" can similarly now be repeated through, and can be said,
for the first time. Two new adjectives have been defined for use options:
"active" and "inactive", with the obvious meanings. This means it's possible
to describe the current options with something like:

	say "We're currently using: [list of active use options].";

The result might be, say,

	We're currently using: dynamic memory allocation option [8192], maximum
	indexed text length option [1024], maximum things understood at once
	option [100], American dialect option and fast route-finding option.

This may be useful for testing purposes.

The former condition "using O", true if the option O is active, false
if not, has not yet been withdrawn but is now deprecated, and may be
removed in future builds, since it is redundant and less flexible; please
write "if O is active" instead of "if using O".

In the early days of Inform, built-in kinds of value had to have single word
names. That has long ceased to be true, but some of those awkward names
remained - for example, we had "indexed text" (two words) but "table-name"
(hyphenated to make it one word). All of those hyphenated kinds of value
are now written out in words, with the hyphens removed: thus

	table name    figure name    sound name    action name    equation name
	external file    Unicode character    use option    table column

The traditional hyphenated names are still recognised (table-name, figure-name
and so on), except for the hardly ever used "table-column", but the documentation
and Index pages always prefer the new unhyphenated forms.

The following kinds, always intended for internal use only, have been withdrawn:

	domain-description    miscellaneous-value    text-routine    boxed-quotation
	rule-outcome    abstract-relation

8. MAP, FILTER AND REDUCE

When a mass of computations has to be done, the traditional approach is to work
through them in a "repeat" loop. One modern alternative, growing in popularity,
is to form a list of inputs; then apply the same computation to each input in
turn to form a list of results (this is called "mapping"); throw out any
bad or unwanted results ("filtering"); and then combine the surviving results
into a single composite answer ("reducing", though some programming languages
call this "folding" or "accumulation"; it's a much-reinvented idea).

Inform provides all three of these fundamental list-processing operations. There
is no special term for a "map", because Inform treats it as another case of
"applied to". Thus:

	doubling applied to {2, 3, 4};

produces the list {4, 6, 8}. More divertingly, suppose we define:

	To decide what indexed text is the longhand form of (N - a number)
		(this is spelling out):
		decide on "[N in words]".

	To decide what indexed text is the consonant form of (T - indexed text)
		(this is txtng):
		replace the regular expression "<aeiou>" in T with "";
		decide on T.

Then we can write a chain:

	txtng applied to spelling out applied to doubling applied to {3, 8, 4, 19, 7}

to produce the value {"sx", "sxtn", "ght", "thrty-ght", "frtn"}.

Next, filtering. Here we make use of descriptions, in order to say what values
will be allowed through the filter. Thus:

	filter to even numbers of {3, 8, 4, 19, 7}

produces {8, 4}, with the values 3, 19, and 7 failing to make it through. (A
sufficiently fine filter may well thin out a list to a single entry, or even
no entries at all, but the result is always a list.) To get the full effect of
filtering, we probably need to define an adjective or two:

	Definition: an indexed text (called T) is lengthy if the number of
		characters in it is greater than 6.

so that we can then write, say:

	filter to lengthy indexed texts of spelling out applied to {15, 2, 20, 29, -4}

which produces {"fifteen", "twenty-nine", "minus four"}.

Lastly, reduction. In order to combine a whole list of values, we need a phrase
to combine any two. Here are some samples:

	To decide what number is the larger of (N - number) and (M - number)
		(this is maximizing):
		if N > M, decide on N;
		decide on M.

	To decide what number is the sum of (N - number) and (M - number)
		(this is summing):
		decide on N + M.

	To decide what indexed text is the concatenation of (X - indexed text) and
		(Y - indexed text) (this is concatenation):
		decide on "[X][Y]".

And here are some sample reductions:

	let X be the maximization reduction of {3, 8, 4, 19, 7};
	let Y be the summing reduction of {3, 8, 4, 19, 7};
	let Z be the concatenation reduction of txtng applied to spelling out
		applied to doubling applied to {3, 8, 4, 19, 7};

sets X to 19, the highest of the values, Y to 41, their sum, and Z to the
indexed text "sxsxtnghtthrty-ghtfrtn". In each case a list has been reduced
to a single value which somehow combines the contents.

Is map/filter/reduce always a good idea? Devotees point out that almost any
computation can be thought of in this way, and in systems where the work has
to be distributed around multiple processors it can be a very powerful tool.
(There are programming languages without loops where it's essentially the only
tool.) At its best, it reads very elegantly: one assembles all of the tools
needed - definitions of doubling, lengthy, spelling out, concatenation and
so on - and then each actual task is expressed in a single line at the end.

On the other hand, there are also times when this is a needlessly complicated
disguise for what could more easily be done with a "repeat" loop, and also
more efficiently since assembling and dismantling lists in memory does take
some overhead time. So these list operations are not a panacea, but it's good
to have them available.

9. GENERIC PHRASES

The following looks quite innocent:

	To say (V - value) twice: say "[V]. [V], I say!";

It's clear what we intend it to do, but previous builds of Inform would have
rejected it. "Value" is not itself a kind - it's too big and unspecific. For
instance, if we were to allow a variable to be just "a value", we could freely
set it to 12 one minute and to "dahlias" the next, and such a variable would
be dangerously useless since we would never know what could safely be done
with it.

So "value" is not a kind, but a kind of kind. Inform has quite a few of these:

	value, pointer value, word value, arithmetic value, enumerated value,
	sayable value

Most Inform users never notice these, since they belong to the eight-tenths
of the iceberg which is underwater, but they act as ways to say "a value of
any kind matching this can go here". For example, "value" is a way to say
"any kind at all"; "arithmetic value" is any kind which arithmetic can be
performed on (any kind with the little calculator icon in the Kinds index);
and so on. If we write:

	To double (V - arithmetic value): say "[V times 2].";

the restriction to "arithmetic value" means that although "double 3", "double
6 kg", etc., would be matched, "double the Entire Game" would not - you can't
perform arithmetic on scenes. Similarly, it would have been tidier to write:

	To say (V - sayable value) twice: say "[V]. [V], I say!";

because then Inform will make it clearer why "say X twice" won't work if X
is one of those rare values which it can't say (an activity, for instance).

Inform has always used generic definitions like these to set up the built-in
stock of phrases (though only with so-called inline bodies, that is, with
direct translations to Inform 6 code). In this build, it's now possible to
write generic definitions using proper Inform source text - so that both of
the above definitions are accepted, and they work just as they look as if
they should.

But those are toy examples. Notice the way "double" just said the answer,
instead of returning it - the trouble was that, not knowing the kind of V,
we couldn't say what the kind of its double would be. We needed a way of
saying "the same kind comes out as went in". This is how Inform expresses that:

	To decide which K is triple (original - arithmetic value of kind K):
		decide on 3 times the original.

Here, K stands for any kind which matches "arithmetic value". Inform supports
exactly 26 of these symbols, which are written A to Z, but it's customary to
use K and L. (They can be written in the plural if we like: e.g., "list of
Ks". But they must always use a capital letter: "list of k" is not allowed.)

Each symbol we use has to be declared in exactly one of the bracketed
ingredients for the phrase - here, the declaration is "arithmetic value of
kind K". That creates K and says that it has to be arithmetic; if we'd just
said "value of kind K", it could have been anything.

For a more ambitious example, here is the definition in the Standard Rules
of the mapping operation described above:

	To decide what list of L is (function - phrase K -> value of kind L)
		applied to (original list - list of values of kind K):
		let the result be a list of Ls;
		repeat with item running through the original list:
			let the mapped item be the function applied to the item;
			add the mapped item to the result;
		decide on the result.

Here we needed two symbols to explain the complicated way that the values
going in and out have to match up to each other. Note also the way that the
temporary variable "result" is created:

	let the result be a list of Ls;

Ordinarily, of course, "L" is not a kind. But within the body of a phrase
definition, it means the kind which L matched. For instance, if we try

	showme spelling out applied to {3, 7, 11};

then in this usage "L" becomes "indexed text", because spelling out is a
phrase whose kind is "phrase number -> indexed text".

Sometimes a phrase needs to know what kind it's to work on, but isn't going
to be given any particular value of it. For example:

	To assay (name of kind of value K):
		repeat with item running through Ks:
			say "There's [item]."

Note that there's no hyphen, and no name for the bracketed token - it only
sets K. We can then have, say:

	assay colours;
	assay vehicles;

(But "assay texts;" would throw a problem message, because we can't repeat
through all possible texts.)

When a symbol occurs several times in the same definition, subtle differences
can arise according to which appearance is the declaration. These are not
quite the same:

	To hunt for (V - value of kind K) in (L - list of Ks): ...
	To hunt for (V - K) in (L - list of values of kind K): ...

Consider:

	let T be "[location]" in title case;
	hunt for T in {"Greater London", "Greater Basildon"};

Here T is an indexed text, but the list is of texts; and a text can be used in
place of an indexed text, but not vice versa. This will match the first
definition, because K is set to "indexed text", but it won't match the second,
where K is set to "text".

10. PROPERTIES

The handling of properties has been simplified and made more systematic in
this build, removing a number of tiresome exceptions. In particular, eight
ways in which "object" differed from other kinds have been removed:

(a) It's possible to give properties to "object", and indeed the Standard
Rules now include:

	An object has a text called printed name.
	An object can be plural-named or singular-named. An object is usually
	singular-named.

Previously one had to specify them each time for each of the fundamental kinds
in turn (thing, room, direction, region), which was tiresome. The problem
was essentially that "object" did not behave as if it were a property-owning
kind; now it does.

(b) Relations in groups, one to various relations, various to one relations,
and one to one relations are no longer restricted to objects - they can be
defined over all kinds. Again, objects are no longer a special case.

(c) Properties have always been able to be held by several kinds of object
independently - for example "matching key" is held by both doors and
containers - but in previous builds that wasn't true for more general kinds.
A property of a scene couldn't be a property of anything else. This is no
longer true. (Indeed, scenes now have the "description" property, just as
objects do.)

(d) Any value which can have properties at all can now have a condition
property, e.g., thus:

	Colour is a kind of value. The colours are red, green and white.
	A colour can be bright, neutral or flat. Green is neutral.

Condition properties were previously restricted to objects only.

(e) Implications can now be written for any values capable of holding
properties, not only for objects. Thus:

	Colour is a kind of value. The colours are red, green and blue.
	A colour can be zesty or flat. A colour can be bright or dull.
	Red and blue are bright. Blue is flat.

	A bright colour is usually zesty.

results in red being zesty, but blue and green being flat; blue because the
source text explicitly says so (which trumps the "usually"), and green because
this isn't a bright colour, so the implication doesn't arise. Again, all of
this works exactly as it does already for objects.

(f) Inform has always allowed a piece of double-quoted text, as a complete
sentence all by itself, to set a description for the object currently being
talked about. This now works for a named value, too, provided that the
value is of a kind which has the "description" property. For example,
the Standard Rules now include the following:

	A scene has a text called description.
	When a scene (called the event) begins:
		if the description of the event is not "",
			say "[the description of the event][paragraph break]".

which enables any scene to have a description text, which is printed when it
begins. For example, we could write:

	Arrival is a scene. "There's a flourish of trumpets."

(g) Adjectives can now be given specific definitions for named values.
(Previously they could be defined for any kind and for any specific object,
but not for specific values in general.) This allows, e.g.:

	A colour is a kind of value. The colours are red, green and blue.
	Definition: red is subtle if the player is a woman.
	Definition: a colour is subtle if it is blue.

The first definition here takes precedence, of course, since it has the
more specific domain. If the player's a woman, the subtle colours are red
and blue; if not, just blue.

(h) The pronoun "it" can now mean either an object or a named value, whereas
previously it could only be an object. Thus:

	Colour is a kind of value. A colour can be zesty or flat.
	Mauve is a colour. It is zesty.

makes mauve a zesty colour. (The restriction to named values is because we
really don't want "it" to mean 63, or the text "frog", etc., just because
such a value has been mentioned in a previous sentence.)

It's now possible to have a topic valued property, that is, a property whose
content is a topic. (This is possibly useful when defining things or values
using a table, one of whose columns holds topics.)

The kinds "figure name", "sound name" and "external file" can all now have
properties. For example:

	File format is a kind of value. The file formats are plain
	text, HTML and CSS. An external-file has a file format.

	The File of Ghosts is HTML.

Similarly, all three can be understood in commands. This is likely to be
useful only for testing purposes, but that's a good enough reason to
provide it.

The either/or property "initially carried" is withdrawn, though sentences
such as:

	The umbrella is initially carried.

continue to work, so it's likely that nobody will notice any difference. (The
word "initially" is redundant here; this property goes back to the early
days of Inform, when sentences mentioning the player were more restricted.)

Previously, certain core Inform properties had the anomalous behaviour that
if they were not explicitly defined then they could be read but not written,
and would show up as not provided - for instance, the "description" of a
thing, or the "carrying capacity" of a container. The same wasn't true for
new properties created within the source text. This anomaly, which came out
of Inform 6 memory economies now of very little purpose, is revoked. For
example, a thing with nothing special about it now has the description ""
(an empty text) rather than not providing a description at all; this means
that, for example, the test

	if the description of R is "", ...

will now work correctly in the case where R is a room whose description has
never been specified.

It used to be legal, but deprecated, to create a property like so:

	An elevator has a number that varies called maximum capacity.

The "that varies" is redundant here, and confusingly similar to the syntax
for creating variables. None of the Examples has ever used this syntax, and
most users probably weren't aware it was allowed. Well, it isn't any more.

Inconsistencies to do with inherited properties of values are now more
consistently checked: e.g.,

	Colour is a kind of value. The colours are red, blue and green. A colour
	can be vivid or drab. A colour is always vivid. Green is drab.

now produces a problem message, as it clearly should.

11. SCENES

Up to now, every scene has had a "when S begins" and "when S ends" rulebook,
but there has been no way to express rules generalising about scenes. We
can now write, e.g.:

	A scene can be bright or dim. A scene is usually dim. Dawn is a bright scene.

	When a scene which is bright ends: say "So passes the bright [scene being changed]."

	When a recurring scene begins: say "Groundhog Day!"

Scenes can now be understood in commands, which may be useful for testing.

The built-in Entire Game is not supposed to be modifiable - that is, it can't
be made to begin or end when other scenes do. This is now enforced with a
problem message.

The Scenes index is now more helpful in explaining Entire Game, and also marks
which scenes are recurring (and this now includes Entire Game).

12. RULEBOOKS

"When... begins" and "when... ends" are scene based rulebooks, meaning that they
take a parameter which is a scene. Inform has always had object based rulebooks,
but in the past that's been the only kind allowed here; Inform now allows, e.g.:

	Grading is a number based rulebook.

	Grading 5: say "It's five. What can I say?" instead.
	Grading an odd number (called N): say "There's something odd about [N]." instead.
	Grading a number (called N): say "Just [N]." instead.

	When play begins:
	repeat with N running from 1 to 10:
		say "Grading [N]: ";
		consider the grading rulebook for N.

which produces:

	Grading 1: There's something odd about 1.
	Grading 2: Just 2.
	Grading 3: There's something odd about 3.
	Grading 4: Just 4.
	Grading 5: It's five. What can I say?
	Grading 6: Just 6.
	Grading 7: There's something odd about 7.
	Grading 8: Just 8.
	Grading 9: There's something odd about 9.
	Grading 10: Just 10.

(A technicality: The familiar IF rulebooks like "instead" are all based on
actions, not values, so it looks as if they can't fit into this system; but
they can, because the Inform kinds system treats that as being based on
the kind "action name".)

There used to be three ways to describe rulebooks:

	rulebook    object-based rulebook   action-based rulebook

(though the last two could only be used at the moment of creation). But now
we ought to use one of these forms:

	rulebook
	K based rulebook
	rulebook producing L
	K based rulebook producing L

Here K is the kind of value we're basing the rulebook on. If this is omitted,
a test like "(R - rulebook)" will match any basis; and a creation like
"Drum summons rules is a rulebook." will use the basis "action name" - in other
words, will make an action-based rulebook. L is the kind of value produced
(see below) - again if this is unspecified in matching, it can be anything;
if it's unspecified at creation time, it will be "nothing". Thus

	Drum summons rules is a rulebook.

is equivalent to

	Drum summons rules is an action name based rulebook producing nothing.

The old syntaxes "object-based rulebook" and "action-based rulebook", with
hyphens, are still allowed, to avoid breaking existing source text. But
"object based rulebook" and simply "rulebook" are now preferred.

The other kind associated with a rulebook is the kind of value it produces,
though for the great majority of rulebooks this is "nothing" - they don't
produce values. (None of the rulebooks created by the Standard Rules do, and
there's only one such across the whole of the Examples.) In past builds, this
produced value has to be an object, but that wasn't checked, making this
little-used feature decidedly rickety.

Making it safe has meant changing the syntax, and that will mean altering
any existing source text which uses such rulebooks. The one Example we had
to change ("Feline Behavior") read, in part:

	The cat behavior rules is a rulebook.
	[...]

	Every turn:
		consider the cat behavior rules;
		if rule succeeded:
			let the destroyed object be the result of the rule;
			[...]

It now reads:

	The cat behavior rules is a rulebook producing an object.
	[...]

	Every turn:
		let the destroyed object be the object produced by the cat behavior rules;
		if the destroyed object is not nothing:
			[...]

Put more formally, the following phrases have been withdrawn:

	rule fails with result (O - an object)
	rule succeeded with result (O - an object)
	rule failed with result (O - an object)
	result of the rule

A rulebook can now only produce a value if it succeeds; and only if it was
declared as producing a value; that value can have any kind, and this is
enforced by Inform; and it can only be obtained if the rulebook is considered
using the new phrases

	the K produced by RB
	the K produced by RB for V

(the second being used if the rulebook RB is based on some value, and V is
the one being supplied here).

It used to be the case that a rule was not allowed to use a named rulebook
outcome unless it was filed in a rulebook which recognised this. What's now
true is that it's not allowed to use a named outcome if it's filed in a
rulebook which doesn't recognise this. The difference is subtle, but it
means that this combination:

	Does the player mean removing something not worn by the player from
		(this is the unlikely to mean removing unworn things rule):
		it is unlikely.

	The unlikely to mean removing unworn things rule is not listed in any rulebook.

...is now legal, whereas previously it would have thrown problem messages.

Finally, and unrelatedly, the logic Inform uses to decide what order to place
rules into rulebooks has been slightly improved. This is something we're
always wary of tinkering with, but the change means that a domain consisting
of a kind K together with one or more adjectives will now be considered
more specific than a kind L together with the same adjectives, if K is itself
a kind of L. For example, suppose we write:

	An envelope is a kind of container.

We then write:

	[R1] Before printing the name of a closed envelope while listing contents:
		do nothing instead.

	[R2] Before printing the name of a closed container while listing contents:
		say "closed ".

In previous builds of Inform, [R1] and [R2] were considered to have equal
specificity, so that the order of their effect would be the order in which
they were defined; in other words, they will only have the effect intended
by the writer of the above (Kathleen Fischer, as it happens) one way around.
In this build, [R1] is considered more specific than [R2], and always takes
precedence over it, regardless of definition order in the source text.

13. INFLECTIONS

(a) Previous builds generated plurals with a very crude algorithm (for instance,
"day" pluralised as "daies"); this sloppiness was mitigated by the face that
the user can specify plurals explicitly:

	The plural of ox is oxen.

Inform's default pluralisation method is now a form of Conway's algorithm,
and this should make most uses of "The plural of..." redundant now. For
example, the following now work:

	A wolf is a kind of animal. Two wolves are in the Stable.

and similarly for oxen, geese (but mongooses), sheep, wildebeest, bream and so
forth among animals alone; Inform constructs plurals such as vertebrae, quartos,
wharves, phenomena, jackanapes and smallpox correctly. In cases where a noun has
both a modern and classical plural, Inform prefers the modern form, so brothers,
not brethren, and cows, not kine. In the spirit of old-school interactive
fiction, Inform uses Tolkien's invention dwarves, not dwarfs, as plural of dwarf.

"The plural of..." continues to work, of course, and is still useful for
cases such as:

	The plural of brother in law is brothers in law.

Another improvement is that the new pluralizer respects capitalization, which
the old one did not:

	A Rolex is a kind of thing. The player carries two Rolexes.

would be understood, but an inventory listing would print as "two rolexes".
It now prints as "two Rolexes".

(b) In similar vein, a more careful algorithm derived from a pronunciation
dictionary is now used for choosing between "a" and "an" when Inform has to
make a guess; thus an honorary doctorate, an FBI windcheater, a U-boat,
a ouija board, a ukiyo-e print, among many others. But this change will be
less visible since Inform doesn't often have to guess; it will mainly show
in problem messages (where Inform will no longer complain that a value
should have been "an use option" or "an Unicode character", for example).

(c) Finally, the method used to guess past participles from present participles
has been improved by the inclusion of some 460 irregular verbs; for example,
catching to caught, fleeing to fled, crossbreeding to crossbred. This means
that the "with past participle..." syntax in action definitions now won't
be needed anywhere near so often, though of course it still works. For
example,

	Weaving is an action with past participle woven, applying to one thing.

can now simply be

	Weaving is an action applying to one thing.

A few cases are ambiguous; Inform prefers "got" to "gotten", but it's unlikely
to arise since in most IF situations "getting" is not an action - instead
"get" is synonymous with "take" and "taking" is the action.

14. MINOR NEW FEATURES

The interpretation of conditions which combine Inform's two past-tense syntaxes
has been changed. Thus,

	Every turn when we have waved the candle at least twice: ...

is legal, but - reading strictly by the specification, as previous builds did -
"we have waved the candle at least twice" could never be true; it implied
two or more distinct periods in which it was true that "we have waved the
candle" was true, with at least one intervening period in which it was false.
Such a situation can never come about. In this build of Inform, we read the
condition "we have waved the candle at least twice" to be counting actions,
not counting periods, which is far, far more likely to be what was meant.

It has always been possible to indicate map connections using the direction
alone (the origin being understood as the room being discussed), but up to
now, only in the form "Direction is Target", like the second sentence here:

	The Temple is a room. North is the Approach. The Sphinx is east.

The third sentence now works as expected: the Sphinx being east of the Temple.

The serial comma is now allowed in sentences like:

	A room can be lofty, regular, or poky.

Inform provides two ways to make headings hold source text whose use relates
to an extension. One is to say something like

	Part 1a - Alternative Leaps (in place of Part 1 - Leaps in Jumping by Eric Eve)

which says that what follows should be used instead of what's in the extension;
the other is

	Chapter 1P - Sidling (for use with Plurality by Emily Short)
	...
	Chapter 1NP - Sidling (for use without Plurality by Emily Short)
	...

giving source text to be used depending on whether the extension is being
included or not. In past builds, these two features were forbidden to "nest";
in this build, it's only the first kind which can't "nest". (That is, once
a chunk of text has been used in place of an extension's text, it can still
contain subheadings "for use with" or "for use without"; but it can't contain
subheadings "in place of".)

In previous builds, the "Options.txt" file (if present) was allowed only to
contain use options - that is, sentences such as "Use American dialect."
It is now allowed also to contain "Test ..."s and release instructions, so
for example the following is now a valid "Options.txt":

	Use American dialect.
	Test fish with "fish/fish with pole/angle".
	Release along with source text.

To recap, "Options.txt" is intended mainly for classroom use, in setting
up a standard configuration on multiple machines. Here the instructor can
make sure the Release button will do what she would like, and can arrange
for each student's copy of Inform to respond to given Test commands: for
instance, if the class has an assignment to create a simulation of a camera,
the instructor could set up "Options.txt" so that TEST CAMERA would run
through some commands the camera ought to respond to.

(The bug causing "Options.txt" to obstruct the bibliographic titling sentence
at the top of the visible source text has also been fixed; and a problem
message has been added for trying to do forbidden things with "Options.txt".)

The participles "worn", "carried" and "held" are now given additional
definitions in the Standard Rules as adjectives applying to things:

	Definition: a thing is worn if the player is wearing it.
	Definition: a thing is carried if the player is carrying it.
	Definition: a thing is held if the player is holding it.

Previous builds allowed some adjectival uses but not others, a little
inconsistently; for example, the following now works, but previously did not:

	A diamond bracelet is here. It is wearable. The description is
	"It sparkles [if worn]on your wrist[otherwise if carried]in your
	hand[end if]."

The adjectives "on-stage" and "off-stage" can now be made true using "now",
so, for instance, "now the diamonds are off-stage" is equivalent to "remove
the diamonds". (If we say "now the diamonds are on-stage" and they already
were, nothing happens; if they weren't, they are moved to the current
location.)

There are three new forms of "[one of]":

	"Maybe the victim is [one of]Adam[or]Bertrand[or]Carlos[then purely at
		random]."
	"Maybe the murderer is [one of]Colonel Mustard[or]Professor Plum[or]Cardinal
		Cerise[then at random]."

The first means that the alternatives are chosen in sequence until all have
been seen, but that after that they are chosen uniformly randomly. The
second is similar, except that once randomness is reached, care is taken to
avoid the same choice coming up twice running.

The third is really a shorthand form:

	"The screen door squeaks loudly as when you open it. [first time]Well,
	you'll get used to it eventually. [only]"

This is exactly equivalent to

	"The screen door squeaks loudly as when you open it. [one of]Well,
	you'll get used to it eventually. [or][stopping]";

but easier to read.

Inform, like Python and some other languages, uses indentation from the left
margin to show how phrases are grouped. In past builds, the practical limit
was 9 tab stops in, though this wasn't very clearly explained and the problem
message if exceeded was cryptic. The limit is now raised to 25 and a better
problem message has been created.

The phrase "repeat with V running from X to Y" previously worked only when X
and Y were numbers; it's now allowed for any arithmetic or enumerated values,
so

	repeat with counter running from 1 to 10:
		...
	repeat with counter running from 4 PM to 4:07 PM:
		...
	repeat with counter running from orange to indigo:
		...

are all allowed (supposing that we have a colour kind whose values are, say,
red, orange, yellow, green, blue, indigo and violet).

The phrases for making entries in a table blank have been made more consistent:

	blank out (table entry)
	blank out the whole row
	blank out the whole (column) of (table)
	blank out the whole of (table)

(The last two abilities are new.)

The phrases for altering the length of a list are worded using "entries";
for example, "truncate L to 10 entries". It's now legal to use the singular,
"truncate L to 1 entry", too.

Previous builds allowed rules in the "printing a parser error" activity to
test which error had occurred using rather clumsy fixed-wording phrases:

	if parser error is can only do that to something animate: ...

These have been withdrawn. For this build, the following should be used
instead:

	if the latest parser error is the can only do that to something animate
		error: ...

This is tidier since it is a standard comparison. A new kind of value,
"command parser error", exists to hold the possibilities; "can only do that to
something animate error" is one of these. (The others are listed on the Kinds
index page. They are all worded exactly as before, with the addition of the
word "error" at the end, as in this case.) The advantage of the new system,
aside from getting rid of 19 clumsy phrases, is that "latest parser error"
is now a variable; the value can be said, or stored, and so on. This is all
much more flexible.

In the startup rulebook, the first two rules - in fact, the first two rules
every Inform story file runs - have been transposed. So the initialise memory
rule now happens before the virtual machine startup rule, not vice versa.
Because the latter rule runs the "starting the virtual machine" activity, the
effect is that we sacrifice a little bit of that activity's ability to be
the very first thing run; but we gain the ability for this activity to use
indexed text, stored actions, and similarly complex data, since those depend
on memory having been initialised.

There is now a way to define an adjective in terms of an Inform 6 routine
which is more capable, since it can not only be tested, but also made true
or false using "now". For example:

	Definition: a scene is crucial if I6 routine "SceneCrucial" makes it so
		(it is essential to winning).

This is very similar to the existing syntax:

	Definition: a scene is vital if I6 routine "SceneVital" says so
		(it is essential to winning).

(a) Whereas "SceneVital" is just a test, "SceneCrucial" is called with two
arguments: SceneCrucial(S, -1) tests whether the scene is crucial or not and
returns true or false; SceneCrucial(S, true) must make it true; and
SceneCrucial(S, false) must make it false.

(b) If the adjective is defined over a kind of values stored in block form
on the heap, S is passed as a pointer to the block, not as a fresh copy.

Inform's automatically generated documentation on included extensions has
always listed names of kinds, objects, variables and so on; it now also lists
names of use options.

The maximum complexity of a single "say" - basically, the maximum number of
chunks it can contain, some being fixed text, others being substitutions -
has been increased from about 400 to about 4000. (In practice this removes the
limit altogether, since the maximum length of a single quoted text gets in
the way first. Having any maxima at all is unfortunate, of course, but it
enables the compiler to run faster, and makes it easier to catch punctuation
mistakes in the source.)

When Problem messages are reported inside an extension, Inform typically says
under what headings they occur, but doesn't make clear which extension is
involved, which can be a nuisance if many extensions are in use. In this build,
Inform explicitly names the extension.

A new use option, "Use no deprecated features", puts Inform into a mode where
it issues problem messages for syntaxes which are currently allowed but which
we expect to withdraw in future. At present this is used only with phrases;
see the Phrasebook index, where deprecated usages are marked with a red
warning triangle.

15. WORD LIMITS ON RELATIONS, VERBS, PREPOSITIONS AND DIRECTIONS

Most constructions in Inform can have quite long names. But in previous
builds, much tighter limits were placed on relation names, parts of verbs,
the wording of prepositions, and the names of directions.

					Example         Old maximum     New maximum
Relation name       containment     1               X - 1
Part of verb        wears           1               X - 4
Preposition         across from     3               X - 2
Direction           northwest       3               X - 2

The intention is that there should be no practical limit in any of these
cases; the current value of X is 32, which it's very difficult to see any
plausible source text ever needing to exceed.

For example, this is now allowed:

	The verb to cover oneself with (he covers himself with, they cover themselves
	with, he covered himself with, he is covering himself with) implies the
	wearing relation.

	Peter is covering himself with a tent-like raincoat.

Here each part of the verb is three words long; the maximum is now 28.
Similarly:

	The verb to be very far away from implies...

is a preposition four words long, which previous builds would have rejected.
The limit is now 30.

	Adept sensitivity relates one person to one vehicle.
	The verb to imagine (he imagines, they imagine) implies the adept sensitivity
	relation.
	Peter imagines the Astral Chariot.

Here we have a relation, "adept sensitivity", which is two words long; the
limit is now 31.

And if you should want:

	Just the tiniest smidge off magnetic north is a direction. The opposite of
	just the tiniest smidge off magnetic north is just the tiniest smidge
	off magnetic south.
	Just the tiniest smidge off magnetic south is a direction. The opposite of
	just the tiniest smidge off magnetic south is just the tiniest smidge
	off magnetic north.

then knock yourself out.

>--> Note that when a direction is created, a relation is automatically created
to represent being in that direction; for instance, "north" creates what is
now called the "mapping north relation". It used to be called the "mapping-north
relation", with a hyphen, to squeeze into the former requirement that relations
have one-word names. It's unlikely that much source text makes direct use of
these relations by name, so the change will probably not be noticed.

16. ACTIONS IN THE STANDARD RULES

Some of the small design decisions about actions in the Standard Rules go back
to accidents of implementation in the early 1990s (if not earlier still), and
have no rationale except custom and practice. We are very conservative about
changing them, all the same, since anything done here will affect essentially
every source text compiled with Inform. But for this build we have made a
systematic search for small changes, unlikely to cause much disruption, but
which will improve the playing experience.

(a) In its earliest works, Infocom introduced the now-traditional commands
VERBOSE, BRIEF and SUPERBRIEF for the player to choose how much detail to
see in room descriptions: the whole thing, even for a room revisited; the
whole thing the first time, but an abbreviated form after that; or always
only the abbreviated form. The default mode was BRIEF, the middle of these
positions.

In 1993, when Inform made its debut, this was still conventional, but since
then authors and players have increasingly found VERBOSE mode more natural.
Even a tiny iPhone screen shows more text that a 1980s micro did, and printing
time is now essentially zero, whereas a long description could take five to
ten seconds to print back then. Inform's fellow IF development system TADS
has long since used VERBOSE as the default; from this build, Inform is finally
following suit. So, farewell to default BRIEF mode (1981-2010).

Three new use options exist to set the default behaviour:

	Use VERBOSE room descriptions.
	Use BRIEF room descriptions.
	Use SUPERBRIEF room descriptions.

So if this change causes problems, simply add "Use BRIEF room descriptions."
to restore the old behaviour. For us, it changed the blessed transcripts of
45 out of about 440 examples, but never such that we minded the change.

(b) Inform has always been liberal in how it reads the word ALL in commands
typed by players - TAKE ALL really does mean all - but has given authors
the option to change this by writing rules for the "deciding whether all
includes" activity. As from this build, the Standard Rules include three
such rules to strike out people, scenery and things fixed in place. Thus:

	Studio is a room. Jenna is a woman in the Studio. Kenneth is a man in the
	Studio. The peacock, the script and the stage set are in the Studio.
	The stage set is fixed in place. The curtains are scenery in Studio.

the traditional reply to TAKE ALL would be:

	Jenna: I don't suppose Jenna would care for that.
	Kenneth: I don't suppose Kenneth would care for that.
	peacock: Taken.
	script: Taken.
	stage set: That's fixed in place.
	curtains: That's hardly portable.

With the new default conventions, it's just:

	peacock: Taken.
	script: Taken.

The new rules are named, of course, and can be cancelled if unwanted (see the
Rules index):

	exclude scenery from take all rule
	exclude people from take all rule
	exclude fixed in place things from take all rule

(c) In this release, the Inform parser changes the default way in which it
asks what is meant by an ambiguous noun such as FROST. It can ask the
question in two different forms:

	(1) Who do you mean, Jack Frost or Jill Frost?
	(2) Which do you mean, Jack Frost or Jill Frost?

In the past it has used form (1) if the token being parsed was "[someone]",
and (2) otherwise. This wasn't very accurate, as plenty of other tokens might
expect a person rather than a thing to be typed; but in English, it didn't
matter very much, because "which" wasn't too bad for people. In German, it
made a bigger difference, and at Christian Blümke's suggestion we are
incorporating a change worked out by German Inform users: message (1) is used
if all of the possible meanings refer to people, and message (2) otherwise.

(d) We have withdrawn the:

	examine undescribed containers rule

and replaced it with two new rules:

	examine containers rule
	examine supporters rule

The original rule converted the action of examining a container which had
no description text into a searching action instead. Sometimes this was a
sensible idea, but not always. Examining and searching are different actions,
and why should it make a difference whether there's any description or not?
(The original idea was to avoid a misleading "You see nothing special about..."
reply about a container which, in fact, contained interesting items. But
however pragmatic that is, it's not very convincing as a reason.) Moreover,
examining something requires only a line of sight to it, whereas searching
requires that the actor can touch the item in question; so converting one
into the other violates the spatial world model in some cases.

The new rules are (equivalent to) this:

	Carry out examining (this is the examine containers rule):
		if the noun is a container:
			if the noun is open or the noun is transparent:
				if something is in the noun:
					if the description of the noun is not "":
						say "[the description of the noun][paragraph break]";
					say "In [the noun] [is-are a list of things in the noun].";
					stop the action.

and similarly for supporters, but without transparency being an issue.

(e) We have withdrawn the:

	examine described devices rule
	examine undescribed devices rule

and replaced them with the:

	examine devices rule

which works much as the rules for containers and supporters do: the
description paragraph first, if there is one, then the status of the device
("The hot tap is switched on.").

(f) The command "switch [something]" is now understood as switching off if the
item in question is currently a device switched on, and vice versa. (Previously
it would always be understood as switching on.)

(g) The command "fix" is no longer a synonym for "tie". (There is too much
confusion of the two senses - "fix" in the sense of affix may mean "tie", but
"fix" in the sense of repair does not.)

(h) The command "get down" is now understood as exiting. (A natural thing to
type when, say, at the top of a library stepladder.)

(i) The command "get in" is now understood as equivalent to typing just
"enter". In general "enter" requires a noun - there could well be a choice
of enterable things available - but a rule new in this build, the

	find what to enter rule

automatically infers an enterable noun in the current location, if one is
available. (It has no effect if the player has typed something explicit, such
as "enter cage".)

(j) The command "look [something]" is understood as examining, as if it had
read "look at [something]". (This is not so much aimed at retro gaming fans
who want to recreate the full 1982 experience, but at novices, who often seem
to type commands like this.)

(k) In previous builds, the going action would be stopped by the

	can't go through closed doors rule

if the actor would need to pass through a closed door. That remains true, but
if the door is openable then the rule now tries opening the door first - thus
allowing players to walk through ordinary doors without having to type
explicit "open door" commands. (The popular "Locksmith" extension has always
provided this; anyone using that extension will see no change.)

(l) A new rule for the going action, the

	stand up before going rule

causes an actor to try getting off a supporter before going in a given
direction. (A rule which was previously an optional extra, demonstrated by the
"Hagia Sophia" Example. Use of the "Rideable Vehicles" extension unlists this
rule, i.e., abolishes it, since this extension makes supporters into mobile
things which can indeed be used to go from place to place.)

(m) The "putting it on" and "inserting it into" actions require the item
being put or inserted to be held by the actor; if it isn't, one of the rules:

	can't put what's not held rule
	can't insert what's not held rule

will stop the action. In this build, they first try to take the item, and
only stop the action if that fails.

(n) A quaint convention going back to the mid-1980s is that an inventory
listing changes the meaning of pronouns like "it". Thus

	> INV
	You are carrying a pineapple.
	> EAT IT

...would result in "it" meaning the pineapple. We think it's time to give up
on this convention, which causes nothing but confusion. Accordingly, we have
deleted the rule responsible:

	use inventory to set pronouns rule

(o) The run-time parser's handling of commands with commas in has been
changed; previously, a command such as

	> FRED, GO NORTH

would be parsed as an instruction for Fred to do something only because
FRED was not recognisable as a verb. This turned out to be unfortunate for
story files with Japanese characters called Takemoto ("Take" for short), or
for anyone called Don (a verb for putting on clothes), and so on. The
parser now considers the command to be an instruction provided that the
text up to the comma matches the name of a possible actor; this avoids
(most) false positives such as

	> TAKE BELL, BOOK AND CANDLE

(p) The "exiting" action has long had a variable called the "container
exited from", so that it's possible to write rules depending on what is
being got out of. This can now be referred to using "from", as in the
following example:

	After exiting from the Mini Cooper:
		say "You painstakingly unpack your limbs from the tiny car."

(q) The "giving" action has a new rule, imitating a similar one for dropping:

	can't give clothes being worn rule

(r) The "removing it from" action has an exemption in the "can't remove from
people rule", so that in the event that the actor is trying to remove something
from himself, this is converted to a taking off action. (For instance, if the
player is involuntarily wearing a monkey on his back, and types REMOVE
MONKEY FROM ME.)

(s) The commands TAKE ... OFF and PUT ... ON are now understood as taking off
and wearing, respectively, just as the commands TAKE OFF ... and PUT ON ...
always have been.

(Translators may need to note that as a result of these changes three library
messages, going action number 3, 4 and 5, have been removed; but there are
also three new ones, going action number 27 and 28, and Miscellany 75, which
is " The End " in English, and is used to provide a generic ending message.)

17. DOCUMENTATION, PROBLEMS AND INDEX

Problem messages reformatted to give more information in case of complicated
ambiguities to do with phrases; and problems suppressed when they are
follow-on problems arising only because variables weren't created properly.
For example, this source text:

	Every turn:
		repeat with X running from 1 to "fish":
			say "Hello! [X].";
			let Y be X plus X;
			increase score by Y;

would throw four problem messages in previous builds, but now it throws only
one. Inform realises that the author intends to create X, and even though he
botched it, Inform suppresses what would otherwise be problem messages in the
next two lines; it further realises that the idea is to create Y as well, and
suppresses the problem message that the last line would otherwise lead to.

The Phrasebook index has been redesigned. Each phrase is now provided with
a "plus" icon which, when clicked, reveals full documentation of what that
phrase does, along with a link to the relevant page in the manual; and the
manual has similarly been redesigned to match the Phrasebook.

The Kinds index has been reorganised to reflect the new structure of the
kinds system in Inform.

The Contents index now includes links to the documentation for any extensions
included in the project being indexed.

Timed events have moved from the obscure sub-panel of the Rules index, where
they had previously languished unnoticed, to the Scenes index. They now
include cross-references for each event to the points in the source text
which trigger them.

The Scenes index now marks which scenes are recurring, and clarifies the role
of the special Entire Game scene.

18. DEPRECATED PHRASES

With this build, we take a first step towards removing a few features of the
Inform language which, in the light of experience, we regret having introduced.
A few syntaxes change with every major release, of course, but we plan a
bigger change next time, and are now preparing the way for this.

There are some 367 built-in phrase definitions in the Standard Rules. The
great majority will stay, of course, but we intend to remove 34 of these
phrases in the next big release of Inform. This will inevitably cause a
little disruption, so we've done three things to ease the way:

(a) Each phrase due to be removed is now officially "deprecated", and marked
with a red warning triangle in the Phrasebook and in the documentation.
The documentation explains what to use instead.

(b) Deprecated phrases are not used in the Examples, except for a very few
cases where the only purpose of the Example is to show how to use the phrase
in question. They are similarly avoided by built-in Extensions, including the
Standard Rules.

(c) A new use option has been added:

	Use no deprecated features.

With this set, Inform will reject any of the deprecated phrases; so setting
this is a good way to see whether any existing source text is likely to give
trouble after the next release.

The deprecated phrases are a mixed bunch:

	say "[contents of object]"
	say "[the contents of object]"
	change (a stored value) to (value)
	change (object) to (property)
	change (object) to (enumerated value)
	delete (a table entry)
	if using the/-- (use option):
	if (a condition) then (a phrase)
	while (a condition) repeatedly (a phrase)
	while (a condition), (a phrase)
	ignore (rule)
	reinstate (rule)
	reject the result of (rule)
	accept the result of (rule)
	substitute (rule) for (rule)
	restore the original (rule)
	move (rule) to before (rule)
	move (rule) to after (rule)
	end the game in death
	end the game in victory
	end the game saying (text)
	resume the game
	if game is in progress:
	if game is over:
	if game ended in death:
	if game ended in victory:
	if it is before (time):
	if it is after (time):
	change the/-- player to (object)
	if in (object):
	award (number) point/points
	set pronouns from possessions of the player

Some of these are very familiar-looking, but almost all simply duplicate more
general constructions. "award 5 points", for instance, is exactly the same as
"increase the score by 5"; "change the time of day to 10 PM" is the same as
"now the time of day is 10 PM". Exotic forms of "if" and "while" are being
removed for simplicity's sake: people didn't use them much in practice.
That leaves two clusters of phrases - those for ending the game, and those
for procedural rules. With ending the game, we have adopted a more uniform
style of wording, and abolished the idea of "death" and "victory":

	end the story
	end the story finally
	end the story saying (text)
	end the story finally saying (text)
	if story has ended:
	if story has ended finally:
	if story has not ended:
	if story has not ended finally:
	resume the story

The difference between ending and ending finally is that a final ending is
one where we don't expect the reader to play again, and can safely show him
menu options such as Infocom's traditional AMUSING (which suggests alternative
unlikely possible plays). Thus "game" becomes "story", "death" becomes merely
the "end" and victory the "final end". In the process, we gain the ability to
have a final ending with wording other than "You have won"; and the default
ending text is now "The End", not "You have died". Sic transit gloria mundi.

Procedural rules, on the other hand, definitely do provide functionality
which is not available otherwise by a simple rewording. When they go, they
will be a small loss. But after four years of Inform 7's public use, we
find that very few people use them, and then almost always in situations
where it would be just as good to use "not listed in" sentences instead -
the main use of procedural rules is to abolish some built-in rule, but
that can be done just as well by unlisting it.

The reason for removing procedural rules is that it will enable optimisations
of the code generated by Inform to get faster run-time performance, which we
expect to become a more significant issue in future - the time may come when
the majority of IF players are running the story file in a browser; perhaps
even a browser on a relatively slow-CPU mobile device, such as an iPad. We
also hope to bring down the writeable memory usage at run-time, which is an
issue for story files running on the Z-machine (though not for Glulx, where
memory is essentially unlimited). Besides this, procedural rules often
confused authors (hardly anybody knows the difference between "follow" and
"consider" - a difference which will be abolished), and they made the Index
a little misleading, since it displayed the structure as it was before
being manipulated.

So we have swallowed our medicine, and deprecated procedural rules. They
were cool, but not worth the cost.

19. MAINTENANCE

There are so many bug fixes that a miscellaneous list has become unwieldy,
so here they are categorised under the headings used by our new bug-tracker.
Note that the following list excludes fixes to built-in extensions such
as Locksmith or Metric Units: for those, see below.

19.1. Source text and punctuation

(*) Bogus times of day such as "minus 6:23 PM" are no longer recognised; "minus"
can only be used with relative times, as in "minus six minutes".

(*) The I6 template reader has been made more forgiving of what it considers
malformed headings - marked by the use of an "@" character in the leftmost
column; some users ran into this by accidentally placing Z-machine or Glulx
assembly language, also marked by an "@" in I6, unindented on the left
margin of material included using "(-" and "-)". The template reader will
now handle any such material correctly, and a more helpful problem message
is produced if it nevertheless runs into trouble because of a stray "@".

19.2. Headings

(*) Bug fixed whereby it's impossible to use a heading to replace an existing
heading in an extension if that existing heading contains the words "in"
or "by" in its name; and problem messages related to heading tricks made
more explanatory.

(*) Part 3 of the Standard Rules now has slightly better section divisions,
making it easier to replace smaller chunks.

19.3. Extensions

-- -- --

19.4. Assertions and creations

(*) Bug fixed whereby "There are ..." sentences might fail if a number of things
were created with some modifying adjective, e.g. "There are four closed doors."

(*) Bug fixed whereby a player declared to be a particular person would not
always be placed into relationships asserted for "the player". For example,

	The player is a woman called Edna Marsh. The player holds a wrench.

...not resulting in Edna carrying the wrench.

(*) Problem message added to explain oddball mistakes like "A thing is a waiting
receptacle if it is an open container.", which in previous builds were met
with a rather vague and unhelpful complaint.

19.5. Model world

(*) Bug fixed whereby generalising about the "map region" property could cause
an internal error; for instance,

	The map region of a room is usually Jaguar Creek Valley.

Setting "map region" is not the preferred way to put rooms into regions,
but the above did work in past builds (and the "Permission to Visit" extension
apparently made use of that); the practice is hereby legalised, and the World
index now properly maps the result.

(*) Bug fixed whereby the fast route-finding algorithm for finding routes through
the map (the default route-finder in Glulx, but only used if the "Use fast
route-finding" option is chosen in the Z-machine) would always use doors,
even when not allowed to, and would return 0 rather than -1 for a count of
the number of steps of an impossible route.

(*) Bug fixed whereby the fast route-finding algorithm for finding routes through
the map would sometimes return "north" as the "best route from X to Y" in cases
where no route exists, rather than returning "nothing".

(*) Bug fixed whereby sudden movements of the player from a dark room into a
lighted one, which happen other than by the usual actions, could result in
the new room's description being shown twice over.

(*) Bug fixed (if it was really a bug) whereby the "maximum score" could not be
changed during play.

(*) Bug fixed whereby UNDO would be disallowed in a story where the "advance
time rule" had been unlisted, with Inform thinking that (since no time had
passed) there was nothing to UNDO back to.

(*) Problem message added to catch unused timed events. This is an arguable case,
because perhaps it could be said that it's legal to create timed events which
are never used. But it's a better idea to catch mistakes like this:

	At the time when supply of the air tank is -4:
		end the game saying "You have suffocated."

where the author believes incorrectly that the rule will fire when the
condition is true, whereas actually he has created a timed event with the
exotic name of "supply of the air tank is -4".

(*) Problem message added (in place of internal error) when a door is said to
be "south of nowhere", or for other such formulations involving "nowhere" as
the source of a map connection.

(*) Problem message added for non-thing objects being created inside or on top
of other objects. (The world model requires that the contents of a room must
be things, but earlier builds didn't check this; at run-time, strange things
could then occur.)

(*) Problem message added (in place of internal error) for making a direction
whose opposite does exist, but isn't a direction.

(*) Problem message added for misunderstandings like "When the play begins..."
instead of "When play begins...".

19.6. Properties

(*) Bug fixed whereby Inform confuses a property of an object with a use of a
value phrase containing the word "of" - for example, misreading "room
illustration of the location" as an attempt to use the phrase "room D of R"
(for looking up the map) rather than an attempt to access a property called
"room illustration".

(*) Bug fixed whereby property declarations such as "A room that is dark can be
dangerous." would wrongly be accepted, but would have adjectives or qualifiers
such as "that is dark" ignored. (It's incorrect to make a declaration like
this because the owner of a property has to own it all of the time, no
matter what; it can't have it only when it's dark.)

(*) Bug fixed whereby adjectives declared in the form "...if its P is V" (which
check that a property P has value V) would always be false for text properties;
thus, "Definition: a childhood memory is forgotten if its recollection is ""."
would fail to work.

(*) Bug fixed whereby antonyms of adjectives declared in a way which laid them
out as phrases, like so...

	Definition: A thing (called the item) is handy rather than useless:
		if the item is openable, decide yes;
		decide no.

...would fail to work: "handy" would work perfectly, but not "useless", which
would in some circumstances produce I6 errors.

(*) Bug fixed whereby descriptions implicitly given to kinds are now taken as
being likely but not certain; as a result, the following is now possible,
whereas previously it was reported as a contradiction:

	A folding metal chair is a kind of supporter.
	"The chair looks only moderately uncomfortable."
	The small chair is a folding metal chair in test room.
	"The chair looks painful to sit in."

(*) Problem message added for definitions which try to use "or more" or "or less"
with non-arithmetic values, e.g.,

	Definition: a person is cool if his callsign is "dude" or more.

(*) Problem message added to catch attempts to give properties to a set of owners
which changes during play, e.g.,

	Colour is a kind of value. The colours are red and green.
	A thing has a colour.
	Taste is a kind of value. The tastes are sweet and sour.
	A thing has a taste.
	The taste of a red thing is usually sweet.

(*) Problem message added (in place of internal error) for understanding a
property in the description of something, when the property is one whose
value is an object of a kind outside the usual spatial model (i.e., neither
room, thing, region nor direction).

(*) Problem message added (in place of what was in some circumstances an internal
error) when an either/or property is assigned using "has" instead of "is",
e.g., "The teddy bear has fuzzy."

19.7. Relations

-- -- --

19.8. Actions

(*) Bug fixed whereby variable declarations for actions whose names include the
words "with" or "having" (either not at the end, or not after "it") would
produce spurious problem messages.

(*) Bug fixed whereby an action in which the player asks someone else to do
something, which then fails because the persuasion rules halt the process,
would result in "reason the action failed" not properly being set. (It's now
set to the identity of the persuasion rule which stopped the action.)

(*) Bug fixed whereby Inform would fail to recognise actions involving actors
whose names include words with an "-ing" suffix, and where the longhand
"trying" syntax isn't being used. Thus if somebody's full name is "Regional
Training Officer Tina", Inform was failing to recognise "Tina examining the
clipboard" as an action, simply because of the word "Training" in her full
name. Inform now allows such readings in any case except where the action
verb is itself part of the actor's full name; thus, if there were an action
called "training", Inform wouldn't like "Tina training Kevin", which would
look to Inform like a row of names of people; and the author would have
to rephrase in the longhand form, "Tina trying training Kevin".

(*) Bug fixed whereby actions out of world applying to a topic would have the
topic noun empty, rather than containing the text of the topic as they
should; for instance, in this combination:

	Helping is an action out of world applying to one topic.
	Understand "help [text]" as helping.

the command HELP RICHARD STRAUSS would fail to have the noun set to the
snippet RICHARD STRAUSS of the command, as would happen for an action
in world. This wasn't a deliberate restriction - it was a bug.

(*) Bug fixed whereby out of world actions in one pass of the turn sequence
rules could sometimes cause the next pass of the turn sequence to begin
as if we were still out of world, making it difficult to try in-world
actions before a command had been typed; this caused the following not
to work -

	This is the Luciano's actions rule: try Luciano singing.
	The Luciano's actions rule is listed before the parse command rule
	in the turn sequence rules.

- in the turn after a command like VERSION or VERBOSE.

(*) Bug fixed (or perhaps it's really that Inform's specification has been
clarified) so that a rule like this:

	Every turn jumping for three turns: say "A demon appears!"

does take effect if the player jumps twice, types SAVE, and then jumps a
third time; that is, the saving the game action does not interrupt the
count up to three. (Because saving the game is out-of-world, and so doesn't
take up a turn.) On the other hand, a rule like this is fine:

	Check requesting the pronoun meanings for the first time:
		say "The PRONOUNS command is very useful. To explain: ...";
		continue the action.

since although "requesting the pronoun meanings" happens out-of-world and
can't take place for a number of turns, it does take place for a number
of times.

(*) Bug fixed whereby references to things having happened "for exactly 0 turns"
would fail to work, e.g.:

	if the rose has been visible for exactly 0 turns

(*) Bug fixed whereby "try", when used to cause an out-of-world action by the
player during an existing action by somebody else, could sometimes cause a
consecutive in-world action by that other person to be misconstrued as
being out-of-world. For example:

	Instead of an actor waiting:
		try requesting the pronoun meanings;
		try the actor saying yes.

might result in the "saying yes" action being rejected as out-of-world and
thus unavailable to an actor other than the player.

(*) Bug fixed whereby before, instead or after rules would sometimes be included
on the Index pages for out-of-world actions, despite the fact that they
cannot affect these.

(*) Bug fixed whereby lists of actions would sometimes be misread if entries
were ambiguous as to which action was meant, e.g.,

	Instead of doing something other than waiting or examining or taking
	inventory or looking: ...

was misread as if "taking inventory" were simply "taking".

(*) Problem message added to catch attempts to file rules about out-of-world
actions into the before, instead or after rulebooks (where they can have no
effect under any circumstances, since these aren't consulted for OOW actions).

(*) Problem message added to catch mixtures of in-world and out-of-world actions:

	Instead of requesting the pronoun meanings or taking inventory: ...

(*) Bug fixed whereby a stored action which involved a value would sometimes be
said incorrectly (though in other ways it was okay): for example,

	Factoring is an action applying to one number.
	...
		let the best idea be the action of factoring 15;
		say "You consider [the best idea].";

would say the action as "factoring -23145", or some other mysterious number.

19.9. Activities

(*) Bug fixed whereby global variables could not appear in "... while ..."
clauses to do with activities, so that this for instance would not work:

	For printing the name of the banana while listing contents of the player:
		say "yummy banana".

...whereas the same thing with "yourself" instead of "the player" would work.
They now both do.

19.10. Rules and rulebooks

(*) A minor change which looks like a bug fix, but isn't, strictly speaking:
when a bare adjective is used as a condition attached to an action, as here -

	Instead of doing something when off-stage:
		say "After the thrill of the spotlight, life seems not to exist."

- the adjective is now assumed to apply to the person performing the action.
(In this case that's the player, who can never be off-stage, so that the
message can't be said. But the principle is the important thing.)

(*) Bug fixed whereby compound conditions which included spurious additional
"when" or "while" words could cause Inform to hang, or crash; for example,

	Test Scene begins when the player is in the First Room or when the
	player is in the Second Room.

(It should be just "or the player...", not "or when the player...". Inform
now catches this with a more on-point problem message.)

(*) Bug fixed whereby rules using "going nowhere in R" for some room R, or
"going somewhere in R", would fail to be matched correctly; so that this, for
example, wouldn't work:

	Instead of going nowhere in the Home: say "You'd just get homesick."

(*) For clarity's sake: rules written thus...

	Instead of yourself going: ...

where the actor is explicitly named as "yourself" (or "the player"), now work
as the writer might expect (i.e., as if it just read "Instead of going: ...").
Hard to know whether this is a bug fix or not - arguably it's less consistent
this way, because the convention is that an action is by the player unless
a specific actor is named. But what matters is that the sense should
be right for the reader.

(*) Bug fixed whereby rules depending on something in the past tense being true
over a period which is itself in the past would sometimes not fire. For
example,

	Before doing something when the hat has been worn for three turns: ...

(*) Bug fixed whereby an I7 name given to a rule defined by an I6 routine would
sometimes be confused with the name of a new object, if used as the value
of a property, or in some other assertion sentence contexts.

(*) Problem message added (in place of sometimes mysterious other problem
message(s)) to catch attempts to use "called" to make a name which already
has another meaning and where confusion may occur. For example, an attempt
to write:

	Instead of giving something (called the number): ...

cannot possibly end well, but Inform would previously allow the calling, then
throw problem messages later on when it was used.

19.11. Lists

(*) Bug fixed whereby lists of lists of indexed texts (and similar constructions)
could lose their identities when printed.

(*) Bug fixed whereby accesses of entries from very long lists, when performed
repeatedly, could become unacceptably slow.

(*) Bug fixed whereby sorting a list of objects using "sort L in P order",
where P is a property whose value is an indexed text, would produce
incorrect results.

(*) Bug fixed whereby sorting a list of indexed text initialised from a list
of literal texts would produce incorrect answers. (Actually it was the list
which was incorrect, but in a way which only affected sorting.)

(*) Bug fixed whereby peculiar messages about being unable to cast or copy block
values would sometimes appear when passing a list of K to a phrase which
expects its token to have kind "list of objects", but where K is something
more specific; for example, passing a list of rooms where a list of objects
was expected.

(*) Two bugs fixed whereby Inform would be picky about whether or not the contents
of, say, a constant list of things were valid, in cases where the entries
were not obviously things but would be proved to be by the end of compilation;
this affected initial values of properties and of global variables. For
example, the following threw a spurious problem message in earlier builds:

	The Place is a room. Hall is south of the Place.
	The destination wishlist is a list of rooms that varies.
	The destination wishlist is { the Place, the Hall }.

The problem here was that the Hall wasn't known to be a room at the time when
the constant list was read; this has now been resolved.

19.12. Tables

(*) The maximum number of columns per table has been raised from 20 to 99.
(There are run-time implementation reasons why a maximum has to exist, but
99 ought to be enough.)

(*) Bug fixed whereby table entries containing literal values would sometimes be
confused with names of objects, if they could also be read as part of an
object's name: for example, if an object called False Door existed, then the
table entry "false" might be misread as this object rather than as the
truth state for falsity.

(*) Bug fixed whereby tables used to define things or values could not have
a column which contained stored actions, e.g., like so:

	A task is a kind of value. Some tasks are defined by the Table of
	Unfinished Tasks.

	Table of Unfinished Tasks
	task				relevant action
	boulder-touching	touching the large boulder
	boulder-recovering	taking the large boulder

(*) Bug fixed whereby, on Glulx only and then only sometimes, looking up a
value corresponding to another value would produce spurious "programming
errors" on screen in cases where the column looked at included blank entries.

(*) Bug fixed whereby attempts to use "an X listed in table T", in the context
of a value, would wrongly be allowed even where this doesn't identify which
value is meant.

(*) Bug fixed whereby the "number of rows in T" would produce a more or less
random answer if T were the empty table used as a default value of the
"table name" kind; and this could cause "number of filled rows in T" to
hang, in unlucky cases.

(*) Bug fixed whereby increasing or decreasing a table entry by a given amount
in fact set it to that amount (but only in cases where the entry was looked
up with "corresponding to").

(*) Bug fixed whereby various sorting tricks with tables would fail if the
column sorted on contained indexed text. Inform now requires such tables
to be sorted before being iterated through using "repeat through T in
C order", where C is a column holding indexed text, and issues a helpful
run-time problem message explaining what to do; previously it simply gave
incorrect results.

(*) Bug fixed whereby sorting tables in random order would be slow if they
contained large numbers of blank rows.

(*) Bug fixed whereby sorting a table on a column which contained some blank
entries (other than as part of blank rows) would move these to the top,
rather than to the bottom, of the table.

(*) Problem message added for attempts to look up a value corresponding to a
key in a table when the kind of the column concerned makes that impossible,
e.g., for "the price corresponding to a shopkeeper of 4 in Table 1" where
the shopkeeper column doesn't contain numbers, so that 4 can't possibly be
there.

19.13. Scenes

(*) Bug fixed whereby scene endings predicated on the player's command would
sometimes fail on the initial pre-turn, before anything had been typed, e.g.:

	Act I ends when the player's command includes "bug/bugs".

(*) Problem message added to catch mistakes like this:

	Happiness is a kind of value. Disappointment is a scene.
	Disappointment begins when happiness ends.

19.14. Kinds and typechecking

(*) Bug fixed whereby defining more than 50 new kinds could sometimes cause
Inform 6 errors or other aberrant behaviour, in a not-very-repeatable way.

(*) Bug fixed whereby nested bracketed compound phrases failed to be read
properly. It's often poor prose style to write messy phrases full of brackets
to disambiguate them, but it ought to work, and it seems that this long-standing
bug made Inform a little unpredictable here.

(*) Bug fixed whereby spurious problem messages would sometimes be produced
when matching adjective-qualified descriptions in the tokens for a phrase;
for instance, in matching "analyse X" against

	To analyse (N - even number): ...

...in cases where X is clearly a number, but may or may not be even.

(*) Bug fixed whereby temporary variables made with "let" or "repeat" whose names
clashed with valid descriptions would be disallowed. This doesn't sound
problematic, but actually it was: for example, if you write

	let held item be ...

in an extension, say, you don't want this to work most of the time, but then
to fail when somebody uses the extension with a story including an object
called "item" (because then "held item" is a valid description - it means
the item when in a state of being held).

(*) Bug fixed whereby "some" used as an indefinite article inside a condition
might be confused with "some" as a determiner, e.g., in the "now" here:

	Some tea is in the kitchen.
	When play begins: now the player has some tea.

(*) Bug fixed whereby spurious kind mismatch problems would be produced when
named objects were used as cases, where a particular kind was needed. For
instance,

	To decide if (D - a direction) looks to windward:
		if D is:
			-- northeast:
				decide no;

(*) Bug fixed whereby an attempt to really violate dimensional rules about the
way numerical values combine could, in some circumstances, throw an internal
error; for example, using the Metric Units extension to set up standard SI
units, but then adding "A force times a mass specifies a force.", thus making
mass dimensionless. (Newton's Laws become not just invalid but inexpressible
in such a universe... but that's no reason for Inform to fold up its tent.)

(*) Problem message added (in place of run-time problem) when a variable is
created with kind "list of topics", or other such constructions. (Variables
of kind "topic" are forbidden; it was an oversight that these more complex
variations weren't rejected at compile-time in earlier builds. They were let
through, but didn't work at run-time.)

19.15. Phrases and functional programming

(*) Perhaps this was a bug fix, perhaps a small new feature, but it likely won't
be controversial: local variable names (created by "let", and such) now take
precedence over global names of physical objects even in descriptions of
essentially physical situations. For example, in the fragment

	To sweep (staircase - a supporter):
		let the debris be a random thing that is supported on the staircase;

...Inform now reads "staircase" as the supporter appearing as a token in the
expansion of "sweep", even if there is an object in the world called "the
staircase".

(*) Bug fixed whereby implicit attempts to repeat through a domain which can't
be iterated through would produce incorrect results at run-time. What now
happens is that a run-time problem message is generated. For example,
"let L be the list of texts" can't be done because the possible texts
can't be iterated through. (In general not all descriptions are used for
iteration, which is why this isn't caught with a problem message in the
compiler.)

(*) Bug fixed whereby a small number of obviously true conditions would produce
Inform 6 errors in compilation: for example,

	if 1 is a number, say "Hi."

would fail. (What happens here is that Inform simplifies the proposition
until it becomes universal truth, then compiles that to an empty string of
Inform 6 code; which is correct for doing nothing, but not for testing nothing,
since it isn't a valid I6 condition. It now tests universal truth as "if (true)".)

(*) Bug fixed whereby spurious problem messages, apparently though not actually
the result of memory being corrupted, would sometimes appear if there were
large numbers of very memory-costly definitions such as this one:

	To dribble/drabble an/-- image-map in (WIN - a number) at (X1 - a
		number) by/x (Y1 - a number) using (WDT - a number) wide data
		of/from/-- from (IMG_MAP - a list of figure names) with tile-width
		(W - a number) by/x tile-height (H - a number) pixel/pixels/px/--:
		do nothing.

(It's quite expensive on memory to write definitions like this: it has nearly
200 possible wordings.)

(*) Bug fixed whereby using "whether or not..." in a "now" would sometimes
cause a spurious internal error: e.g., setting a truth state variable "T" with

	now T is whether or not location is Stage.

(*) Bug fixed whereby the "Runtime problems" pages displayed in the user interface
have title numbers which are out by one. Thus the explanation page for
"P17 - Can't divide by zero" was headed "P18 - Can't divide by zero"; which
was needlessly confusing, though it did no harm otherwise.

(*) Bug fixed whereby definitions of phrases given as inline I6 code would not
properly cast word values to pointer values where necessary. For example...

	To announce (event - indexed text):
		(- print "I declare ", (INDEXED_TEXT_TY_Say) {event}, ".^"; -).
	When play begins, announce "Saturnalia".

...would not work because "Saturnalia" would be expanded into {event} as
text rather than indexed text. This looks like an obscure bug, but in fact
caused some phrase definitions in the Standard Rules to go wrong, e.g.,

	let L be a list of indexed text;
	let L be {"oranges", "apples", "bananas"};
	add "pears" to L;

would create L having three indexed texts and then one unindexed one, because
the inline definition of "add ... to ..." was failing.

(*) Problem message added (in place of internal error) when a declaration
contains only variables, e.g., "To (N - a number): ...".

(*) Problem message added (in place of internal error) for a malformed inline
Inform 6 phrase definition with redundant text after the "-)" marker.

(*) The (+ ... +) syntax for embedding I7 source text within I6 code was previously
not allowed in I6 inline definitions of phrases, which was an odd anomaly,
because it was allowed in other I6 inclusions. It's allowed now.

(*) Bug fixed whereby the literal Inform 6-to-7 escape "(+ V +)", where V is a
value stored on the heap, produced an attempt to block-copy an independent
instance of V, rather than producing a pointer to the existing instance;
this, in particular, making it difficult to use the notation for global
variables holding indexed text, and the like.

(*) Bug fixed whereby the literal Inform 6-to-7 escape "(+ A +)", where A is an
adjective, would produce I6 code which failed to compile, rather than the
name of the routine to test the adjective. Since Inform 6 is typeless,
there's no good way to choose which sense of the adjective is meant, if
several exist for different kinds of value (as for instance with the
adjective "empty"). The convention is: the meaning for objects, if there
is one; and otherwise the first-declared meaning.

19.16. Equations, units and arithmetic

(*) Bug fixed whereby printing units scaled by factors which aren't powers of 10
tended to produce somewhat wildly approximate results - for example, that
printing the value "90 min" in the unit "hours" would produce "1.36 hr".
Integer arithmetic makes this necessarily only an approximation, but the
new algorithm is better; for example, 90 seconds is rendered as 0.0010418
days, the true figure being 0.0010416666...

(*) Bug fixed whereby numerical parts of literals which were both optional and
had optional preamble would sometimes match if the preamble was there but
the number wasn't, and would sometimes not respect the optionality: for example,

	A die roll is a kind of value. 3d20+9 specifies a die roll with
	parts dice, sides (without leading zeros), adds (without leading zeros,
	optional, preamble optional).

...would allow "2D6+2" and "2D6+" but not "2D6" in typed commands; it now
allows "2D6+2" and "2D6" but not "2D6+".

(*) Bug fixed whereby units given in singular and plural forms would sometimes
have only the singular form used in saying, e.g.,

	An age is a kind of value. 1 year old (singular) or 2 years old (plural)
	specifies an age. Every person has an age. Suzie is a woman. Suzie is
	8 years old.

would result in "[the age of Suzie]" being "8 year old", not "8 years old".

(*) Problem message added (in place of internal error) when attempting to solve
an equation which is given as the result of some further calculation, rather
than being explicitly named.

19.17. Understanding

(*) Bug fixed whereby commands using numbers spelled out in digits as noun
phrase determiners wouldn't always work: e.g., TAKE FIFTEEN PLANTS would
be recognised, but not TAKE 15 PLANTS.

(*) Bug fixed whereby the Understand token "[any ...]" would ignore any
constraint made about visibility in the "..." part; for example, "[any
person who is not visible]" would be read as "[any person]".

(*) Bug fixed whereby the pronoun IT would sometimes wrongly be set during
play to the identity of a backdrop item which, though present, was not
explicitly mentioned; for instance, IT might be set to the sun in some
outdoor room.

(*) Bug fixed whereby understanding units which contained mixed case lettering
in their notations didn't always work on the Z-machine; for instance,

	100kHz specifies a frequency.

would lead to commands like "tune to 79kHz" not being recognised.

(*) Bug fixed whereby an empty player's command (resulting from the player simply
pressing enter instead of typing), which then produces an empty snippet, would
result in run-time problem messages if this were matched against. That made
it difficult to write rules like:

	Rule for printing a parser error when the player's command includes
	"please": ...

(*) Problem message added (in place of internal error) when a circularity is
asked for by using "[something related by equality]", e.g.:

	Understand "[something related by equality]" as a person.

19.18. Glulx issues, file I/O, figures, sounds

(*) Bug fixed whereby handling of external files with the Glulx setting would
tend not to work after a game had been saved and then restored. (Particular
thanks to Erik Temple and Andrew Plotkin for helping with this.)

(*) Formatting improved on the Problems page for the case of running out of
readable memory in the Z-machine. In 5Z71 the message for this was, due to
a text editor accident, full of words run together without spaces; which
"creates the alarming impression of a nervous breakdown" (Eric Eve).

19.19. Spacing and printing

(*) Bug fixed whereby a serial comma would wrongly be used when saying a list
which contained exactly two items, if the "Use the serial comma." option
is in force - thus "Starsky, and Hutch".

(*) Bug fixed whereby printing numbers in excess of 1,000,000 "in words" would
describe them in thousands; Inform now uses the words "million" and "billion"
as necessary. (This only affects Glulx games, since the Z-machine can't hold
numbers that high.)

19.20. Indexing

(*) Bug fixed whereby links to extension documentation inside the application
would be broken if the extension's name or author included an apostrophe
(as in the case of "Poor Man's Mistype by Aaron Reed").

(*) Bug fixed whereby rules such as "Instead of doing something other than
singing..." would appear in the Actions Index as if they affected singing but
not other actions, the exact reverse of the truth.

(*) Bug fixed whereby certain built-in adjectives would have their indexed
Phrasebook definitions truncated by one word, though surprisingly often they
still made sense that way.

(*) Bug fixed whereby tool-tips displayed when the mouse arrow hovers above a
map connection in the World index would show garbled names of rooms or
directions when these included accented characters.

19.21. Testing commands

(*) Bug fixed whereby the "Use predictable randomisation." option caused I6
errors in build 5Z71; it works again now.

(*) The trace file has been abolished; in trace mode, Inform copies the same
information to the debugging log instead. (Only affects Inform maintainers.)

19.22. Releasing, bibliographic data, and cBlorb

(*) Bug fixed whereby, similarly, pasted code from extension documentation
examples would come out with accented characters garbled in the paste process.
Sorry about this: it was particularly bad for examples like "Cursillo Mini
Juego", supplied with the documentation for Sebastian Arg's Spanish extension.

(*) Bug fixed whereby releasing with a website would sometimes produce web pages
with the wrong character encoding; typically with UTF-8 for the source text,
but with ISO Latin-1 headings.

(*) Bug fixed whereby releasing with template websites was not working unless
the template was placed inside the application, which users should never
have to do.

(*) Problem message added (in place of Inform 6 errors) to catch attempts to
change the bibliographic data for a story during play. A shame, this; it
would be coolly interactive to be able to change the story's title and
author halfway through, but it would make the Library Card, the IFDB entry,
and so on, wrong.

(*) Problem message added (in place of internal error) when the title, author,
or other bibliographic data for a project contains a text substitution -
again, these have to be fixed text.

(*) Problem message added for attempts to release along with an existing story
file when in Glulx mode: Inform supports this for Z-machine story files, but
not Glulx, at present. (There are so few Glulx story files not generated by
I7 that it's never seemed worth it, but get in touch if you do need this.)

20. EXAMPLES

"Entrevaux" added to demonstrate a system of scenes where each scene has a
	list of props, a location, and some starting text, and scenes are set up
	and struck automatically.
"Wainwright Acts" added to demonstrate a quirk of using doors with NPCs.
"Number Study" added to demonstrate conditional relations between numbers.
"For Demonstration Purposes" added to show the use of relations applying to
	stored action names.
"The Undertomb 2" added to demonstrate properties of values.
"Finality" added to demonstrate how to strip out the offer of UNDO.
"Pot of Petunias" added to demonstrate "set pronouns from..." and point to
	the more abstruse methods available in Plurality, if the author needs them.
"Unblinking" added to demonstrate the use of best route through...
	described rooms, and to explain a tricky point about determining light
	levels in a room.
"Lethal Concentration 2" edited to produce more attractive grids.
"Bic" modified to reflect the new behavior of description properties.
"Kiwi" revised to be more accurate about when it prints its parser error.
"Waterworld" extended to show how to add new accessibility rules. (The old
	version of this example was simple but not the most trustworthy
	implementation.)
"Stately Gardens" revised to handle "look towards [something]" better, and
	to print a response to looking towards a room that contains nothing notable.
"Paddington", "Sushi" and "Crusoe" slightly rewritten to account for changes
	to the carry out examining rulebook (see above).
"Ferragamo Again": removed bug whereby it was possible to get "You sighs
	heavily." as output.
"Bowler Hats and Baby Geese": removed bug that caused the eggs still to be
	visible after they were made into the omelet.
"Pine 4": removed bug that made the brothers invisible because they were
	not starting in the Woodcutter's Shack.
"Strictly Ballroom": removed bug that made it possible for one of the other
	characters to dance with "yourself".
"Entrapment": made a very slight tweak to syntax to clarify what is
	happening at one point for the reader.
"Tilt 3": removed a comment that pasted incorrectly into the main window,
	causing compilation to fail when compiling for Glulx.
"The Cow Exonerated": removed a bug such that the game text always assumed
	you'd been burning multiple matches.
"Further Reasons All Poets Are Liars": added tweaks to prevent moving the
	box while standing on the bed, and to give a more sensible response to PUSH
	BOX alone (formerly this gave "It is fixed in place.", which was clearly
	wrong).
"Hayes Code": revised to add an indefinite article ("a thong", "a
	pin-striped suit") rather than the inexplicably bare version given before.
	Also, it should have been "Hays Code" all along. Oops.
"Under Contract": revised to include a test for the situation in which the
	player tries giving her dress to Clark. This actually tests an improvement
	to the Standard Rules.
"The Cactus Will Outlive Us All": tweaked to replace the somewhat
	disappointing message "Nothing obvious happens" after we pull the cactus to
	kill Luckless Luke.
"AARP-Gnosis": bug fixed whereby taking all but one of the volumes from the
	encyclopedia would produce a delay of one turn before proper collection
	descriptions kicked in.
"Cloves": modified to automatically list the adverbs that the game knows
	rather than hard-coding the list, now that this is possible.
"Bumping Into Walls" very slightly revised because the previous phrasing
	would create output like "From here, the only way out is to the down"
	if vertical directions were included.
"Whence?" and "Whither?" simplified considerably thanks to the use of
	built-in phrases about door directions.
"Boston Cream", "Text Foosball", "Patient Zero", "Nickel and Dimed", "Four
	Stars" tweaked to include the "end the story finally saying..." phrase to
	mark successful endings apart from unsuccessful ones.
"Patient Zero" edited to excise an unused phrase definition.
"The Facts Were These" edited to deal more gracefully with the problem of
	giving items that are on the ground, if no other items not on the ground match.
"Cave-Troll", "Kiwi", and "WXPQ" edited to handle new treatment of parser errors.

Recipe Book:

Modifications to "Ending the Game" (now called "Ending the Story") to
reflect new syntax and to explain the Table of Final Question Options more
fully.

21. BUILT-IN EXTENSIONS

The definition of kHz in "Metric Units" was wrong: it thought 1 kHz was a
	thousandth of a Hz, not a thousand Hz.
"Locksmith" advanced to version 9:
	Additional rules so that the player can learn the function of a passkey
		by using it to lock or observing it being used to lock. (Formerly only
		unlocking identified the passkey.)
	Name given to one rule for which a name had been omitted. (Sorry about that.)
Tweak to "Basic Screen Effects" to get rid of a bug to do with the styles of
	status text in Glulx when an extended status bar was employed (thanks to
	Erik Temple for the patch). Version advanced to 6.
"Plurality" advanced to version 8:
	A couple of minor bugs expunged.
	Extension documentation improved to show how to check the plural status of
	objects.
	Adjusted to use the phrase "set pronouns from...".
	Deprecates phrases using "Cap ...", as in "Cap it-they", instead allowing
	the author to capitalize normally for the same effect ("It-they").
	Adds a contracted 's-'re form in addition to is-are, and extends the example
	in the documentation.
"Glulx Text Effects": minor changes to the documentation to clear up some
	confusion in the discussion of colors as rendered in hex; and revised to
	allow the user to modify the built-in styles. Version number advanced to 4.
"Glulx Entry Points" given a new example and better explanation of what the
	gestalt checks about multimedia ability will actually do. Version number
	increased to 8.

22. A NOTE ABOUT FIGURE AND SOUND NAMES

Figure names and sound names are the standard Inform kinds for representing
pictures and sound effects. In this build they gain in functionality (they
can have properties now, can be repeated through, and so on), but to achieve
this we needed to change their data representation at the Inform 6 level.

This only affects I6 code included into I7 source text, but the practical
side-effects run wider, because many people use Glulx extensions for doing
ingenious things with (especially) images; and those extensions tend to rely
on the old representation.

This means they will need to be updated in order to work with this new build
of Inform.

Previously, a figure name and a sound name were each represented in I6 by
the resource ID number of the picture or sound resource inside the blorbed
story file. These would usually be small numbers, and would be different from
each other (i.e. no picture would have the same ID number as a sound).

From this build, figure name and sound name are enumerated kinds, meaning
that they are each independently stored as the I6 level as 1, 2, 3, ... in
order of creation. These are typically off by one, or some other small amount,
from resource ID numbers, but don't rely on that. To convert to a resource
ID number, indirect through the word arrays:

	ResourceIDsOfFigures-->N
	ResourceIDsOfSounds-->N

In other words, whereas in an I6 inclusion

	(+ figure of Space Shuttle +)

would previously have produced the resource ID number as an I6 value, you
now need to say

	ResourceIDsOfFigures-->((+ figure of Space Shuttle +))

and similarly for sounds. We apologise for the inconvenience of changing
this, but from the long-term point of view, it's the right thing to do.

23. A NOTE ABOUT EXTERNAL FILES

Prior to March of 2010, the Glk reference materials and interpreters
incorrectly specified the underlying code for appending text to
external files. This means that, on most interpreters, external file
handling did not work correctly. The major interpreters, including
WinGlulxe, WinGit, and Gargoyle, were patched in mid-March. (Zoom was
not affected.) Authors should be aware of this when testing and
recommending or packaging interpreters for games that utilize external
files.

§11.2. What was new in build 5Z71 (April 2009)

As this release was being prepared, the Indian Ocean island of Mayotte voted to rejoin France, which in turn rejoined NATO; Sweden, Vermont and Iowa legalised gay marriage; Fermilab discovered the Y(4140) particle, composed (some said) of charm and anticharm; the Proctor and Gamble soap opera "Guiding Light" was cancelled after 72 years of family struggles, uplifting sermons, and the legendary Reva, twice believed dead but in fact an amnesiac taken in by the Amish who returned to find her husband living with a clone of her called Dolly, who in remorse took her own life with aging serum, leaving Reva free to become a San Cristobelian Queen and travel in time, and... so on; Oxford, with its heaviest rowing crew in centuries, won the annual Boat Race against Cambridge; and Barack Obama's first hundred days coincided with a hundred days of hair-tearing by the makers of the new Inform website.

In the world of Inform, miscellaneous benefits came out of a substantial internal reform in logic and the handling of kinds of value. Many of those lifted niggling restrictions - see the full change log for details. Build 5Z71 uses around a third as much memory as 5U92, does much less file-handling, is a little faster, and can handle projects unlimited in size. Dimensional checking became much more flexible, allowing Inform authors to model the world with quantitative physics, and a new built-in extension, "Metric Units by Graham Nelson", defines all the kinds of value needed. Equations, imitating those in books and papers, were added to the language. The release mechanism was also rewritten, allowing much better CSS-friendly websites to be produced by the Release button. The Recipe Book was expanded and rewritten in its coverage of actions and commands. Lastly but most visibly, the Index was redesigned and the Problem messages relaid to incorporate links to relevant documentation. All 132 issues arising from bug reports since build 5U92 were closed out.

5Z71 (18 April 2009)

INFORM FOR OS X

A new option on the Advanced panel of the Preferences allows the user to
	choose between Git and Glulxe as the interpreter used in the Game panel
	to play back Glulx-format projects.
A new option on the Format menu, "Enable elastic tabs", causes Tables in the
	Source to be shown with elastic-width tabbed columns, which are the
	right width for their content. (Typing a single tab is enough to mark
	the end of the contents of a table entry; it's as if the tab is made
	of something elastic, because it stretches as needed.)
Various minor bugs have been removed.

INFORM FOR WINDOWS

The spell check dialog now lets the user choose the dictionary language, and
	whether or not all text is checked, or just the text in quotes.
Spell check dictionaries for different languages can be installed by copying
	the ".aff" and ".dic" files into the "Dictionaries" sub-directory of
	the Inform 7 installation. Dictionaries can be downloaded from the
	OpenOffice project at
		http://wiki.services.openoffice.org/wiki/Dictionaries
In the Source tab's Replace dialog, selecting "Replace All" will also replace
	the currently selected word, if it matches.
The interpreter in the Game tab can now play MOD music files.
Sounds playing in a game in the Game tab are stopped when the game stops.
Interpreter command files (containing a list of commands entered by the user
	into a game, as recorded by a game interpreter such as Frotz) can be
	imported into the skein with the File menu item "Import into Skein".
There is now a choice of Glulx interpreters for the Game tab: either Glulxe
	or Git. If there are any problems with games under Git that do not
	show up under Glulxe, we would be interested to hear of it.
The directory that Inform uses to store extensions, documentation, etc, which
	defaults to the user's "My Documents" folder, can be changed by
	creating a text file "home.txt" in the same directory as the Inform
	executable, containing the path to the required home directory.
More options added to the preferences dialog.
Alt-cursor left and right are now mapped onto the tab's back and forward
	actions, rather than the web browser's history.

INFORM FOR GNOME ON LINUX

Colour now works in the Game tab.
The Game tab now has a choice of two Glulx interpreters: in addition to
	the traditional Glulxe, which has been brought up to date with version 0.4.4,
	one can now test one's Glulx projects in Git 1.2.2.
"Elastic tabstops" have been added as an optional way to display the source
 	text - this makes table columns the right width regardless of where tab
 	positions lie. This feature can be enabled in the Preferences window.

INDEX

The most visible change in this build is that the Index for a project now
has a new look, and has been reworked throughout. We now have much more
experience of working with large projects, and have more feedback from users
about what they found helpful and not in the old Index.

In general, we have tried to improve navigation within the Index pages - each
of which contains several different tables or charts - to pack more information
into the existing tables, where sensibly possible, and to improve its visual
recognisability - to make it easier to see at a glance where you are. Being
lost in the Index is no better than being lost in the source text, the whole
problem it's supposed to address.

There are too many changes to itemise, but briefly:

	links to extensions from the Index pages now have a new icon (in place of
		the old footnotes like [E1]); clicking them jumps to the documentation
		for the extension;
	a new use option, "Use numbered rules", indexes rules with identifying
		numbers alongside their names, and causes the testing command RULES ALL
		to show these numbers at run-time - which may help in debugging when
		"Use memory economy" is enforced, so that RULES ALL is unable to quote
		rule names in full.

CBLORB

This build includes version 1.1 of "cblorb", and matching improvements to
Inform's system for releasing projects. "cblorb" is an internal tool which is
run at the end of the translation process, but only when the Release button
rather than the Go or Replay buttons was clicked. It has two main jobs: to
bind up the translated project, together with any pictures, sounds, or cover
art, into a single file called a "blorb" which can be given to players on
other machines to play; and to produce associated websites, solution files
and so on as demanded by "Release..." instruction(s) in the source text.

Previous builds of Inform included a minimal implementation of "cblorb"
which, although it mostly worked, was really only a prototype: it was not
really flexible or reliable enough to be used in the final system. We have
long intended to replace it with a better implementation, and version 1.1
is our first draft of that. It is much faster (running in order N time,
where N is the line count of the source text, not order N-cubed), and
produces much better HTML. This also gave us the opportunity to reform
how "Release" works, and to make it easier to produce tidy collections of
release material.

Almost all of the size or complexity limits have been taken out, and in
particular:

	the number of audiovisual files embedded in the blorb, previously limited
		to about 495 (depending on circumstances), is now limited only by the
		Blorb specification limit of 32765;
	the number of auxiliary files, previously at most 50, is now unlimited;
	the numbers of tables and headings in a project released with source in a
		website, previously 250 each, are now unlimited;
	the number of knots in the Skein of a project released with a solution,
		previously at most 10000, is now unlimited;
	the story description length, previously at most 1000 characters, is now
		at most 2047 characters;
	and all filenames can be up to 2047 characters long, which should help
		if the project is very, very deep in the file system tree.

Various minor bugs have been removed, of which the most important was a
tendency to trim 8 bytes from the end of some audio files when embedding
them, which caused some Ogg Vorbis files to be unplayable. The rendering of
source text on an accompanying website is also improved somewhat, with
various bugs to do with nested comments removed, and support for verbatim
I6 code added; text substitutions are also now styled, and hanging
indentation for code makes it much easier to read. Particular thanks to
David Kinder, who diagnosed the Ogg Vorbis fault, and to Stephen Granade,
whose "i7htmltidy.pl" script was a most effective critique of the original
"cblorb".

Internal changes include:

	there are several new placeholders:
		[PAGENUMBER] and [PAGEEXTENT], for pages in the multi-page source
		web pages, are such that "page [PAGENUMBER] of [PAGEEXTENT]" produces
		text such as "page 2 of 7";
		[TEMPLATE] is the name of the web template in current use;
		[SMALLCOVER] is the filename of the thumbnail-sized version of the
		cover art file. (Compare [BIGCOVER], which already exists, and is the
		filename of the real thing.)
		[STORYFILE] becomes the "leafname" of the story file, e.g., "Bronze.gblorb"
		[GENERATOR] becomes the name of the program generating the website, e.g.,
			"cblorb 1.2"
		[TIMESTAMP] and [DATESTAMP] are the time and date at which cblorb runs
	new command-line arguments "-trace", "-help";
	the user interface is now expected to call with the first option
		being "-osx", "-windows", or "-unix" as appropriate;
	a new "style" command in Blurb locates the relevant CSS file to
		use when releasing with a website;
	"<img ...>" tags generated by "cblorb" are now self-closing ("<img ... />");
	"<br>" tags generated by "cblorb" are now self-closing ("<br/>");
	footnote anchors are now closed, preventing link style from spilling;
	paragraphs generated by "cblorb" are now always in matching
		"<p>...</p>" tags;
	links in the lists of links are now in "<li>...</li>" list item tags in
		a surrounding "<ul>...</ul>", and similarly for the contents listing
		in a source website, where nested <ul>s are now used to show the
		headings hierarchy;
	"halign" and "valign" markers are not used in tables if a CSS file is
		present to handle table styling better;
	auxiliary file sizes displayed better, and file size displayed for the
		Blorb itself;
	cblorb no longer generates temporary files in the project's Build
		directory, so it no longer leaves debris behind for the user interface
		to tidy up.

RELEASING

There are six corresponding changes in Inform itself.

(1) "Release along with..." has a new option - "library card", which is
the iFiction record for the project, an XML file conforming to the Treaty
of Babel for bibliographic data.

(2) In "Release along with..." sentences, the adjectives "private" and
"public" can be used when we release along with any of:
	source text, solution, library card
"Public" means that if we release along with a website then the item in
question will appear in the links from the home page; "private" means it
will be produced but not be mentioned or linked on the website. If neither
one is specified, source text is public but everything else is private,
which conforms to Inform's traditional practice. If we aren't releasing
along with a website, public vs. private makes no difference.

(3) Suppose Release is clicked in the Inform user interface, and everything
works without problem messages. If there are no "Release along with..."
sentences in the source text, then the release consists only of a single
blorb file. The user interface displays a Save As... dialogue box asking the
user where to put this file. But if there are "Release along with..."
sentences, then Inform needs to release multiple files, and it puts those
in the "Materials" folder for the project. (If the project is, say,
"Apricot.inform" then this would be a folder called "Apricot Materials" in
the same place.)

All of that is how Inform has always worked. What's new is that the released
material is now all put in a subfolder of "Apricot Materials" called "Release".
Anything in "Release" can be thrown away at any time, as it can all be
replaced; equally, to upload a website to a server, we only need to copy the
contents of the "Release" folder. This is much tidier than the old
arrangement, in which released files mingled with other working documents in
the root of "Apricot Materials", so that it wasn't easy to see at a glance
what was part of the released website and what wasn't.

Inform automatically generates the Materials folder and its Release subfolder
as necessary if they don't already exist.

(4) Inform has always generated websites using what it calls "templates",
and it has always been supplied with a single built-in template called
"Standard". This continues to be true, but the new "Standard" is a more
modern design, making use of CSS. (The old look is preserved as "Classic",
also built-in, in case anyone really wants to keep using it, or needs to
generate a website which makes no use of CSS.)

The form of templates has however changed. A template was previously a pair
of HTML files - for instance, "Platinum.html" and "Platinum-Source.html" -
containing placeholder text like "[AUTHOR]" where the author's name should
appear, and so on. A template is now a folder - "Platinum", say - which can
contain any of the following four files:

	index.html - the template for the home page
	source.html - the template for source text pages
		(used only when "Release along with a website" is used)
	style.css - the CSS styles needed by the HTML files
	(extras).txt - a catalogue of any other files to be added

If any of these is missing, Inform uses the one in "Standard" instead.
In practice, this means the easiest way to create a new template is to
supply just a new CSS file, which can change the colour, font, type size,
and position of more or less everything in the site.

The optional "(extras).txt" file - note brackets - is a text file which
contains a list of named extras to throw in. For instance:

	easter.html
	egg.png

These named files need to be present in the template folder. Files with the
extension ".html" go through the placeholder expansion process just like the
index and source pages; all other files are copied verbatim. (Extras allow
for images, movies, etc., to be added to the template.)

See 22.12 and 22.13 in the documentation, which have been rewritten.

(5) Inform knows templates only by their titles ("Standard", say, or
"Platinum"). When it needs to find one, it searches the following places
in sequence:

	(a) the "Templates" subfolder of the project's Materials folder, if this
		subfolder should exist;
	(b) the "Templates" folder in the user's own library - on Mac OS X, this is:
			~/Library/Inform/Templates
		and on Windows:
			My Documents\Inform\Templates
	(c) the built-in stock of templates, currently "Standard" and "Classic".

(6) A file released without cover art now has a generic cover image applied.
Most people releasing Inform 7 works do now include cover art, and we would
like future interpreters and website designs to be able to assume that an
image of some kind can be associated with any I7-produced blorb.

INDEX AND PROBLEMS

It would not be useful to itemise the changes here, but the design of the
Index pages has been heavily revised. The aim is to present more information,
but more clearly, and with better navigation and labelling. We'd suggest
that anyone used to the old Index might find it worthwhile to explore the
new one.

A process of trying to improve the quality of problem messages is under way,
though it's certainly not complete. Here the aim has been to be clearer and
more direct, with hints typographically separated from their messages to
reduce the tendency of long paragraphs to resist the tired eye. Most problem
messages are now accompanied by blue documentation-link icons to relevant
passages of the manual.

KINDS OF VALUE

Activity names can now be stored in variables.
In previous builds, indexed texts, stored actions and lists could not be
	properties of values - though they could be properties of objects. This
	anomaly is removed.
Inform now makes more apparent that it allows arithmetic on some kinds of
	value (numbers, times, etc.) but not others (text, scenes, etc.). The
	new Kinds index page should clarify which.
The rounding-off notation "V to the nearest D" now works for any numerical
	value V, not just for times, as in previous builds. Thus, for instance:
		the pressurised volume to the nearest 100 cu m
		the score to the nearest 25
Two new operations also act on any numerical value:
		cube root of V
		square root of V
	The results will necessarily be approximate. Square roots of negative
	numbers throw a run-time problem.
It's now legal to declare multiplication rules for any numerical kinds of
	value, provided this is done consistently. E.g.:

		Bus Stop is a room.
		Frequency is a kind of value. 40/min specifies a frequency.
		Bus frequency is a frequency that varies. Bus frequency is 2/min.
		A frequency times a time specifies a number.
			When play begins:
			say "You can expect [bus frequency times 10 minutes] buses to turn
				up in the next ten minutes."

	This would previously have been rejected as involving the built-in KOVs
	"time" and "number", which Inform was rather over-protective towards.

SCIENTIFIC UNITS AND SCALED ARITHMETIC

Inform now allows a spread of alternative notations for units:

	A weight is a kind of value. 10kg specifies a weight. 1 tonne specifies a
	weight scaled up by 1000. 1g specifies a weight scaled down by 1000.

This enables notations such as "0.45kg" to be used, and causes weights to be
stored to an accuracy of 1g. These scale factors are kept consistent in all
arithmetic, and in particular when different units are multiplied together
or divided.

There can be equivalents on a different scale altogether:

	1 ounce specifies a weight equivalent to 0.028kg.
	1 pound specifies a weight equivalent to 16 ounce.

We can also mark some notations as singular or plural, and give them names:

	1 tonne (singular, in tonnes) or 2 tonnes (plural, in tonnes) specifies a
	weight scaled up by 1000.

That enables us to say "[weight of the tank in tonnes]", for instance.

A new built-in extension, "Metric Units by Graham Nelson", makes definitions
of kinds of value for most of the scientific quantities needed to make models
of the real world:

	length, mass, elapsed time, electric current, temperature, luminosity,
	angle, frequency, force, energy, pressure, power, electric charge, voltage,
	luminance, area, volume, velocity, acceleration, momentum, density, heat
	capacity, specific heat capacity

The extension defines SI standard notations for all of these, allowing both
European and American spellings, and gives them the proper dimensional rules
for multiplication (for instance, length times length is an area). "Elapsed
time" is much more precise than the built-in "time" kind of value - it measures
from 1 centisecond up to about 35 weeks, rather than being a count of minutes
in the course of a single day. Use of "Metric Units" requires the Glulx story
file format rather than the Z-machine, simply in order to hold large enough
numbers to make sensible scientific calculations.

EQUATIONS

As trailed, somewhat speculatively, in the January 2007 discussion document,
Inform now supports displayed equations. Inform imitates the conventions of
printed scientific books and papers, just as it does with tables of data.
For example:

	Equation - Newton's Second Law
		F=ma
	where F is a force, m is a mass, a is an acceleration.

	Equation - Principle of Conservation of Energy
			mgh = mv^2/2
	where m is a mass, h is a length, v is a velocity, and g is the
	acceleration due to gravity.

(These equations are dimensionally checked for correctness.) Inform can then
solve them to calculate whatever unknown is missing. For instance,

	let v be given by the Principle of Conservation of Energy, where h = 10m;

is sufficient to determine "v" provided that the quantities other than "v" and
"h" are known.

In cases where we simply want a quick way to write an elaborate one-off
formula, we don't need to declare an equation - we can just write it in directly:

	let f be given by V = fL;

LOGIC

It is now legal to use "now" in a way involving more than one varying quantity
	at a time. For example:

		Trail Shelter is a room. Fred and George are men in Trail Shelter. The
		possum, the skunk and the weasel are animals. Dixville Notch is north
		of the Shelter. Earl is a man in Dixville Notch.

		Suspecting relates various people to various people.
		The verb to suspect (he suspects, they suspect, he suspected, it is
		suspected, he is suspecting) implies the suspecting relation.

		Earl suspects the possum.

		Instead of waiting:
			say "A sinister odour begins to make itself felt.";
			now every person in Trail Shelter suspects every animal which is not
				suspected by Earl.

		Test me with "relations / z / relations".

	Previous builds would have rejected this use of "now" as too complex.

It's now legal to test if something is "everywhere"; this will only be true
	for backdrops which are indeed everywhere.

The Standard Rules now define:

		The verb to provide (he provides, they provide, he provided, it is provided,
		he is providing) implies the provision relation.

	This in general is a relation. The following are equivalent:

		if carrying capacity is provided by the player
		if the player provides carrying capacity

	For clarity, "the property ..." can be used, and this is compulsory for
	either/or properties, since those are otherwise adjectives not nouns:

		if the player provides the property male
		if the player provides the property carrying capacity

	This makes "to provide" a full verb, whereas previously it was only imitated
		by a definition of "X provides the property P" in the Standard Rules.

It's now legal to assert value relations in relative clauses, e.g.:

	Laboratory is a room. Peter is in the laboratory.
	Colour is a kind of value. Aquamarine is a colour.
	Annoying relates various colours to various people. The verb to annoy (he
	annoys, they annoy, it is annoyed, he is annoying) implies the annoying
	relation.
	Aquamarine is a colour which annoys Peter.

MINOR NEW FEATURES

A new use option allows the parser to handle large numbers of objects better.
For instance,

	Use maximum things understood at once of 200.

enables the parser to handle commands like TAKE ALL to work well in situations
where up to 200 items are within view at once. (This number was always 64 in
previous builds, and the default level has been raised to 100.)

Inform has for some time had the phrase

	the room north from the Ballroom

to look up map connections; it now recognises "north of the Ballroom" as being
synonymous. This reports the room which somebody would get to if they could
go, in an unimpeded way, north from the Ballroom - perhaps through a door.
The result is always a room, or nothing. In similar vein, the new phrase:

	the door D from/of R

produces the door which lies in direction D from room R, or else nothing if
there's no door there.

It's now legal to set values that vary "usually". For instance:

	The speed limit is a speed that varies. The speed limit is usually 100 mph.

This should help extension writers who are nervous of setting values which
their users might want to alter.

Inform usually allows "while" as synonymous with "when", but until now an
exception has been that it insists on "Understand... when..." rather than
"Understand... while...". Both wordings are now allowed.

Build 5U92 was rather strict about not allowing colons in text substitutions.
Usually that's a good thing, as it catches various accidents, and in general
text substitutions shouldn't contain punctuation. But that overlooked times
of day written with colons, as here:
	"The stage is [if the time of day is after 8:00 PM]filled[else]empty[end if]."
So colons have been allowed again if used in explicit times of day.

New rules have been added to the Standard Rules:

	standard report preferring abbreviated room descriptions rule
	standard report preferring sometimes abbreviated room descriptions rule
	standard report preferring unabbreviated room descriptions rule
	standard report switching score notification on rule
	standard report switching score notification off rule

so that these out of world actions are reported by the report rules, which
can then be modified or pre-empted, just as the corresponding rules can for
ordinary actions.

In previous builds, and in keeping with ancient Infocom customs, "leave" was
synonymous with "go" when typed as a command. On balance, though, this leads
to confusion - especially since "go" often has the sense of "enter", exactly
reversing the meaning of "leave". "Leave" is now synonymous with "exit".

Perhaps this is really a bug fix: the phrase option "if absent" for the phrase
"add V at entry N in L" (for adding a value to a list in a given position) was
claimed to work in the documentation for previous builds, but in fact it has
only just been implemented in this build. (Previous builds did allow "if absent"
in the case where V is a list, but not where it is a single entry; and in the
case where no entry position is specified.)

PERFORMANCE

The Inform 7 compiler is now more economical on memory usage. Previously
it consumed around 43MB on a small run, and 78MB on "Bronze", a typically-sized
complete work; those figures are now 9MB and 25MB respectively. (This may
make Inform more viable on low-memory netbooks.)

Inform's use of temporary files is more or less abolished in this build;
thus a typical problem-free run on a large source text now involves around
100 file writes, almost all index pages, where previous builds might make
around 1400 file writes. (This may speed Inform up on slow media such as
memory sticks.) Internally, Inform now makes use of flexible-sized memory
buffers instead, and as a side-effect it should be much harder for
maliciously-constructed source text to crash Inform by means of buffer
overruns - though nobody at present is trying this, so far as we know.

The upper limit of 500,000 words of source text has been removed; there is
now no upper limit. This once seemed unthinkably large, but the recent
release of Aaron Reed's 385,000-word "Blue Lacuna" changed our minds.
"A la recherche du temps perdu" is about 1,500,000 words, "Clarissa" about
1,000,000, and "War and Peace" about 500,000, so it's not impossible for
novels to grow to such sizes.

"Blue Lacuna" provided some real-world profiling information on how Inform
handled very large source texts. Although no major bottlenecks were found,
a little tuning produced about a 10% speed gain on these larger projects.

Inform now takes advantage of a March 2009 extension to the Glulx virtual
machine specification which causes certain I6 veneer routines (called very
frequently during play) to be implemented natively rather than in Glulx
emulation. This can result in speed-ups of a factor of 2 or 3, though those
gains will only be realised on a Glulx interpreter which supports the new
"acceleration" feature. (The Glulx interpreters built into Inform as the
Game panel do support it, and work is under way in making stand-alone Glulx
interpreters support this too.)

OPTIONS AND TELEMETRY

When Inform starts up, it now looks for a file called Options.txt inside
the user's home folder for Inform. (On Mac OS X, this is "~/Library/Inform";
on Windows, "My Documents\Inform", and so on.) If the file is present, then
the text in it is added to the source text of everything Inform translates.

This should be used only to set use options, and given the potential for
confusion (it's easy to forget that the Options.txt file is there), should
only be used if really necessary.

A new use option, "Use telemetry recordings.", causes Inform to copy its
outcome and problem messages to files in the home folder (see above) as
they occur. These files are dated, so that for instance

	Telemetry 2009-03-25.txt

contains all of the recorded activity on 25 March 2009. Telemetry only
records the contents of the "Problems" panel - notes of success or failure,
and problem messages - and (see below) nothing is transmitted via any network,
so it isn't really surveillance. The user can deliberately add a note to
the current telemetry file by writing something like this in source text:

	* "I don't get it! What's a kind? Why can't the lamp be lighted?"

(This is a way to make a note for the benefit of someone who will read the
telemetry file - for instance, to comment on a problem message that has just
appeared. Note the double-quotes. Otherwise, it's meant to look like the
standard way that beta-testers mark up IF transcripts.)

These two features have been added in response to requests from education
users. Let's suppose that Mr Lebling, who teaches 5th grade in Minnesota,
wants to set things up just right for his class. He installs Inform on the
ten computers they will use, and also copies an Options.txt file from his
memory stick onto each one. The Options.txt file reads:

	Use serial comma.
	Use American dialect.
	Use telemetry recordings.

Now Mr Lebling's class won't be confronted with English spellings, and
so on. And most of the kids are happy, but Mr Lebling gets the feeling that
young Marc wasn't really paying attention, so after class he checks that day's
Telemetry file for that computer to see what Marc was up to, and whether he
was stuck on something.

(The Telemetry feature was originally devised to help with testing the
response of real users to problem messages, and to find out which problems
are most often generated. Telemetry systems like this are often built in to
large applications - for instance, Microsoft Word - and the name implies
that data can be sent back to the manufacturers, who thus get to look over
their users' shoulders. But Inform transmits nothing at all, even if the
use option is set, which by default it is not. So this feature really can't
invade anyone's privacy. But we would, if people are willing, be very
interested to see telemetry files resulting from genuine classroom use, and
use by complete newcomers - we'd really like to know which problem messages
puzzle people, and what the stumbling blocks are.)

MAINTENANCE

It's hard to say whether this is a bug fix or not; more a slight change in
	philosophical outlook. Inform previously rejected this sort of thing:
		Before taking something:
			if a block is larger than the noun, say "Look out!"
	on the grounds that it couldn't know whether the noun was comparable in
	size to blocks - it would be if the noun were a block, but not otherwise.
	This generated a problem message. What now happens is that the above
	compiles to run-time checking, and a run-time problem is generated if
	the noun ever turns out not to be a block. (This is done because we
	often have a situation where the source text does guarantee things about
	the kinds of objects involved, but which Inform is unable to see.)
Another one that is arguably a change of design rather than a bug fix:
	subject-verb inversion in assertions has been withdrawn for prepositions
	which are also participles. In previous builds, Inform would accept the
	somewhat Yoda-like sentence
		Holding the light sabre is the young Jedi.
	which is an inversion of
		The young Jedi is holding the light sabre.
	...yet has the same meaning. Inversions are often perfectly natural in
	English:
		On the table is a jar of marmalade.
	So we don't want to rule them out altogether. But we do want to prevent
	these sentences from being misread as inversions:
		Holding Area is a room.
		Wearing something is good manners.
The order of testing the conditions on when a rule applies has been reversed.
	That sounds a more dramatic change than it really is; it means that a rule
	such as
		Instead of X when Y: ...
	will test to see if the action is X before testing whether condition Y is
	also true, rather than vice versa, as happened in previous builds. The
	main reason for this is so that a rule like
		Before printing the name of a vehicle (called the car) when the
			traffic warden cannot see the car: ...
	works properly, because the "car" variable is set during the test of X
	(that the "printing the name" activity is being applied to "a vehicle
	(called the car)"), and so is available for use in condition Y
	("the traffic warden cannot see the car").
When one rule is "listed instead of" another one in the same rulebook,
	previous builds of Inform duplicated the first rule to provide the
	replacement; this had some advantages but broke the principle, implicit
	in the syntax and usually helpful (not to mention announced in the manual)
	that a rule can only occur once in the same rulebook. This build moves
	rather than duplicates the build. There was some debate about this on
	rec.arts.int-fiction in February 2009, and opinions were divided; we
	changed our own minds in the making of this new build; but in end, what
	lawyers call a bright-line test - a simple easily-stated principle - seemed
	for the best.
When an actor other than the player tries an action which needs him to be able
	to touch one of the objects involved, Inform normally applies the basic
	accessibility rule (and thence the accessibility rulebook) to make the
	decision about whether this should be allowed, just as it would if the
	player tried the same thing. In previous builds, an exception was made
	for doors and backdrops, whose ability to be present in multiple rooms
	made it difficult to determine accessibility for third parties. Erring
	on the side of caution, the item would be assumed accessible. In this
	build, that leniency is narrowed so that it applies only in the case
	of third-party actors in a different location from the player.
When Inform tests to see if an action applies, and it finds a region where it
	might have expected a room, it reads this as any room in that region.
	This is why:
		Instead of going from the Great Tundra, ...
	matches going from any room in the Great Tundra region, and since an
	action cannot apply to a region, there's no ambiguity here. But 5U92 also
	applied the same room to activities, which _can_ apply meaningfully to
	regions in their own right, and this was a bug. It has been fixed.
In previous builds, it was legal but futile to try actions like this one:
		try asking Xerxes about "Athenians";
	- futile because command text is always reduced to lower case, so that
	the capital A in Athenians makes it guaranteed not to match anything
	Xerxes knows about. In this build, command snippets like this in a "try"
	are automatically reduced to lower case.
Attempts to determine "the time since Alien Landing began" or "the time when
	World Obliteration ended" are not possible if these scenes have, in fact,
	never begun or ended. In previous builds, these questions would produce
	misleading answers. They now produce run-time problem messages.
Problem message added to explain why doors cannot be "part of" other things,
	and how to achieve the same effect in other ways.
Problem message added, in place of an internal error, if directions are created
	by complex rather than simple sentences (in defiance of the instruction
	in the documentation not to do this).
Problem message added, in place of an internal error, if the source tries to
	assign properties to all kinds (e.g. by "A kind can be cool or lame.").
Problem message clarified when the source tries to use the name of a kind
	of value as a 'let' variable name (e.g., "let the number be 10").
Problem messages improved when lists are rejected because the spacing before
	commas is missing.
Problem message added to be more helpful if "out of play" is used instead of
	"off-stage".
Problem messages added when Inform 6 code is Included in place of template
	files which don't exist, or parts of them which don't exist.
Problem message added, in place of an internal error, for attempts to
	construct a phrase in a vague way, like so:
		The factorial of a number is a phrase.
Problem message added, in place of an I6 error, when a property name containing
	bizarre textual matter is created, usually as a result of missed punctuation:
	for instance, because of the missing full stop after "climbed" in:
		The Tree can be climbed "There is a tree in the middle of the lawn."
Problem message added, in place of an internal error, for attempts to give
	definitions to phrases like "To try (the feat - an action): ..." which
	treat "feat" as if it were a value. (Inline definitions can use this,
	but not as a value, and nobody else can use it all. "Stored action" would
	be fine, as the problem message explains.)
Problem message added to catch attempts to say that whole kinds of backdrop
	are "everywhere". (You can say a backdrop is everywhere, but only one
	backdrop at a time.)
Problem message added to catch certain name-clashes between new values
	created as table entries, and other values already existing.
Problem message added to catch "a random X" where X describes something with
	a domain which can't sensibly be searched - "a random text", for instance.
Problem message added to prevent defining a rulebook, activity or action
	variable with a name which already has a meaning as something else.
Bug fixed whereby a hidden limit of 255 grammatically different command verbs
	was being applied. Exceedingly this limit (which is quite hard, in fact)
	resulted previously in inexplicable mix-ups between the command verbs at
	run-time, clearly a very bad thing. Inform now enforces the limit on the
	Z-machine, where it's inherent, and lifts it on Glulx, where there can
	now be 65535 grammatically different command verbs. (Applying this fix
	required changes to the I6 compiler; we'd like to thank Brian Rapp, who
	posted issue C63010 to the I6 support pages, for putting us on the right
	track.)
Bug fixed whereby releasing an existing story file (for instance to publish
	an old I6 project with new cover art and bibliographic data) would
	generate a spurious I6 error.
Bug fixed whereby a bogus "too many activities" run-time problem message would
	appear once an "[any ...]" token in parsing produced a particular kind of
	parser error message on more than 20 different turns during play.
Bug fixed whereby a condition property with three or more names, which was
	also given an explicit property name, would have the last name wrongly
	taken down: thus
		A fruit can be unripened, ripe, overripe, or mushy (this is its
		squishiness property).
	would lead to "mushy" not properly being defined.
Bug fixed whereby lengths of time (though not times of day) mixed up hours
	and minutes, so that
		let T be 8 hours 3 minutes;
	would in fact set T to 3 hours 8 minutes. (Blushes all round.)
Bug fixed whereby route-finding wasn't working through one-to-one relations.
	(It seems we just forgot this case: one-to-various, various-to-one, and
	various-to-various all worked.)
Bug fixed whereby, if two actions look the same except that one takes two
	objects rather than one, then check/carry out/report rules can sometimes
	apply to the wrong one. For instance, given actions "tying" and "tying it
	to", a rule such as "Check tying something to: ..." could wrongly apply
	to the one-object form "tying" rather than to the two-object form.
Bug fixed whereby a stored action property attached to a kind of object will
	be such that all instances of that kind which do not define their own
	value for this property will forever after share the default value, even
	if it is changed for some instances and not others.
Bug fixed whereby mysterious run-time problems to do with your former self
	not having properties would appear in situations where the player is named
	as a character, and a property has been given to all people.
Bug fixed whereby a list of ordinary texts being copied into a list of indexed
	texts would lose their contents, or be corrupted.
Bug fixed whereby it would sometimes be possible to reach inside a closed
	container, if that container were part of something else which could be
	touched by the person concerned.
Bug fixed whereby a person asked to perform an out of world action will
	silently do nothing. The reply is now something like this:
		> CLARK, SAVE
		[That command asks to do something outside of play, so it can only
		make sense from you to me. Clark cannot be asked to do this.]
	(This is a new library message - Miscellany number 74.)
Bug fixed whereby "does the player mean" rules would sometimes not apply in
	several cases where the grammar in question involves two nouns, and the
	second noun either follows immediately on the first or has some stipulation
	applied to it (such as that it be "[someone]"), or where the first noun
	has some stipulation applied but which the second noun does not share.
Bug fixed whereby, relatedly, the definition of the "block tying rule" in the
	Standard Rules was loosely worded and could catch one-object forms of
	tying, as well as the two-object form in the Standard Rules for which it
	was intended.
Bug fixed whereby Glulx programmers creating additional Glk windows would find
	that sound channels were improperly created, and that random-number
	generation would not necessarily be "fixed" on debugging runs. (Many
	thanks to Eliuk Blau, for both finding and correcting this.)
Bug fixed whereby units set up to imitate decimal places would print values
	wrongly if in between 0 and -1; e.g., given "A weight is a kind of value.
	-99.999 specifies a weight.", the value "-0.123" would print as "0.123".
Bug fixed whereby table entries initially set to unspecified lists, with a
	column entry described only as (say) "a list of times", would then during
	run-time appear sometimes to be lists of numbers regardless of what they
	had been intended to contain.
Bug fixed whereby optional clauses in descriptions of actions would not always
	be checked for sense - or rather, they would, but would fail with an
	internal error instead of a helpful problem message.
Bug fixed whereby setting or testing the "to be through" relation, for talking
	about the far side of one-sided doors, silently failed during play.
Bug fixed whereby a various-to-various relation where one of the two domains
	was a kind with no instances would sometimes produce I6 errors in
	translation.
Bug fixed whereby, if the player gets into an enterable container on top of
	a pushable between rooms enterable supporter, and then tries to push that
	supporter to another room, a spurious programming error is displayed as
	well as the (thoroughly merited) reproof.
Bug fixed whereby a supporter which held only an undescribed item would
	sometimes be mentioned in a broken-off sentence in a room description; e.g.
		An easel is a supporter in the studio. "An old fashioned easel is
		here." A painting is on the easel. It is undescribed.
	would produce
		An old fashioned easel is here.
		On the easel .
Bug fixed whereby confusion could occur between actions which have similar
	names except that one takes two nouns and the other only one, e.g., as
	between "pointing at" and "pointing it at".
Bug fixed whereby the use of brackets in heading names - e.g. "Section 2(c)1" -
	could cause bracketed stipulations like "(for use with...)" to be
	unrecognised.
Bug fixed whereby matching the names of extensions in headings (those "for
	use with E by A", for instance) was performed case-sensitively - so that
	unless the exactly correct casing was used, the heading would behave
	unexpectedly. (Sorry: some people thought this was us being pedantic,
	but in fact it was an accident.)
Bug fixed whereby the SHOWME testing command would incorrectly claim that
	some items were "initially carried".
Bug fixed whereby the serial comma would be missed out of some lists produced
	by "say", even when "Use serial comma" was in force.
Bug fixed whereby mapping tips given to improve the World index map would not
	always work where room names included the words "of" or "from".
Bug fixed whereby the Kinds index would sometimes doubly list an either/or
	property ("Usually... drab not colorful, colorful not drab").

EXAMPLES

Added "The Speed of Thought" to demonstrate unit conversions.
Added "Hatless" to spell out some details of how "now" works with randomness.
Added "Slogar's Revenge" to demonstrate unlocking a door with a key can be
	worn instead of carried (and thus how to manipulate the carrying
	requirements rules)
Added "The Facts Were These" to demonstrate giving multiple objects at once,
	with different results than if the player offered them separately
Added "Oyster Wide Shut" to offer an alternate (and more flexible) way to
	handle the inventory listing of properties such as "(closed)"; it also
	allows the author to add his own properties to the standard list.
Added "Whither?" to illustrate letting the player refer to a door as "the
	west door" or "the east door" under the appropriate circumstances.
Added "Widget Enterprises" to demonstrate equations.
"The Abolition of Love" and "What Not To Wear" changed to reflect the new
	flexibility of "now".
"Zorb" updated to deal with a sentence of explanation that stopped without
	ending, and also to make it possible for the player to ride in the Zorb.
"Identity Theft" given extra commentary to explain the different effects of
	compiling under Z- or Glulx.
"Four Cheeses" improved with more refinement of scope-handling for interacting
	with a distant person who should not be visible.
"Verbosity" slightly tweaked to give more information about how defaults work.
"Verbosity 2" added to demonstrate how to *force* the player always to use
	full-length room descriptions (rather than merely setting the default and
	allowing him to modify it).
"Only You" simplified and moved to an earlier section because Inform now
	pre-defines the adjective "even".
"Channel 2" typo fixed.
"Peeled 2" error fixed, and the documentation slightly expanded.
"Dinner is Served" revised to make the sample code more safely portable into
	a larger game, and to remove a procedural rule that is no longer necessary.
"Puncak Jaya" edited to improve behavior with revised accessibility rules,
	and to deal with the case where a ghost is the second noun rather than
	the noun.

BUILT-IN EXTENSIONS

New built in extension, "Metric Units": see above.
Documentation for "Menus" substantially rewritten and the version number
	advanced to 3.
"Basic Screen Effects" and "Complex Listing" adjusted to be more safely
	compatible with "Case Management": all three were defining a printed_text
	array but not consistently, with the result that some compilation effects
	varied depending on which extension was included first.
"Rideable Vehicles" tidied up to be more consistent in handling how actors
	other than the player are treated; version number advanced to 3. The rules
	here have been more cleanly arranged, but with some renamings as a result -
	for instance, the "no person mounting a mounted animal rule" used to
	apply only to non-player actors, while the corresponding rule for the
	player was anonymous. There is now a single "can't mount when mounted on
	an animal rule". So any source text making use of the old rule names in this
	extension will need tidying up, or will need to use version 2. The actual
	functionality of the extension has not changed except that commands like
	"tanya, get on mystery" are now correctly understood; a cosmetic blemish in
	descriptions when multiple people are riding the same animal has been fixed.

RECIPE BOOK

Slightly expanded the section on start up features in order to include the
	idea of doing some game initialization, as necessary.
Added a section "Other Built-in Actions" to the Commands section, which
	provides some explanation and cross-referencing for a number of types
	of action.
Extensively rewrote the "Actions on Multiple Objects" section to provide a
	clearer explanation of how the multiple objects list works.
Expanded the "Modifying Existing Commands" section to explain more clearly
	how to change the carrying requirements and related rules, and
	cross-referenced this segment from "Barter and Exchange", "Taking,
	Dropping, Inserting and Putting", and several sections that pertain to
	locking or placement.
"Room Descriptions" section added to the "Place" chapter, which mostly
	contains material formerly under "Commands > Looking". Looking now points
	to this section; this organization change is due to assorted user
	feedback about where people were looking for material most often (and
	not finding it).
"Going, Pushing things between rooms" expanded to explain the behavior of
	pushing more clearly; to offer more examples of how to write conditional
	rules governing pushing; and to lay out the details of meddling on room
	descriptions produced specifically in the context of going actions (as
	opposed to in response to LOOK). The previously under-documented "the
	room-describing action" variable used by the looking rulebooks is also
	explained in this section.
"Scoring" expanded to explain the NOTIFY ON and NOTIFY OFF commands, to
	exemplify how to modify their behavior, and to refer the player to
	default message extensions in order to change the wording of such
	messages as "[Your score has just gone up by two points.]"
"Saving and Undoing" expanded to mention undo prevention and warn against
	some of the dangers of using it.
"Glulx Multimedia Effects" expanded to discuss in more detail what is and
	isn't at least theoretically possible under Glulx, in terms of sounds
	and images. (Several people on the newsgroup have asked recently whether
	it is possible to have multi-channel sounds or fade-ins and fade-outs
	under Glulx. The answer is yes, but it is not easy. The section suggests
	the prospective author check out the latest tools from the Inform
	extensions site.)
"Settings and Status Checks During Play" section added to the Out of World
	chapter; this is largely a pointer to other sections of the manual
	(verbosity under Looking, notification under Scoring), but it also
	explains the other more obscure out of world actions. This is in response
	to an outstanding request that the unusual out of world actions be
	better documented.
"Background, Memory and Knowledge" divided into two, considerably expanding
	the discussion of ways to track player character knowledge and use that
	tracking to affect descriptions, object names, and scope.

§11.3. What was new in build 5U92 (September 2008)

As this release was being prepared, King Tupou V of Tonga was crowned, but Nepal became a Republic; climbers were lost to avalanches on K2 and Mont Blanc; Australia became perplexed at winning fewer Olympic medals than Great Britain; the most wanted man in Greece, who had escaped from prison by helicopter, was recaptured; a 50-foot spider spent a week crawling at 2 mph across the Liverpool skyline, spraying random passers-by with water; and many journalists had to learn how to spell "Ossetia" at a time when they would rather have been watching the sports channels.

In the world of Inform, a set of related improvements was made to the way adjectives, nouns and verbs combine in descriptions. This lifted many restrictions which made talking about values less flexible than talking about objects, and showed the language gradually becoming more general. In addition, directions could now be created freely. All 110 issues arising from bug reports since build 5T18 were closed out.

5U92 (10 September 2008)

This build makes a set of related improvements to the way adjectives, nouns
and verbs combine in descriptions. This lifts many restrictions which made
talking about values less flexible than talking about objects, and shows the
language gradually becoming more general. This brings only subtle (if nice
to have) improvements for authors, but improves the coherence of the design
of Inform. In addition, directions can now be created freely, fulfilling the
last outstanding promise made in the January 2007 consultation document.
There are miscellaneous minor improvements, and five months' worth of
maintenance changes. All 110 issues arising from bug reports received up to
7 September 2008 have been closed out.

INFORM FOR WINDOWS

Added a preferences dialog, allowing the tab size in the source panel to be set.
Drag and drop in the source panels now follows the usual Windows conventions:
	by default the operation is a move, and holding down the 'Ctrl' key
	during the drag makes it a copy.
Fixed a bug in the built-in Glulx interpreter that generated
	spurious timer events.
Accented characters in the user's name should no longer cause the compiler
	to crash.

INFORM FOR LINUX

Internationalized all the strings in the user interface, so that translators
	can if they wish translate these. (A Spanish translation has been started,
	thanks to Ángel Eduardo.)
The Documentation text will now still be visible when using a light-on-dark
	desktop theme.
The dialog that appears when you start the program can now be closed, in case
	you started the program by accident.
Bugs fixed that caused some preferences to revert to their default values
	every time the application started.
Bug fixed that caused a crash when deleting some items from the Skein.
Various minor bugs and crashes fixed.

NATURAL LANGUAGE

Descriptions and adjectives have each been expanded in scope, so that many
	kinds of value can now be handled in ways which previously only worked
	for objects. Specifically:
Either/or and value properties can now be given to any kind of value
	with named, enumerated outcomes. So for instance:
		A scene can be thrilling or dull.
		A scene has a text called cue speech.
	or:
		Colour is a kind of value. The colours are red, blue and green.
		A colour has a number called frequency. The frequency of a colour
		is usually 130.
	As with objects, the names of either/or properties act as adjectives
	describing a scene.
Descriptions can now talk about values as well as objects. So:
		if N is an even number, ...
		if the score is positive, ...
		let L be the list of thrilling scenes;
		repeat with S running through non-recurring scenes: ...
		if more than three scenes are dull, ...
	all now work. Repeating through and listing require that the possible
	range of the kind of value is finite - so you can't write
		let L be the list of numbers;
	(which would have to be infinite). See the chart at the bottom of the
	redesigned Kinds index page to see when repeating and listing are allowed.
The same adjective can now have multiple independent meanings, and there is
	no difficulty provided that these apply to different things. Thus a
	definition of "fancy" for a colour would not obstruct a definition of
	"fancy" for a door, for instance.
The Standard Rules now define the following adjectives for values as built-in:
		even, odd, positive, negative - for numbers
		empty, non-empty - for texts, indexed texts, tables, rulebooks,
			activities, and lists
		recurring, non-recurring, going on - for scenes
	(Note the six independent definitions of "empty" depending on context.)
	"Recurring" used to be an adjective which could be used only when creating
	a scene, as in:
		Train Stopping is a recurring scene.
	It is now an either/or property, which means we can change it at run-time:
		now Train Stopping is non-recurring;
Now that scenes can be described in flexible ways, we can use the "during ..."
	clause of a rule flexibly, too. For instance:
		Before going north during a dull non-recurring scene, ...
	(Previously "during" could only name a single explicit scene.)
There is now a short-hand way to define the antonym of an adjective, that is,
	the name of its opposite. For instance, the Standard Rules include:
		Definition: a number is even rather than odd if the remainder after
		dividing it by 2 is 0.
	The optional part here is "rather than odd", which saves us writing:
		Definition: a number is odd if it is not even.
	(Note that different meanings of an adjective can have different opposites.
	We could, if we wanted, write
		Definition: a stored action is empty rather than purposeful if ...
	and then the opposite of "empty" would be "purposeful" in the context
	of stored actions, but "non-empty" for the other cases above.)

Inform has always supported a convenient quick way to create a property,
	sometimes specific to a single thing, which have three or more named
	possibilities:
		A fruit can be citrus, berry, melon, or pome.
	This actually makes a property called "fruit condition" and creates a
	new kind of value whose possibilities are enumerated as "citrus", "berry"
	and so on. The author often never needs to use the name "fruit condition",
	because the adjectives "citrus", "berry", ..., are convenient enough by
	themselves.
	But because Inform forms the property name in this way, there's a
	collision if two different ranges are created:
		A fruit can be unripened, ripe, overripe, or mushy.
		A fruit can be citrus, berry, melon, or pome.
	In previous builds this prevented two such conditions from existing at once
	for the same thing or kind. Inform now allows any number of conditions to
	exist independently of each other; if the author supplies an explicit name,
	that's used, and otherwise Inform automatically makes names. Thus:
		A fruit can be early, summer or late.
		A fruit can be unripened, ripe, overripe, or mushy (this is its
		squishiness property).
		A fruit can be citrus, berry, melon, or pome.
	creates three properties, called "fruit condition", "squishiness" and
	"fruit condition 2" respectively.
	This means that an extension author can write, say,
		A vehicle can be brand new, roadworthy, battered or wrecked (this is
		its serviceability property).
	without "using up" the eventual user's ability to make his own "vehicle
	condition".
	Conditions like these can be created for anything which can have a property,
	and in particular for scenes and enumerated kinds of value as well as
	for objects (see above).

It is now possible to use "there", as in "there is" or "there are", to
	talk about whether or not something exists. Here are some examples in
	assertion sentences:

		There is a room called the Shadow World.
		There is a box in the Shadow World.
		There is a jigsaw puzzle in the box.

		A coin is a kind of thing. There are two coins on the crate.

		Incrimination relates various things to various people. The verb to
		incriminate (he incriminates, they incriminate, he incriminated, it is
		incriminated, he is incriminating) implies the incrimination relation.

		There is a man called Mr Darcy. There is a pair of boxer shorts which
		incriminates Mr Darcy. There is a fishing rod incriminating Mr Darcy.

	And here are some examples in conditions:

		if there is a man, ...
		if there are vehicles, ...
		if there is nothing in the box, ...
		if there are three coins in the box, ...
		if there are exactly three coins in the box, ...
		if there are at least three coins in the box, ...
		if there is something incriminating Mr Darcy, ...
		if there is nothing incriminating Mr Darcy, ...
		if there are fewer than two things which incriminate Mr Darcy, ...

	Note that

		if there are three coins in the box, ...
		if there are at least three coins in the box, ...

	have the same meaning: if the number of coins in the box is four, then
	there do exist three coins in the box, which is what these are testing.
	"Exactly" is more precise:

		if there are exactly three coins in the box, ...

As some of these examples suggest, the handling of "nothing" has been
	improved so that it can be used in a wider range of contexts, and a few
	bugs have been fixed in the process. For instance, the following now works:

		now nothing incriminates Mr Darcy;

	And similarly for "nowhere", "nobody", "no-one" and even "no one" -

		now nobody in the Temple is surprised;
		if nowhere is dark, ...
		if no one is in the Temple Annexe, ...

It has always been legal to use "not all" in a condition - for instance,
		if not all of the coins are in the box, ...
	"Not every" has been added, so that this has the same meaning:
		if not every coin is in the box, ...
	And similarly, we can now if we wish write
		if not more than four coins are in the box, ...
	or (equivalently)
		if not fewer than six coins are in the box, ...
		if not less than six coins are in the box, ...
	Those are the only determiners to which "not" can be applied. So this,
	for instance, continues not to be allowed:
		if not some of the coins are in the box, ...
There was previously a hard limit of 32 on the maximum number of relations
	"in groups" which could be created in any single compilation: this has
	been removed and there is now no limit.
The relation which tests whether two things are equal now has a name: it is
	the "equality" relation. So for instance it's now possible to define -
		The verb to be identical to implies the equality relation.
	(There's no obvious reason for doing this, but it was anomalous that it
	couldn't be done before.)
When a verb is created in the form "to be able to...", as the Standard Rules
	does with the line:
		The verb to be able to see (he is seen) implies the visibility relation.
	then the following prepositional forms can be used:
		"to be able to see"
		"to be unable to see"
		"to be able to be seen by"
		"to be unable to be seen by"
	The last of these, "to be unable to be seen by", did not work in previous
	builds, having been overlooked. So it is now possible to write, e.g.,
		if Peter is unable to be seen by Paul, ...
		if Peter had not been unable to be seen by Paul, ...

DIRECTIONS

Directions have been reformed. In earlier builds it was difficult to create new
	directions (and the documentation officially said that this could not be
	done at all); I6 hacks were needed, and the results sometimes failed.
	Directions can now be created freely, or at any rate pairs of them can:

		Turnwise is a direction. The opposite of turnwise is widdershins.
		Widdershins is a direction. The opposite of widdershins is turnwise.

	- To create a direction, a simple sentence in the form "X is a direction."
		must be given.
	- Each direction has to have a value for the "opposite" property, which
		has to be another direction; these must be in matched opposing pairs.
	- The maximum length of a direction name used to be 1 (i.e., they had to
		be single words); now it is 3.
	- The maximum number of directions used to be 16; now it is 100.
	- New directions are exactly as good as old ones: for instance we can
		write "to be mapped turnwise of", or use route-finding through new
		directions.
	- Each direction automatically makes a relation, the "mapping-turnwise
		relation" (or similar), which is the meaning of "to be mapped
		turnwise of". This enables us to define prepositional forms; for
		instance, the Standard Rules includes the line:
			The verb to be above implies the mapping-up relation.
	- The I6 implementation beneath the surface is new: there are no "n_to",
		"s_to", etc., I6 properties any longer; the "door_dir" property for
		doors now holds a direction object, not a direction property as it did
		in the I6 library; the map is stored in a flat array instead. See
		the template file "WorldModel.i6t".

MINOR NEW FEATURES

Scenes can now be said - that is, if X is a scene, then "[X]" now expands
	to the name of the scene.
It is now possible to have "let" and global variables of the kind of value
	"sound-name", which hold sound effects. (The default value for this is
	a special silent sound, the playing of which has no effect, but which
	is present in all compilations regardless of whether they use sounds
	or not.) And similarly for "figure-name" and "external-file". "Scene",
	which up to now could be held in a global but not a local variable
	(an oversight) can now be either.
Truth states (both of them) can now be understood, so actions can be made
	which are applicable to them, and "[truth state]" is a valid Understand
	token.
The Understand token "[a time]" matches a time of day, such as "10:15 AM"
	or "midnight". But the "time" kind of value can hold relative times as
	well as absolute ones -- for instance, 10 minutes is a time, but it is
	not recognised by "[a time]" since it isn't a specific moment in the day.
	A new Understand token called "[a time period]" has been added for this,
	so for instance
		Understand "wait for [a time period]" as ...
	would match WAIT FOR AN HOUR or WAIT FOR TWO HOURS 12 MINUTES.
The handling of mixed-case notations has been improved - for instance, given
		Acidity is a kind of value. pH 7 specifies an acidity.
	the "p" will always be printed in lower case, and the "H" upper case.
	Printing back always respects the case in the original specification;
	but parsing is always case-insensitive.
Repeating through tables used to carry the risk that if something in the body
	of the loop changed the row selection, the loop would break, since it used
	the row selection itself as an iterating variable. This has been corrected.
	A "repeat through" loop can now be nested inside other "repeat through"
	loops; the body of the loop can change the row selection without harm;
	moreover, a "repeat through" loop preserves the row selection, so that
	on exit, the same row (if any) is selected as was selected before the
	loop began.
When tables are sorted "in random order", blank rows are now automatically
	moved to the bottom. The non-blank rows occur in a uniformly random order
	at the top of the table.
When "Include ... instead of ..." is used to replace a part or segment from
	the I6 template, a subsequent "include... instead..." on the same part or
	segment now overrides an earlier one. (In 5T18 both would be applied, but
	this almost never led to valid I6 code, and it's hard to think of
	circumstances when users would want that behaviour.) It continues to
	be the case that "Include ... after ..." and "... before ..." allow
	multiple inclusions attached to the same part or segment.

INTERFACE TO I6 INTERNALS

There are now two ways to specify that an adjective is defined at the I6 level:
		Definition: a rulebook is empty rather than non-empty if I6 routine
			"RulebookEmpty" says so (it contains no rules, so that following
			it does nothing and makes no decision).
	The part in brackets does nothing, but is the text used in the Phrasebook
	index for the user's benefit; it should be a brief definition. The I6
	routine should take one parameter, the value on which the adjective is
	being tested, and should return true or false as appropriate.
		Definition: a rulebook is exciting if I6 condition
			"excitement_array-->*1==1" says so (it is really wild).
	The condition is given as a "schema", in which the escape "*1" is
	expanded to the value on which the adjective is being tested. (This is
	usually faster than calling a routine, but in case of side-effects, the
	*1 should occur only once in the condition, just as with a C macro.)
The "translates into I6 as" verb now has another possible use: for Understand
	tokens. This is how the Standard Rules sets up the new "[a time period]"
	token, for instance:
		The Understand token a time period translates into I6 as
		"RELATIVE_TIME_TOKEN".
	(The I6 routine of this name can be found in the Time.i6t template file.)
	This might be of use to extensions which want to add very rich parsing
	possibilities which break existing conventions.

PERFORMANCE

The run-time storage of relations, kind membership and the map has been
	made slightly more efficient. The gain has been used to make projects with
	"use memory economy" in force run a little faster - previously, memory
	economy blocked Inform from generating faster searches through objects
	by using precompiled linked lists. That still leaves a memory saving of
	around 2.5K in a completely full Z-machine story file. This is not as
	ridiculous as it sounds, since the Z-machine has only 64K of dynamic
	memory to play with, and this tends to be the limiting factor on the
	size of projects which Z can handle. A minimal I7 project needs 24K of
	this, so a saving of 2.5K out of the remaining 40K represents room for
	maybe a 6% larger design. (Of course for Glulx projects this is all
	irrelevant - there are really no size limits at all.)

Some users observed that the 5T18 build compiled more slowly, and this was
	a large enough effect to make a considerable difference to novel-sized
	projects (with 200,000-word source texts). This proved to be an accidental
	side-effect of internal consistency checks only really needed when
	debugging Inform itself. This has been fixed, and large projects should
	once again compile at roughly the same speed as in 5J39 and previous
	builds.

MAINTENANCE

Problem messages added for attempts to write constant values in notations
	where the second or subsequent numerical element runs out of the legal
	range, or where the total value exceeds the maximum or minimum range
	which Glulx can hold. (There was already a similar check for Z-machine
	projects - for Glulx, of course, the bounds are larger.)
Similarly, run-time parsing of values in such notations is also checked
	more carefully to see that it remains in range.
Finally, the Kinds page of the Index now quotes the maximum possible
	value for both Z-machine and Glulx use. (It previously quoted this only
	for Z, thus giving a misleading answer if Glulx was used.)
Problem message added to explain what's wrong when the source text tries to
	provide command grammar for a word reserved as an Inform testing command,
	such as SHOWME. (And the indexing of these reserved commands on the
	Actions index page has also been improved.)
Problem message improved when "try" is applied to something which ought to
	be a valid action, but which isn't for type-checking purposes - for
	instance,
		try taking 22;
Problem message added (in place of an internal error) to catch cases where
	a verb is missing from a condition so that it otherwise forms a
	description with no obvious subject:
		if the player not carrying a thing, ...
	(which of course is missing an "is".)
Problem message added to block the use of "called" when it is being used
	only to rename one specific item, e.g.,
		if the Z-Boson Destructorator (called the gun) is carried, ...
	Previously this sometimes worked, but sometimes didn't, and in any case
	wasn't ideal from a stylistic point of view.
Problem message added to block the use of implications based on information
	not available at compile-time, such as:
		A room in the Garden is usually lighted.
	(Previously this disregarded the relation information - the "in the Garden"
	part - and therefore wrongly read the sentence as "A room is usually
	lighted", a valid but different implication.)
Problem message added to catch attempts to equate two kinds of variable, as in:
		The stored actions variable is a truth state that varies.
	(This has happened because the user didn't realise that "stored actions
	variable" was a general category of variables, and thus not a good name
	to choose for a specific one. In 5T18 it produced an internal error.)
Problem message added to object to saying that things are to be defined by
	a table, but also saying how many there are (which may of course be in
	conflict with the number of rows in the table):
		Three berries on the bush are defined by the Table of Tasty Berries.
	The word "three" is either redundant or contradicts what the Table says,
	and the problem message says it should be removed, e.g., by writing:
		Some berries on the bush are defined by the Table of Tasty Berries.

Run-time problem message added to explain why only things can be moved during
	play (not for instance rooms, regions or directions). (Although people very
	seldom try this deliberately, they do sometimes accidentally ask for it
	because of misunderstandings about short forms of names of rooms.)

Bug fixed whereby a small number of rules formed like this one:
		Before printing the name of an object: say "Print."
	would cause a spurious internal error; and similarly for rules such as
		Before listening to nothing: ...
	which can't in fact be useful (because "listening" always takes a noun),
	but ought not to trip over the compiler; and similarly for clauses
	such as:
		Instead of going east by nothing: ...
	in which optional details are added to an action (and these can indeed
	be useful: this example means going east on foot, i.e., with no vehicle).
	This was all one single bug, and was the one most experienced by users
	of 5T18 - apologies.
Bug fixed whereby and "[end if]" adjacent to an "[or]" in text, as here:
		"[one of][if the location is Lab]Lab[end if][or]blah[at random]"
	would cause an I6 compilation error. This was another very popular one.
Bug fixed whereby "try" with an action which applies to a topic would not
	work if applied to a snippet variable, so, for instance,
		try asking Bob about the topic understood;
	would fail.
Bug fixed whereby large rulebooks would in some cases misfile rules which
	depended on a single action _not_ being the current one, such as:
		Before doing something other than examining to the mercenary: ...
	(While this was a serious bug, it occurred only rarely, depending on
	complicated combinations of other rules also being in force.)
Bugs fixed to do with table columns holding indexed text, so that some attempts
	to look for corresponding values, or to search for values, or to copy a
	non-blank value into a blank, would fail with spurious run-time problem
	messages.
Bug fixed whereby sections replacing those in extensions:
		Section 1 - New foo (in place of Section 1 - Foo in Bar by Tina Banana)
	were not in fact always doing so in 5T18; and relatedly, when such
	heading tricks were used, were sometimes causing source text to be lost
	from the main text, resulting in spurious problem messages complaining
	that no room had been created. (It had, but in a sentence wrongly removed.)
Bug fixed whereby paragraph spacing would go wrong - usually with the expected
	gap between paragraphs going missing - in cases where a text substitution
	is defined which itself includes a "[paragraph break]" substitution. For
	instance, redefining:
		To say p -- running on:
			say paragraph break.
	ought to give "[p]" exactly the same effect as "[paragraph break]", but in
	5T18 the spacing after "[p]" would in some cases go missing.
Bug fixed whereby "resume the game", a phrase to be used in the "when play
	ends" rulebook to cause it not to end but to carry on after all, had
	stopped working. Particular apologies for this: we hadn't realised that
	nothing in the 5T18 test suite verified its behaviour.
Bug fixed whereby the "carrying capacity" for a container or supporter could
	not be read without run-time problem messages if it was not set explicitly
	in the source text. (It should have, and now does, default to 100.)
Bug fixed whereby a container called "sack" would sometimes wrongly be treated
	as if it were a player's holdall, if it were carried alongside a genuine
	player's holdall.
Bug fixed whereby a rule depending on something having happened for a small
	number of times only would not always apply if the action is silent, e.g.,
		Instead of taking the top hat less than three times:
		say "The top hat resists!"
	...would fail to apply if the top hat were being taken silently as a
	result of a command like WEAR HAT. (Apologies: this bug was introduced
	inadvertently as part of a bug fix made in 5T18, and did not occur in
	earlier builds.)
Bug fixed whereby the Standard Rules read
		A door is never pushable between rooms.
	instead of
		A backdrop is never pushable between rooms.
	(Both are true. In 5T18, the sentence was given for doors twice and for
	backdrops not at all.)
Bug fixed whereby the Standard Rules wrongly put the "switch the story
	transcript off rule" in the "carry out switching the story transcript
	on rulebook", not the one for "...off", so that in 5T18 the transcript
	once started couldn't be stopped.
Bug fixed whereby table sorting might fail if the table contained consecutive
	blank rows within the body of non-blank rows.
Bug fixed whereby the phrase
		let maximum score be a number;
	which fails because "maximum score" is already a global variable, so can't
	be a temporary one as well, would give both a problem message and also an
	internal error. It now just gives the problem message.
Bug fixed whereby source text such as:
		The Lab is a room. The barrel is a vehicle in the Lab. Sir John is a
		man in the barrel. The player is Sir John. The player is in the barrel.
	would create a bogus "yourself" object in the barrel, other than Sir John.
Bug fixed whereby Understand grammar using "[any ...]" would wrongly match
	all items within those specified, as well as the items themselves. For
	instance, "[any adjacent room]" would match not just the rooms, but also
	their contents. Apologies for this bug, which was introduced by accident
	in the template rewrite for 5T18.
Bug fixed whereby rules depending on actions which involve the text of the
	player's command would sometimes throw internal errors if they also
	required the use of named "Understand" tokens which weren't used in any
	of the ordinary command verb grammar. For instance:
		Understand "i7" or "inform" or "inform 7" as "[inform]".
		After asking Edsger about "[inform]":
			say "Projects promoting programming in 'natural language' are
				intrinsically doomed to fail."
Bug fixed whereby "does the player mean" rules would sometimes disambiguate
	the second noun of an action as if it were the first, in cases where
	the action uses "[things inside]" or "[other things]" as the first token
	(which the inserting action does, in particular). The documentation does
	warn that this might not work; it will now sometimes work, with care.
Bug fixed whereby a table with a number but not a name (say, "Table 5") could
	not be referred to elsewhere in the source in the same form (e.g.,
	"The utensils are defined by Table 5").
Bug fixed whereby "does the player mean" rules would not be applicable to
	going actions implied by commands consisting of a direction alone, such
	as SOUTH.
Bug fixed whereby, in complicated circumstances, two ordinarily identical
	things are wrongly considered still identical even after one has
	changed its property value for a property declared as describing them.
	(But only where this property is inherited from a mutual kind, which
	in turn has other "Understand" grammar defining it.)
Bug fixed whereby releasing a project with both a website and auxiliary files
	would produce links in the website which, though working for some browsers,
	failed for others, and which were local "file:" links rather than "http:",
	so that the result would not work when uploaded.
Bug fixed whereby an UNDO which takes us back to a position where the player
	is in darkness would print the location as "(darkness object)" rather
	than running the appropriate activity to describe darkness.
Bug fixed whereby "Use authorial modesty" did not always work when given
	in the main source text of a work by an author wanting to be modest
	about his own extensions, included from it.
Bug fixed whereby negative values of literals would sometimes be printed
	incorrectly (e.g., "-10.123" might be printed "-10.00-123").
Bug fixed whereby in rare cases the text of previous commands might be
	mingled with the text of a literal value being read in the current
	command.
Bug fixed whereby conditions for start and end of scenes would not properly
	work if they needed to manipulate indexed text, lists or stored actions,
	either throwing spurious problem messages or simply failing to match.
Bug fixed whereby, similarly, conditions for start and end of scenes would
	throw spurious internal errors if they contained table lookups.
Bug fixed whereby complex specifications of "in the presence of" people
	which involve callings or manipulate similarly complicated values would
	cause internal errors.
Bug fixed whereby relations applied to kinds rather than instances would in
	some cases throw an internal error rather than generate a problem message
	as being too unspecific:
		A supporter usually allows sitting.
Bug fixed whereby memory allocation would sometimes fail, in Glulx, when
	existing memory was sufficient but too fragmented to hold a large single
	block of data.
Bug fixed whereby Inform would refuse to create "let" variables called "nd",
	"st" or "th". (Exercise for the reader: can you guess why?)
Bug fixed whereby "Understand ... when ..." sentences would sometimes, if
	the condition was invalid, throw an internal error as well as a problem
	message.
Bug fixed whereby the sentence
		Here is everywhere.
	would crash Inform rather than produce an outraged problem message.
	(Yes, somebody tried this.)
Bug fixed whereby extension documentation would be wrongly punctuated around
	displayed example source text which contained explicit I6 inclusions,
	with a spurious "-)" to close the I6 inclusion, added at the wrong point.
Bug fixed whereby spurious "details" icons appeared after the names of kinds
	in the Lexicon index.
Bug fixed to do with the status line sometimes disappearing on the Z-machine.
Bug fixed to do with cursor movements in unusual font sizes in v6 of the
	Z-machine.
On Glulx works only, the "emphasised" type style now has the style hints
	weight 0 and oblique 1 set automatically when Glulx starts up: the point
	of this is that I7 uses this style to implement the text substitution
	"[italic type]". (Yes, yes, so the 5T18 change log made the same promise.
	But with any luck it will work this time.)

EXAMPLES AND EXTENSIONS

Examples:
	Added "Fabrication" to demonstrate the use of values which themselves have
		properties.
	Added "Bowler Hats and Baby Geese" to demonstrate the use of scenes with
		properties.
	Added "Elsie" to demonstrate a sliding door that closes automatically
		after being open for one turn.
	Added "Versailles" to demonstrate a mirror the player can look into.
	Added "Pizza Prince" to demonstrate a near-infinite supply from which
		the player can go on taking instances.
	Added "Extra Supplies" to demonstrate a supply from which the player
		can take one instance at a time.
	Added "North by Northwest" to demonstrate compass directions between
		the usual set, and how to deal with the nine-character limit on names.
	Added "The World of Charles S. Roberts" to demonstrate a hexagonal
		direction system.
	Modified "Copper River", "One Short Plank", "Mr. Burns' Repast", "Yolk
		of Gold", "Depth", and "Xylan" to use the new "there is..." syntax in
		places where the old syntax seemed a bit stilted.
	Modified "Solitude" to correct some errors in the comments caused by an
		over-zealous search and replace when truth states were introduced.
	Modified "Copper River" to list all objects explicitly while taking
		inventory, even if they are otherwise referred to as "assorted dull
		items".
	Modified "Bumping into Walls" to get rid of some inelegant grammar in
		the definition of viable directions, which is no longer necessary
		because of syntax improvements.
	Rewrote "Fore" completely to take advantage of new direction-defining
		abilities, rather than presenting the rather hackish methodology
		originally on offer.

Extensions:
	"Glulx Text Effects" updated to deal with an indentation bug. The version
		number is now 3.
	"Glulx Entry Points" updated to handle a bug introduced by the treatment
		of templates. The version number is now 6.
	"Locksmith" edited to bring conditional syntax in line with the new
		Pythonesque standard, and (more importantly) to give explicit names
		to a couple of rules that still lacked them. Version number is now 7.

Recipe Book:
	Expanded the contents of the section on ending the game to lay out more
		of the ways in which the final text can be altered.

§11.4. What was new in build 5T18 (April 2008)

As this release was being prepared, the Grand Canyon was deliberately flooded, while Sweden's largest lake was lowered by 15cm; in London, Heathrow Terminal 5's state-of-the-art automated baggage system went live; gold prices broke £500 per troy ounce, while Pernod Ricard bought Absolut Vodka for $9 billion; in London, Heathrow Terminal 5's state-of-the-art automated baggage system began to fail, with many cancellations; Vietnam banned pet hamsters; in Nashville, King Crimson began recording again, but in Princeton our greatest translator of Homer, Robert Fagles, died; and in Milan, 15,000 items of lost luggage arrived from Heathrow Terminal 5's state-of-the-art automated baggage system, so that they could be sorted by human beings instead.

In the world of Inform, build 5T18 finally made the long-awaited reform of "block structure", allowing Python-like syntax for grouped phrases, and made miscellaneous other improvements throughout. The Standard Rules were redrafted and formally advanced to version 2, and the standing I6 code used by I7 - the "template" - was completely rewritten. The first steps were made towards an official system for translating I7 into languages of play other than English, something which had previously been done but only with great difficulty. Certain run-time algorithms were optimised for speed, and all 162 open bug reports as of 26 April 2008 were closed out.

Besides the new examples, new material was added to the Recipe Book to give more guidance on designing new commands (see the Commands chapter), on the looking action and on conversation.

5T18 (30 April 2008)

This build is founded on a major reform of the infrastructure supporting
Inform. It contains miscellaneous new features to complete the work
of implementing the less speculative proposals planned in the January 2007
consultation document. (A second consultation document will be published
later this year to lay out future plans.) The interface application
contains a new Source view for OS X which should handle large projects
much better: it will follow on other platforms in subsequent builds.
The first steps are made towards an official system for translating I7
into languages of play other than English, something which has previously
been done but only with great difficulty. Certain run-time algorithms have
been optimised for speed, and all 162 bug reports received up to 26 April
2008 have been closed out.

INFORM FOR MAC OS X

The Source panel is now divided into two side-by-side views: Contents and
	Source. These are alongside each other, but only one is visible at a time,
	and each slides out of the way to make room for the other as needed. The
	Contents view shows a contents page for the source text, automatically
	generated from its headings. A slider can be used to control how much
	detail is shown. Clicking any heading slides back into the contents
	view, but showing only the material under that heading (and its
	subheadings, if any). This makes very large source texts much more
	manageable, and also provides a useful overview of an entire project.

INFORM FOR WINDOWS

The Contents view has also been partially implemented on Windows. On
	selecting this pane from the source tab, a window slides in from the
	left showing some or all of the headings in the source, depending on
	the slider at the bottom of the window. Clicking on a heading causes
	the contents pane to slide back and the source tab to jump to the
	chosen heading.
A spell checker has been added, using the "hunspell" project from
	OpenOffice.org. Only words that will appear as text in the game are
	checked. Currently this is accessed through the new "Check Spelling"
	Edit menu item: checking spelling as the user types will be implemented
	later.
Copying tables from the documentation to the source tab via the clipboard
	or through drag and drop should now work correctly: the table will
	be pasted with tabs rather than spaces between columns.
If the registry DWORD value
	"HKCU\Software\David Kinder\Inform\Window\Watch File Changes"
	exists and is set to zero, then the application will not notify
	the user if the "source.ni" file is changed by another program.

INFORM FOR LINUX

The long-awaited Skein tab has been added to the GNOME application; all
	features that are relevant without an accompanying Transcript tab
	are fully-functional.
The Game tab now runs Glulxe 0.4.3.
GtkSourceView 2.0 adopted, which means several fixes for the syntax
	highlighting. Thanks to Zachary Amsden for submitting a patch which
	did much of the work.
	- Most importantly, nested comments are now highlighted correctly.
	- Inform 6 code is highlighted as in the OS X application.
	- Words like "if" and "otherwise" are no longer highlighted burgundy.
	- Syntax highlighting in general should be somewhat faster.
Fixed various, minor bugs, some of which were tracked down and patched
	by Alan De Smet and Jonathan Liu.
Jonathan Liu has contributed a package for Arch Linux i686.

IF, REPEAT, WHILE

The preferred syntax for "if", "repeat" and "while" phrases has been changed
	to a Python-style format using colons ":" and indentation to mark that
	lines in the definition of a phrase or rule are being grouped together.
	This implements most of proposal (6.22) from the January 2007 consultation
	document. For instance, what was previously written thus:

		...
		if the actor is holding a player's holdall (called the sack)
		begin;
			let the transferred item be nothing;
			repeat with the possible item running through things carried by
			the actor begin;
				if the possible item is not lit and the possible item is not
				the sack, let the transferred item be the possible item;
			end repeat;
			...
		end if;

	can now be written thus:

		...
		if the actor is holding a player's holdall (called the sack):
			let the transferred item be nothing;
			repeat with the possible item running through things carried by
			the actor:
				if the possible item is not lit and the possible item is not
				the sack, let the transferred item be the possible item;
			...

	We believe this is more consistent with the shape of definitions as a
	whole, which also take the form "preamble: item 1; item 2; ..." It also
	seems much closer to how books or newspapers represent lists of instructions
	or recipes, for instance.
The new syntax is now used in Inform's documentation and examples. We think
	it's clearer and more logical, though groups of the kind shown above are
	surprisingly uncommon in I7 source text, because so much which would need a
	loop in another programming language is done implicitly in I7. (There are
	fewer than 600 grouped phrases in the entire Inform documentation, an
	average of only 1.5 per example.) But the new syntax is _not_ compulsory.
	Each individual phrase or rule can be written to use either the old syntax
	or the new syntax (but not both in the course of the same definition).
	Thus, there is no need to change any existing source text - it will all
	compile exactly as before. Going over to the new syntax is entirely
	optional, and there is no intention at present to withdraw the old one.
A few notes about the arrangements:
	- A rule or phrase using "new" syntax is required to start each phrase
		of the definition on a new line. (But phrases are allowed to be
		longer than a single line, and can wrap in any way the author wants:
		see the "repeat with..." phrase above for an example.)
	- Indentation must be made with a sequence of tab characters; spaces are
		ignored (as they already are with table columns).
	- Indentation must begin on tab stop 1, i.e., one tab stop in from the
		left margin, and must advance by a single tab stop for each block
		which begins after an "if", "repeat" or "while".
	- Indentation must not exceed 9 tab stops.
	- An "otherwise" or "otherwise if ..." clause in an "if" should be
		given the same indentation as the "if" it belongs to. For instance,
			if the yellow door is open:
				now the duckling is happy;
			otherwise if the red door is open:
				now the duckling is sad;
			otherwise:
				now the duckling is ambivalent.
A new form of "if" provides a form of switch statement: this is only allowed
	in the "new" syntax above. For example:
		if N is:
			-- 1: say "1.";
			-- 2: say "2.";
			-- otherwise: say "Else.";
		if the dangerous item is:
			-- the electric hairbrush:
				say "Mind your head.";
			-- the silver spoon:
				say "Steer clear of the cutlery drawer."
	This implements proposal (6.22c) from the January 2007 consultation
	document, though with slightly different punctuation syntax.
Finally on "if": in every form except that last one, "unless" can now be used
	in place of "if" and with the same effect except that the sense of the
	condition is reversed. For instance:
		unless N is 3, say "N is not 3.";
		unless the yellow door is open:
			now the duckling is happy;
		otherwise unless the red door is locked:
			now the duckling is sad;
		otherwise:
			say "The yellow door is closed and the red one unlocked.";
	If written in old-style syntax, "unless" should be ended with "end unless",
	not "end if".
	This implements proposal (6.24) from the January 2007 consultation document.
Inside "repeat" and "while" loops, the new phrases "next" and "break" can
	be used to go directly to the next iteration, and to exit the loop
	immediately, respectively. ("Next" is called "continue" in a fair
	number of programming languages, and Inform issues a specific problem
	message to help people who forget this.) Thus:
		repeat with X running from 1 to 10:
			if X is 4, next;
			say "[X] ";
			if X is 7, break;
	prints the text "1 2 3 5 6 7".
	This implements proposal (6.23) from the January 2007 consultation document.
The text substitution "[unless ...]" means the same as "[if ...]" but with
	the sense reversed, paralleling the use of "unless" and "if" as phrases.
The text substitutions "[otherwise]" and "[otherwise if...]", for use within
	"[if]...[end if]", can now be written "[else]" and "[else if...]": this
	is to be consistent, since "otherwise" can be written "else" in regular
	code too.

UNDERSTANDING

When an item or room is created, Inform automatically makes its name something
	the player can type to refer to it. For instance,
		The Wabe is a room. The blue peacock and the sundial are in the Wabe.
	means that the player can type EXAMINE BLUE PEACOCK or PUSH SUNDIAL or
	SHOWME WABE, and so on. This is almost always a good thing, but a nuisance
	if something's true identity is not known to the player. So:
		The secret document is a privately-named thing in the drawer.
		The printed name of the secret document is "[if the secret document is
			handled]secret document[otherwise]dusty paper".
		Understand "dusty" and "paper" as the secret document.
		Understand "secret" and "document" as the secret document when the
			secret document is handled.
		After taking the secret document for the first time: say "Heavens! It
			is the secret document!"

	...uses the new property "privately-named" to make the secret document
	something whose name is only what Understand... explicitly says: the name
	it happens to have in the source text is ignored. (Privately-named is
	a property which affects how Inform creates the object, and it can't be
	given or taken away during play.)
When a kind is created, and the source text constructs multiple duplicate items
	of that kind, Inform generates a plural of the kind's name in order to
	understand commands referring to these multiples. For instance, given...
		The Lake is a room. A duck is a kind of animal. Four ducks are in
		the Lake.
	...the player can type TAKE DUCKS to try to pick up all four.
	It is now also possible to teach Inform new plural forms of name. For
	instance:
		Understand "birds" and "ruddy ducks" as the plural of duck.
	Now TAKE BIRDS and TAKE DUCKS are equivalent. Plurals can even, strange
	as it may seem, be given for single things:
		The magpie is in the Lake. Understand "birds" as the plural of the
		magpie.
	Now TAKE BIRDS tries to take all four ducks and the magpie too.
	This implements proposal (6.49) from the January 2007 consultation document.
When Inform receives a command like TAKE ALL, it forms up a list of the
	eligible objects and then generates actions for each in turn. This can
	now be inspected and changed. For instance,
		let L be the multiple object list;
	sets L to this list. (If there is no multiple object, say if the command
	was TAKE PEAR, the list will be empty: it won't be a list of size 1.)
	Correspondingly, we can set it:
		alter the multiple object list to L;
	Of course if Inform is already working through the actions, it is too
	late cleanly to change this list, but the following...
		The magic rule is listed before the generate action rule in the turn
		sequence rules.
		A thing has a number called dramatic potential.
		This is the magic rule:
			let L be the multiple object list;
			if the number of entries in L is greater than 1:
				sort L in dramatic potential order;
				alter the multiple object list to L.
	...does a little rearrangement after the parser has finished but before
	actions have started to be generated.
The meaning of the phrase
		place X in scope
	used to depend on whether X was a room or not: for rooms, only the
	contents would be put in scope, and not X itself. This meant there
	was no way to put the actual names of rooms in scope, and was in any
	case an unnecessary complication. As from this build, the following
	possibilities:
		place X in scope
		place X in scope, but not its contents
		place the contents of X in scope
	do what they appear to suggest, whether X is a room or not. (If X is
	a room, the new "place the contents of X in scope" does exactly what
	the old "place X in scope" did, so it should be easy to correct existing
	source text if necessary - but e.g. in the Inform examples we didn't
	need to make any corrections at all.)
The "printing a parser error" activity can now override a further parser error,
	like so:
		Rule for printing a parser error when parser error is noun did not
			make sense in that context:
			say "If you must use 'any thing', you deserve all you get." instead.
	This error message appears only when an "[any ...]" token failing is the
	most interesting error the parser can generate, and several users have
	noticed that up to now there's been no way to rephrase it.

TABLES

Tables can now have amendments as well as continuations. That is, just as
	one can already write
		Table of Semi-Precious Minerals (continued)
	to add extra rows to an existing table, one can now also write:
		Table of Semi-Precious Minerals (amended)
	to change those rows. The amended table must have exactly the columns
	of the original and in the same order. Moreover, each row in the amended
	table must match exactly one row in the original. For instance:

		Table of Plans
		moment		outcome
		10 AM		"takeover of Mars"
		11:30 AM	"canals reflooded"
		11:45 AM	"chocolate bar production doubled"

		Table of Plans (amended)
		moment		outcome
		11:45 AM	"volcanic cave production doubled"

	creates a three-row Table of Plans, with reference to the chocolate bars
	struck out.
	Amendment rows may be given in any order.
	The process of matching a row begins at the left-most column: Inform
	tries to see if any single row in the original table has a matching
	entry. If none do, a Problem is issued. If more than one do, Inform then
	looks at the second column, and so on. Thus:

		Enthusiasm is a kind of value. The enthusiasms are pumped, wired and languid.

		Table of Mental States
		feeling	extent	consequence
		pumped	1		"you feel able to run for your life"
		pumped	2		"you feel able to run for President"
		wired	1		"you feel able to run"
		languid	1		"you feel"

		Table of Mental States (amended)
		feeling	extent	consequence
		pumped	2		"you feel able to run for the Nebraska State Legislature"

	...the amendment here is made to the second row of the original table.
	For the present, at least, the columns used for matching may only contain:
	numbers, times, objects, action names, activities, figure names, sound
	names, truth states and any new kinds of value or units which have been
	declared.

FAST ROUTE-FINDING

The ability to find routes through the map, and other relations, makes it
	possible to write quite sophisticated conditions concisely: but these
	sometimes run slowly, because they call for large amounts of computation.
	Two especially bad cases are provided by having dozens of characters
	constantly route-finding through the map in order to meander about;
	and having dozens of articles of clothing all partially revealing each
	other, overlying and underlying, so that it becomes a complicated
	matter to establish what can be worn on top of what else.
For finding routes in the map, there are now two use options:
		Use fast route-finding.
		Use slow route-finding.
	This chooses between two algorithms, neither of which is best in all
	cases. If neither is specified, "fast" is used on the Glulx VM, and
	"slow" on the Z-machine. In general, "fast" is very much faster if there
	is a large map in which frequent route-finding goes on; but it comes at
	a sufficient memory cost that, for a large map, it won't be able to
	fit into the Z-machine, which is very short of memory. On Glulx projects,
	memory is only an issue if we mind that the story file and saved games
	will be a little larger, which could just possibly matter for very small
	mobile devices. "Slow" is the same algorithm used in previous builds of
	Inform, and it has very low memory overheads: for many maps, especially
	fairly small ones, and where route-finding is only an occasional need,
	it is not detectably slower than "fast".
	(For those interested, "slow" is a variation on Prim's minimal spanning
	tree algorithm, while "fast" is a form of the Floyd-Warshall algorithm.)
For finding routes through relations, the same two options are available,
	but because we tend to create many relations which never use route-finding
	the default is always "slow". To make route-finding for a given relation
	"fast", we have to declare it that way:
		Overlying relates various garments to various garments with
		fast route-finding.
		Overlapping relates various garments to each other with fast
		route-finding.
	(For instance, changing the "overlying" and "underlying" relations in the
	example "What Not To Wear" to "fast" enormously improves performance when
	there are large wardrobes to choose from.)
	The "with fast route-finding" note can only be added to various-to-various
	relations: although route-finding through various-to-one and one-to-various
	relations is fully supported, it exploits the relative simplicity of these
	problems to use a more efficient algorithm than either the "fast" or "slow"
	ones described above.

EXTENSIONS

Up to now, extensions have had filenames without a dot "." followed by trailing
	text identifying their file type (i.e., without a "filename extension",
	to use a completely different meaning of the word). There are some merits
	to this, but the demerits have won out. Inform now recognises the suffix
	".i7x" (read: "I7 extension") for these filenames, and we will gradually
	move to this form for files downloaded from the website.
Headings can now provide source text to be used if a given extension is
	included in the current run; or alternatively, if it isn't. For instance:
		Chapter 2a (for use with Locksmith by Emily Short)
	specifies that everything under this heading (and its subheadings, if any)
	will be ignored unless the extension Locksmith by Emily Short is included.
	Conversely,
		Chapter 2b (for use without Locksmith by Emily Short)
	will be ignored unless it isn't included.
	This allows extension writers to give variant implementations depending
	on what other extensions are in use.
Headings can also replace portions of extensions which have been included.
	For instance:
		Section 6 - Hacked locking (in place of Section 1 - Regular locking in
			Locksmith by Emily Short)
	places the source text under the new heading in the place of the old
	(which is thrown away). If there should be two or more headings of the
	same name in the given extension, the first is the one replaced;
	if two or more headings attempt to replace the same heading in the
	given extension, the final attempt in source text order is the one
	which succeeds; and finally, heading dependencies like the above are
	scanned in a top-down way. Thus, if we have
		Chapter 2a (for use with Locksmith by Emily Short)
		...
		Section 1 - Hacked marbles (in place of Section 4 in Marbles by Peter Wong)
		...
	and we don't include Locksmith, then the replacement of Section 4 of
	Marbles is not made, because Section 1 - Hacked marbles is subordinate
	to the Chapter 2a heading which we've told Inform to ignore.
The extensions machinery has been made more robust, fixing a number of
	obscure bugs not actually experienced in practice by any users, and
	changing existing conventions as follows:
- It is now possible for an extension to contain accented characters
	in author name and title: thus,
		Include Étude Pour La Fênetre by Françoise Gauß.
	should work. (Accents are removed for console output; the file of
	the extension must have the actual name it claims, as with any other
	extension.)
- The word "and" is permitted in the title of an extension.
- The maximum lengths of extension title and author name, previously
	31 characters each, have been raised to 50 characters each: but these
	are now more rigorously checked. (Previously, an extension breaking
	these limits would work on some platforms but not others: it would
	produce installation error messages on the Extensions documentation
	page, but these were easy to overlook by accident. An extension with
	overlong title or author name will now produce a Problem message when
	included.)
- It is now possible to give an optional line of additional credits for an
	extension, so that collaborators or earlier versions can get a name-check.
	For instance:

		Version 1 of Banana and Mango Peeling by Jesse McGrew begins here.

		"Allows banana splits."

		"based on War and Peace by Leo Tolstoy, translated by Donald Rumsfeld"

	This last paragraph is the optional extra, which we suggest can be used
	in cases where, for instance, old I6 code has been wrapped up in new
	form - this is where to say who wrote the original.
- Installation errors are now more prominently displayed on the
	Extensions documentation page.
- Problem messages added and improved for checking that 'begins here' and
	'ends here' sentences for extensions being used are correct. (Checking
	of 'ends here' sentences, in particular, was very lax previously because
	of a bug in the extension manager: apologies for this, because it means
	there are now a few extensions in circulation which have improperly
	written 'ends here' sentences, but which are otherwise correct, and
	will now be rejected. But the corrections needed will be very simple.)

MINOR NEW FEATURES

It is now possible to define two different versions of the same text
	substitution, one in which the first letter is capitalised, the other
	in which it is lower case: these then have different meanings. (Inform
	already did this where the first word was The, A or An, and used this
	so that "[the noun]" had a different effect from "[The noun]": what
	is new is that the same rule now applies to any first word.)
When lists of objects are printed with the text substitution "[list of ...]"
	(for instance, "[list of open containers]") such lists are now always
	grouped and printed using plurals. (In previous builds, they would be
	if the objects involved were all inside or on top of a given parent
	object, but not otherwise. It's arguable that this is a bug fix rather
	than a new feature.)
The substitution "[A list of ...]" now capitalises the first indefinite
	article in the list, just as "[The list of ...]" does for the first
	definite one. (This was something we forgot to implement, and the
	fact that it wasn't there was reported as a bug, but properly speaking
	it was a missing feature before and is a new one now.)
A backdrop can now be dynamically moved to any set of rooms. For instance,
	suppose rooms have the either/or property "wet", and that "stream" is a
	backdrop. Then -
		When play begins:
			move the stream backdrop to all wet rooms.
	- sets the stream to be present in any wet room, and of course absent in
	any dry one. The form of words:
			move the ... backdrop to all ...
	is deliberately meant to look unlike the simpler ways to move things, to
	emphasise that this is possible only for backdrops.
	The stream's position is ordinarily checked only after movements, for
	efficiency's sake. So if the player is in a room which suddenly changes from
	dry to wet, the stream will not magically appear (though it will be there
	if the player goes out and comes in again). If this is not good enough,
	the phrase "update backdrop positions" can be used to ensure the accuracy
	of all backdrop locations after a dramatic change -
		Instead of pulling the lever:
			now the Cave is wet;
			remove the lever from play;
			update backdrop positions;
			say "The old rusty lever pulls away, and the thin cave wall goes
				with it, so that a stream bursts into the cave."
	This implements proposal (6.54) from the January 2007 consultation document.
When creating new verbs or prepositions, the word "reversed" can be used
	to reverse the sense of a relation. For instance,
		The verb to be embedded in implies the reverse incorporation relation.
The word "nothing" can now, in simple ways at least, be used in conditions
	to mean the non-existence of something. For instance -
		if nothing is in the box, say "Nothing is in the box.";
		if the box contains nothing, say "Nothing is in the box.";
	An exception is made for "is" alone, that is, for testing equality:
	otherwise
		if X is nothing, ...
	would mean "if there is no thing that is equal to X"
The verb "to incorporate" has been added to the built-in stock; that is, the
	following is now part of the Standard Rules:
		The verb to incorporate (he incorporates, they incorporate, he
		incorporated, it is incorporated, he is incorporating) implies the
		incorporation relation.
	Thus X incorporates Y if and only if Y is a part of X. It was slightly
	anomalous that no such built-in verb existed already (analogous to
	"to contain" and "to support"), and several extension-writers have
	found it a useful linguistic device and had to define it themselves.
A new activity "printing the announcement of light" has been added, in
	parallel with "printing the announcement of darkness".
The assertion-maker has been slightly improved, so that relative clauses
	like the one in the third sentence here work (rather than producing
	problem messages):
		A person can be asleep or awake. The Spinning Tower is a room.
		Sleeping Beauty is a woman who is asleep in the Spinning Tower.
Test scripts (for TEST) can now contain exotic characters, and follow
	the same apostrophe conventions as other text: thus ' becomes " except
	where used as a contraction, but ['] forces a genuine single quote.
On Glulx works only, the "emphasised" type style now has the style hints
	weight 0 and oblique 1 set automatically when Glulx starts up: the point
	of this is that I7 uses this style to implement the text substitution
	"[italic type]".
The new activity "printing a number of" activity allows customisation of the
	entries in lists which give a number of duplicate objects. For instance,
		Rule for printing a number of blocks when the listing group size is 3:
			say "all three blocks".
	In both this activity and also the existing "grouping together" activity,
	the number variable "listing group size" contains what it says.
	This implements proposal (6.44) from the January 2007 consultation document.
It has always been possible to test the (most recent) outcome of a scene, if
	it's a scene which has named possible endings, as here:
		Hindenburg Ride is a scene. Hindenburg Ride begins when play begins.
		Hindenburg Ride ends disastrously when a random chance of 1 in 7 succeeds.
	We can test what happened thus:
		if Hindenburg Ride ended disastrously, ...
	We can now also test what didn't happen:
		if Hindenburg Ride did not end disastrously, ...
	Note that this is true only when the scene has ended, but ended differently.
In the definition of a phrase which has options, the name of an option can
	be used as a condition: now, "not" followed by the name of an option
	can also be used as a condition, testing the obvious thing. Thus:
		To hunt the wumpus, fiendishly:
			if fiendishly, say "Hunting fiendishly.";
			if not fiendishly, say "Hunting normally."
	...prints one of these two texts, according to whether the "fiendishly"
	option is set, i.e., according to which of these is used:
		hunt the wumpus;
		hunt the wumpus, fiendishly;
The (+ ... +) construction for using I7 source text within an I7 inclusion
	(or within a template file - see below) now allows an adjective name
	to be given, and translates it to the name of the I6 routine testing
	that adjective.
A new feature so minor that with any luck nobody will notice or make use of
	it. I7 has a global variable called "the container in question", used
	in reaching inside and reaching outside rules to mean the barrier being
	reached through. A much nicer way to do this is:
		Rule for reaching inside a container (called the barrier): ...
	where one then calls it "barrier". The only reason that "the container
	in question" exists is because reaching rules go back to the very early
	days of I7, before the "called" mechanism exists. Well: the new feature
	is that a parallel "supporter in question" now also exists, because it's
	illogical to have the one without the other, and its absence was
	reported as a bug. But please don't use either.

EXAMPLES

Recipe Book:
	"Varying What Is Read" revised to account for many more types of parsing
		issue.
	Three new sections, "Designing New Commands", "Writing New Commands", and
		"Modifying Existing Commands" added at the beginning of the Commands
		chapter. These are meant to help people find technical features
		scattered throughout Writing with Inform, and also to offer some
		design guidance. "Modifying Existing Commands" tries to avoid overlap
		with the guidelines in the Advanced Action chapter and instead exists
		to point readers to the resources there and also in the Activities
		and Rulebooks chapters.
	"Looking" substantially revised to reflect new behavior.
	"Actions on Multiple Objects" added to the Commands chapter.
	"The Flow of Conversation" added to the Other Characters chapter to offer
		some general guidance about drafting conversation.

Examples:
	Added "Escape from the Seraglio" to demonstrate a way to vary printing
		of text such as "grapes: ..." when acting on multiple items at once.
	Added "The Left Hand of Autumn" to demonstrate printing more
		sophisticated descriptions of multiple objects when all are examined at
		once.
	Added "Noisemaking" to demonstrate adding a new stage to action
		processing, during which other characters can observe and react to what
		the player has done.
	Added "Delicious, Delicious Rocks" to demonstrate adding a new stage to
		action processing, during which the player's action is sanity-checked
		before any implicit takes, etc., are generated.""
	Added "Provenance Unknown" to demonstrate how PUSH TELEVISION WEST might
		be converted to pushing the cart on which the television rests.
	Added "Low Light" to demonstrate an object that is visible and manipulable
		only when a bright light source is on.
	Added "Kiwi" to demonstrate a kind of shelf whose contents can only be seen
		if the player is standing on something.
	Added "Jamaica 1688" to demonstrate how to modify the final question of
		the game.
	Added "Trieste" added as a simple test and demonstration of table
		amendments.
	Added "Formicidae" added to demonstrate changing the order of the
		multiple object list.
	Added "WXPQ" added to demonstrate replacing the "That noun doesn't
		make sense in this context." parser error.
	Added "Copper River" added to demonstrate the idea of "interesting"
		and "dull" objects: the game determines which items are currently
		important to the puzzles or narrative and mentions those in the room
		description, while suppressing everything else.
	Added "Priority Lab" added to offer a sandbox for trying out priority
		ordering in room descriptions, and some debugging tools.
	Added "Casino Banal" added to demonstrate more advanced uses of
		priority ordering.
	Added "Zorb" to demonstrate making some changes to the circumstances in
		which the player can push objects between rooms.
	Added "Vouvray" to demonstrate plural names at the beginning of the Kinds
		chapter.
	Added "Prolegomena" to demonstrate the printing a number... activity.
	Added "Quiz Show" to demonstrate asking open-ended questions of the player,
		which can be answered only on the subsequent turn.
	Added "Orange Cones" to demonstrate moving backdrops to
		conditionally-specified rooms.

	Changes to "Alias", "Air Conditioning is Standard", "A Haughty Spirit",
		and "Dinner is Served" to reflect new strictness about properties
		such as enterable and transparent. (These were all effectively minor
		bugs that had previously gone unnoticed.)
	Changes to "What Not To Wear", to reflect new strictness and to make
		some running speed improvements. More speed improvements are necessary.
	Change to "Pink and Blue" so that it works under Glulx as well as on the
		Z-machine.
	"Second Oldest" corrected for a typo in the middle initial of Dennis Jerz.
	"Frizz" adjusted so that instead of laboriously putting the wet and dry
		glove rules into various rulebooks, it now more elegantly creates a
		"post-check" rulebook between the check and carry out phases, and
		relies on that.
	"Equipment List" modified to remove a bug in the divided-wide style of
		inventory listing.
	"Switch" modified to demonstrate an actual switch statement now that
		one is available (but still to show how the same thing can be
		accomplished with otherwise if... or with a table of alternates)
	Updated "Instant EXAMINE and LOOK" into a playable example, now called
		"Timeless", with modifications reflecting the new action sequence
		rules.
	"Patient Zero" revised to remove several bugs to do with exit
		descriptions and nondescript item listing.
	"DIAGNOSE command" converted to a complete, runnable example (now
		called "Red Cross").
	"Responding to questions starting with WHO, WHAT, etc." converted to a
		complete, runnable example (now called "Query")
	"Examining everything at once" converted to a complete, runnable
		example (now called "Beekeeper's Apprentice").
	"Hotel Stechelberg" converted to a complete, runnable example.
	"Replacing standard action report rules" converted to a complete,
		runnable example (now called "We").
	"Laura" slightly updated to mention the privately-named feature and to
		mention some of the more advanced parsing features that can be found
		in the Understanding chapter.
	"Puff of Orange Smoke" updated to use the privately-named feature.
	"Verbosity" edited to mention the syntax for checking current verbosity
		levels during play.
	"First Name Basis" adjusted to demonstrate plural names for a kind.
	Adjustments made to "Money for Nothing", "Bic", "Chronic Hinting
		Syndrome", "Dubai", "Patient Zero", "Bribery", "Search and
		Seizure", "Lakeside Living", "Lemonade", "Modern Conveniences",
		"Trying Taking Manhattan", "Rock Garden", "Otranto", "Savannah",
		"Stately Gardens", "Tilt 2", "Tilt 3", "Thirst 2", and "Noisy
		Cricket" to clean up code using "unless".

EXTENSIONS

"Standard Rules" advanced to version 2: see below.
"Locksmith" edited to make it easier to change the output text; version
	number advanced to 6.
"Plurality" advanced to version 6, and a bug fixed whereby is-are did not
	print the correct output in the case where the object was the player.

SOURCE PUBLICATION

Internally, Inform is written according to the "literate programming" dogma
	of Donald Knuth, which means that its programs are written in such a way
	that they can be both executed by computers and also read by human readers.
	We intend to publish the entire source (online) in the course of Inform's 15th
	anniversary year, 2008. The result is likely to make a roughly 2000pp book,
	though of course a reference book rather than something anyone will want
	to read cover to cover.
This build sees the first step, with publication on the Inform website of
	drafts of Appendices A and B - the Standard Rules (A) and the Template (B) -
	which between them contain the most interesting 600pp of the material
	for people interested in modifying the internal workings of Inform.

INTERNAL REFORMS

The Standard Rules have been revised throughout: they are now more logically
	constructed, easier to read and better presented (for instance, in the
	Phrasebook index, which has a slightly new look). They advance formally
	to version 2.
	While much altered internally, they are almost exactly the same from the
	user's point of view, except that:
	- The property "inventory listing" for things has been withdrawn.
	(A fossil from the days of Inform 6: in I7's more rule-oriented way of
	looking at things, gadgets like this one are more an obstruction than a
	help, and it was striking that not one of the hundreds of examples ever
	used this property. And users often found it misleading that the property
	didn't play well with the activity "printing the name of something".)
	- The either/or property "transparent/opaque" is now a property only of
	containers, not of all things. (It only ever had any effect for
	containers anyway, and for some things it makes no good sense - a
	transparent animal is perhaps a jellyfish, but a transparent man, in
	the non-metaphorical sense?)
	- The either/or property "enterable" is now a property only of containers
	and supporters. (Again, it did nothing for any other things before.)
	- An action which fails because the player is in darkness, and it needs
	light, is now deemed to fail the "basic visibility rule", not the "can't
	act in the dark rule". (This brings it into line with the "basic
	accessibility rule", which is given as the reason for failure when the
	actor cannot touch something which is required to be in reach.)
	- The somewhat vaguely named "non-player character action rule" is now
	called the "requested actions require persuasion rule".
	- Implicit taking has been reformed: in past builds, the implementation
	of the taking action looked as if implicit takes were unlike ordinary
	actions, but this wasn't really so. The action variable "thing implicitly
	taken" has been abolished, and so have the following three rules:
		standard set taking variables rule
		avoid unnecessary implicit taking rule
		don't report successful implicit takes rule
Four obscure variant syntaxes, intended primarily for use by the Standard
	Rules, have been combined into one. The following examples show the
	change:
		Open translates into Inform as open.
		--> The open property translates into I6 as "open".
		The I6 library object name of yourself is "selfobj".
		--> The yourself object translates into I6 as "selfobj".
		The adjust light rule corresponds to routine ADJUST_LIGHT_R.
		--> The adjust light rule translates into I6 as "ADJUST_LIGHT_R".
		Quitting the game is an action corresponding to Quit, out of world
		and applying to nothing.
		--> Quitting the game is an action, out of world and applying to nothing.
		The quitting the game action translates into I6 as "Quit".
	In addition, one can now write:
		The whatever variable translates into I6 as "whtvr".
	which was not previously possible to specify.
	Problem messages have been added to defend this combination verb
	better against malformed requests, though it is still intended only for
	low-level extensions.
	(As a result, "to correspond" is no longer reserved and people can
	define this as a verb of their own now; "to translate", of course, is
	still reserved. The "I6 library object name" property has been abolished.
	Old-style tabular action definitions, in terms of lists of I6 routine names,
	have also been withdrawn.)
I7 projects no longer use the old I6 library: for fifteen years now, every
	story file made by Inform has included "Parser.h", "VerbLib.h" and
	"Grammar.h", but no longer. This is not as momentous as it sounds.
	I7 began by using library 6/9, then adapted to 6/10 and 6/11, but it
	always required minor modifications, indicated the suffix "N": thus,
	the latest releases of I7 have used library 6/11N. This was intended
	for dual use by I6 and I7 projects, but I7's use of the library had
	become increasingly strained. In 5J39, library 6/11N contained around
	400 conditional compilations causing it to produce different code when
	used by I6 and I7: in some cases, drastically different. Almost half of
	the lines in 6/11N were ignored by I7, as were many of the concepts
	and features familiar to I6 users. It seemed to the authors that 6/11N
	was living a lie: it wasn't really the same library when used by both
	systems, and the continuing pretence was only making the code more and
	more baroque. Its form was only holding back further development.
	In this new build, the material from 6/11N which was still in use has
	been moved into the "template layer", where it joins the other I6
	code used by I7. This somewhat simplifies the I7 architecture.
	Library 6/11N is still included in the current build, for the benefit
	of anyone using it with purely I6 projects in the Inform 7 user
	interface.
	In any case much of the significant code in the I6 library lives on, almost
	unmodified, in a new home. "Parser.i6t" in the new template, for instance,
	is more or less the supposedly abandoned "parserm.h" from Library 6/11N.
The template layer consists of a set of about 35 mainly short files, or
	"segments", with the extension ".i6t". Each segment has a name and is
	divided up into one or more named parts.
	This has enabled the Include (- ... -) syntax for inserting raw I6 code
	to be considerably strengthened. For instance -
		Include (- ... -) before "Flowers.i6t".
		Include (- ... -) instead of "Flowers.i6t".
		Include (- ... -) after "Rhizomes" in "Flowers.i6t".
	With these new forms of Include, the given I6 code can be placed before,
	instead of, or after any named segment or named part of a segment.
	- Multiple such inclusions can be made for the same segment or part, and
	if so, all will take effect;
	- Inclusions requested before, or after, a segment or part which has been
	replaced with "instead of" will take effect and appear before or after
	the code which appears instead of it.
	- The existing but deprecated syntax
		Include (- ... -) before the library.
	has been withdrawn; the new syntax
		Include (- ... -) after "Definitions.i6t".
	should have the same effect.
	- The existing (and still fine!) syntax
		Include (- ... -).
	is, for what it's worth, equivalent to
		Include (- ... -) after "I6 Inclusions" in "Output.i6t".
	- Template code can now use the same (+ ... +) notation to evaluate I7
	expressions that inline definitions can; they also have access to a wide
	range of internal-use-only commands which shouldn't be used except in
	the built-in template files, but one command is safe to use:
		{-segment:NAME}
	places the whole of the template file NAME in this position. The file
	should be named as something like "MyStuff.i6t" -- it's a leafname, not
	a pathname -- and Inform looks for template files first in the subfolder
	"I6T" of a project's "Materials" folder, if that exists, and only then
	in its built-in stock. This means that
		(a) you can if you wish replace the built-in templates with your
		own, putting those in Materials/I6T, and
		(b) you can if you wish include chunks of I6 code generated by
		external utilities - Perl scripts, lex and yacc, etc. - by compiling
		those to suitable template files in Materials/I6T and then using
		an inclusion like
			Include (- {-segment:MyStuff.i6t} -).
All this allows for fine control in modifying the template, though we hope
	that users won't go in for template modification much or often.
	The template layer is gradually being tidied up: an annotated version,
	explaining what each part does, will be published later this year. In
	the mean time, those who do hack the template are warned that they may
	need to alter their code to keep it working with future builds.
One application of template layer hacking might be to provide extensions
	which translate the language of play. At present, I7 is not configurable
	enough to translate the language of writing, but as from this build it
	should be much more viable to translate the language of the story file.
	To demonstrate this, a new extension, "English by David Fisher", is
	built in. This extension implements English, and there's no need for
	anyone to include it in their story files since English is already the
	language of play by default: but it serves as a model which translators
	can imitate. It should be fairly straightforward to convert existing
	I6 language definition files into extensions following this model.
	The authors suggest that these could be named in the style "Language
	by Translator's Name" - say, "Latin by Adam Thornton".

OPTIMISATION

We would like to thank Jesse McGrew for writing a profiling version of the
	Z-machine interpreter dumb-frotz: a great help. (It appears, incidentally,
	that if dumb-frotz has a 3GHz Xeon CPU core to itself, it can interpret
	at around 13.5 MHz; a just-in-time compiler can manage 19.7 MHz, probably
	the world speed record for the Z-machine. Realistically, when interpreting
	the Z-machine over the next couple of years, we can expect about 10 MHz,
	but we should divide by about five to get likely speeds on portable devices
	such as the iPhone, with CPUs at about 600 MHz.)
The running time of large rulebooks (with 16 or more rules) has been improved.
	The recent discussion on RAIF about before, instead or after rules being
	inefficient in large numbers - because these rulebooks become large -
	led us to investigate how large an effect this really was. The answer
	was that it wasn't as dramatic as some people had feared, but was well
	worth addressing: this shaved about 24% off the running time of "Bronze"
	played right through to a solution. (The representation of rulebooks is
	now such that there is very little or no possible speed advantage to moving
	a before/instead/after rule into the check/carry out/report rulebooks,
	so this shouldn't be a factor in deciding where to put rules in future.)
As of this build, activity rulebooks are "processed" rather than "followed".
	This means that they do not run the procedural rules individually as fresh
	contexts for rules in their own right: instead, they remain subject to
	procedural rules applying to whatever larger thing is going on -- i.e.,
	in almost all cases, the current action. This change made no difference
	to the behaviour of any test in the test suite, and removed a further
	16% from the running time of "Bronze". (The change will not so
	significantly affect projects which don't use procedural rules, of course.)
Miscellaneous other adjustments, such as replacing heavily-used veneer routines
	with hand-coded assembly language versions better aimed at likely I7 rather
	than I6 use cases, should save about 10% of running time on most projects.
At the end of this period of optimisation, "Bronze" ran about 2.5 times faster
	than at the start, but this was an extreme case: most examples saw more
	modest improvements.

MAINTENANCE

Inform has been made more sensitive to the casing of prepositions. So, for
	instance,
		if the location is In Hallway, ...
	will now check to see if "location" is the room "In Hallway", rather than
	taking "is in" to be a reference to containment, because the capital I is
	suspicious.
The "map region" property now exists for every room, even when there are no
	regions. (Its value is "nothing" if a room isn't in a region.) The point
	of this is to allow extensions which provide extra features for
	region-using works to compile. So, not quite a new feature, not quite a
	bug fix.
The ancient I6 library reply:
		> PUSH SUNDIAL EAST
		Is that the best you can think of?
	has been reworded:
		> PUSH SUNDIAL EAST
		The sundial cannot be pushed from place to place.
	(The original message has too much of a narrative tone, particularly for
	modern IF, and most authors prefer a more neutral message.)
Bug fixed whereby "if X can see Y" did not properly work if the player were
	in darkness. (Fixing this slightly changes the way we report a situation
	where the player is in an opaque container, without a light source, and
	asks someone outside the container to close it: we can now only witness
	that the container closes, and we don't actually see who closes it.)
Bug fixed whereby if two phrase definitions have identical wordings, it would
	be the earlier whose definition was applied, not the later. (It ought to
	be the later, firstly because the documentation says so, and secondly
	because this enables definitions in the Standard Rules to be overridden
	more easily - because the SR are always read earlier than anything else.)
Bug fixed whereby the rules [A] and [B] in the following would be regarded
	wrongly as being only equally specific:
		A flowerpot is a kind of thing. A flowerpot can be unbroken or broken.
		A Ming Vase is a kind of flowerpot. [Yes, I know, it isn't. Never mind.]
		Instead of attacking an unbroken flowerpot: ... [A]
		Instead of attacking an unbroken Ming Vase: ... [B]
	In fact, [B] is more specific and should therefore have priority over
	[A], because all Ming Vases are flowerpots but not vice versa, and this
	is now fixed.
Bug fixed whereby a skipped line for a paragraph break would in some
	circumstances be omitted between subsequent paragraphs in a room
	description.
Bug fixed whereby excessive skipped lines (two or three superfluous ones)
	would sometimes appear after out-of-world actions have reported.
Bug fixed whereby action, activity and rulebook variables could not be used
	as text substitutions when supplied to phrases with indexed text arguments.
Bug fixed whereby phrases with indexed text arguments would be unable to
	compile if they also required run-time disambiguation for other arguments,
	and would produce I6 errors instead.
Bug fixed whereby use of indexed text which used text substitutions, but
	didn't print on screen, would sometimes nevertheless cause incorrect
	paragraph spacing in what was printed next.
Bug fixed whereby constructing indexed text from other text, in a way which
	required use of text substitution, which itself needed to construct some
	indexed text, would produce garbled results.
Bug fixed whereby using "exactly matches the text" would behave the same as
	"matches the text", that is, would not check the "exactly" part: this
	worked for regular expression matching, but not for plain text matching,
	because we forgot to implement this case. (Sorry. Of course, "exactly
	matches the text" means the same as "is", so people probably weren't
	convenienced too much.)
Bug fixed whereby constant lists occurring in code, in works which otherwise
	contain no indexed texts, lists or stored actions, would fail to compile
	through I6.
Bug fixed whereby abstract use of "...is listed in..." in source text which
	contains no actual lists would fail to compile through I6.
Bug fixed whereby constant lists used in expressions other than assignments
	would not always have the correct contents.
Bug fixed whereby constant lists used to initialise a "list of objects" would
	fail if the objects in question had a specific kind made explicit by
	other assertions.
Bug fixed whereby constant lists of texts, when assigned to global variables,
	properties or table entries whose kind of value is "list of indexed text"
	rather than "list of text", would be incorrect.
Bug fixed whereby constant lists of lists of numbers, where some of the numbers
	were negative, would have garbled contents.
Bugs fixed whereby constant lists of text which included at least one text
	substitution in one of the texts would sometimes fail to compiled through
	I6, or else would produce odd results at run-time.
Run time problem added for attempts to use "entry N of L", where L is a list
	and N is an index out of range.
Bug fixed whereby changing a list to the empty list explicitly like so -
		now L is {};
	...would result in forgetting the kind of value stored in L if it were
	subsequently to be filled again, so that saying the contents might
	produce cryptic numbers instead of the proper values.
Bug fixed whereby
		if X is listed in {1, 2, 3}, say "Hello.";
	would be misparsed because the commas inside the braces would be confused
	with the one outside.
Bug fixed whereby a phrase to decide a list (or indexed text), but which
	depended on arguments requiring run-time type checking, would either fail
	to compile through I6 or (more rarely) produce bogus results.
Bug fixed whereby use of lists, indexed text, stored actions, "(called ...)",
	or certain other unusual constructions, would fail to compile through I6
	if they were made within "Definition:"s of adjectives or "when" conditions
	of relations or of "Understand ..." lines.
Bug fixed whereby variables could not be declared to have kind "list of K
	that varies", where K is a either a kind of object (e.g. "list of rooms")
	or a new kind of value.
Bug fixed whereby creating a kind called "link" would cause I6 errors.
Bug fixed whereby type-checking would incorrectly allow
		The secret word is a text which varies. The secret word is "xyzzy".
		Before consulting the book about the secret word: say "Magic!"
	...which should not be allowed because matching against variable text
	like this has to be done using indexed text, and can't be done by direct
	methods. (Type-checking did correctly allow this for constant text.)
Bug fixed whereby type-checking would fail to find the correct interpretation
	of a "try ..." action, where the action applied to a value and the value
	was in turn calculated arithmetically, e.g.
		try hanging around until the time of day plus 6 minutes;
	where "hanging around until" is an action applying to a time.
Bug fixed whereby type-checking would not properly be applied to relative
	clauses incorrectly applied to descriptions, so that
		repeat with X running through members of D who are male:
	would apparently work if D is a description that varies - but only because
	Inform is misreading "D who are male" as itself a description, which it
	isn't, because only a person can be male: a description can't.
Bug fixed whereby type-checking would not correctly interpret, e.g.,
		let the irrelevant fact be whether or not 1 is 3;
	as a new variable "irrelevant fact", and would instead overlay it on an
	existing one, the result being mayhem.
Bug fixed whereby a "your former self" person would sometimes be picked up
	by, for instance, repeats through all people or lists of people in cases
	where the source text specifies a particular person as the player-character,
	so that no "yourself" object ought to exist.
Bug fixed whereby the list-writer would not group together similar items
	into a numbered collection if they were people who were carrying things.
	Thus:
		A thug is a kind of person. A knife is a kind of thing.
		Every thug carries a knife. Five thugs are in the Alley.
	would report "You can see a thug, a thug, a thug, a thug and a thug here."
Bug fixed whereby the text substitution "[the player's command]" would have
	too few words to it during an "after reading a command" rule taking place
	after the parser has asked a question like "Which do you mean, ...?";
	and similarly where it would hold the word "again" or "g" rather than the
	command being repeated if the player had typed AGAIN or G.
Bug fixed whereby matching the player's command against a topic would sometimes
	give wrong answers at the start of play, or after a very short command in
	the previous turn.
Bug fixed whereby the parser will no longer say "You can only do that to
	something animate" if the supposedly animate object's name as typed
	wasn't recognised at all: it now says "You can't see any such thing."
	in the usual way. (This seems to have been a curiosity in I6 going back
	at least ten years.)
Bug fixed whereby an implicit take (by someone else) generated by a requested
	action would fail to be recognised as another form of request.
Bug fixed whereby an "instead" or sometimes also a "before" rule like this:
		Instead of an actor jumping: say "[The actor] prepares to leap."
	...would sometimes be applied before the persuasion rules had decided
	whether or not the actor in question would even try.
Bug fixed whereby a relation between two kinds of value which aren't objects
	would sometimes have its second term wrongly interpreted as an object
	just the same - for instance,
		Divisibility relates a number (called N) to a number (called M)
		when the remainder after dividing M by N is 0.
	- did not work because M was wrongly thought an object. It works now.
Bug fixed whereby conditions containing fairly elaborate double-negatives
	would sometimes fail to compile, producing I6 errors: for instance,
		if no hat is not enclosed by a person, ...
Bug fixed whereby run-time type checking was not properly defending relations
	between specific kinds of object, so that a condition would sometimes
	be misapplied to objects not of the that kind, resulting in spurious
	run-time problems (albeit only if the relation were being tested for
	objects to which it really doesn't apply).
Run-time problems added for attempts to remove the player from play (a logical
	impossibility) or to remove doors from play (which would make a mess of
	the map), and for attempts to change the player to someone who has been
	removed from play.
Bug fixed whereby, on Glulx, an attempt to expand the heap by dynamic memory
	allocation might fail if the current heap were completely full (i.e., with
	not even the smallest block of memory free): in some cases, a run-time
	hang would result.
Bug fixed whereby the count of how many turns over which a category of actions
	has been happening would sometimes be wrong if the action qualified only
	when a certain condition held, which did not hold at the start of the
	action but did hold at the end. For instance, suppose we have:
		A thing can be examined or unexamined.
		Carry out examining something: now the noun is examined.
		After examining an examined thing for the third turn: say "Not again!"
	If the player types EXAMINE BOX, never having done so before, then this
	does not qualify as "examining an examined thing": but previous builds
	would have counted it towards the three turns needed for the rule to fire
	because, at the very end of the action, the description "examining an
	examined thing" would indeed match, the box by then having acquired the
	"examined" property.
Bug fixed whereby the count of turns is not fooled by multiple actions in a
	single turn: suppose we have the rule
		Before taking for the third turn: say "Not again!"
	and suppose the player types TAKE ALL, picking up a dozen items. In
	previous builds, the rule would treat these as different turns, but now
	they are treated as the same turn.
Bug fixed whereby "when" clauses in the preambles of rules for actions were
	not always allowed to see the action variables for the actions they
	belonged to: e.g.,
		Check going when the room gone to is dark: ...
	would not compile even though "room gone to" is a variable belonging to
	the action "going", which owns the "check going" rulebook. A "when"
	clause for a rule can now see exactly the variables which the rule's
	definition can see.
Bug fixed whereby "asking ... to ..." actions would not work in rules which
	counted them: for instance,
		Instead of asking Daphne to take the snack for the second time: ...
	would never fire. It now does; note that the count is of the number of
	times the action has been requested. If Daphne first takes the snack
	on her own initiative, and then the player asks her, that doesn't fire
	the rule.
The count has further been reformed by ensuring that silent actions can
	never count towards the number of turns in such a rule; silent actions
	are never the main point of what is happening in a turn.
Bug fixed whereby "[one of]...[or]...[in random order]" would fail on the
	Z-machine if there were 13 or more alternatives, and could cause spurious
	programming errors on Glulx.
Bug fixed whereby making something a part of a door would in some cases cause
	a bogus problem message claiming to find two apparently unrelated sentences
	contradictory.
Bug fixed (or, arguably, specification clarified) so that when one thing makes
	another, and the new item derives its name from the old, then a "printed
	name" for the original is transferred to the new. For instance:
		An oak tree is a kind of thing. Some leaves are a kind of thing.
		Some leaves are part of every oak tree.
		The printed name of an oak tree is usually "a mighty oak".
		Oak1 is an oak tree in Stage.
	...now results in leaves called "a mighty oak's leaves", not "Oak1's leaves",
	because the printed name "a mighty oak" transfers from Oak1.
Bug fixed whereby if a character were asked to do something with multiple
	objects (say with the command HELEN, GET ALL) then it would be assumed
	that agreement to perform the action with the first item would extend
	to the rest of the list, too. Persuasion rules are now properly checked
	for each item in the list in turn.
Bug fixed whereby rules predicated on a list of two or more actions, where
	an action name before the last could be read as both a complete action
	name and also an abbreviation for a different one, would have both
	interpretations applied instead of only the complete one: for example,
	if actions called "franking" and "franking it with" both existed, then
	"Instead of franking or taking" would be misread as applying to any of
	the "franking", "franking it with" or "taking" actions - whereas
	"Instead of franking" and "Instead of taking or franking" would not
	be misread in this way.
Bug fixed whereby the "in" would be misinterpreted if it occurred in the
	name of a rule being explicitly placed in a rulebook, as here:
		The new can't travel in what's not a vehicle rule is listed instead
		of the can't travel in what's not a vehicle rule in the check
		going rules.
Bug fixed whereby some extension namespace clashes would fail to be
	reported correctly on the dictionary page where three or more
	different extensions all defined the same term.
Bugs fixed whereby names with exotic ingredients such as ~, ^, @ would
	either be misprinted or misparsed, or both.
Bug fixed whereby a "Definition:" would fail with an internal error if
	applied to just an "object" rather than a named kind such as "thing".
	For instance -
		Definition: An object is weaponlike if it is the knife.
Bug fixed whereby "now X is P of Y", where X is a variable and P is a
	property whose kind is a unit with the same name, would sometimes
	wrongly try to set P for X as well even when X is a variable of kind P
	rather than an object having P as a property. On the Z-machine this
	produced a spurious programming error; on Glulx, it sometimes crashed.
Bug fixed whereby asserting that a property is set to its own kind of value,
	rather than a specific value, would cause an internal error rather than
	produce a sensible problem message.
Bug fixed whereby the use of a specific named object combined with adjectives,
	in a context where only the object is expected, might cause an internal
	error rather than issue a problem message.
Bug fixed whereby paragraph breaks in the middle of phrase definitions
	would sometimes incorrectly be allowed, if the material just before
	the paragraph break ended in a semicolon.
Bug fixed whereby the "does the player mean" rules did not properly work for
	requests made by the player for other people to do things.
Bug fixed whereby making an assertion about a form of named construction
	(a type which is not a kind of value) would cause an internal error.
	For instance,
		A condition is usually true.
Bug fixed whereby a "when" condition in a relation which makes a calling
	so as to refer to an earlier result to decide a later one, would produce
	I6 errors and fail to compile.
Bugs fixed, or really, syntax clarified as to when qualifiers such as
	"always" and "usually" can be used in assertions: these are allowed
	on either side of the verb in most assertions, but not on both (for
	which a problem message has been added), and not in assertions
	admitting no doubt (such as "Looking is an action applying to nothing").
	Previously Inform would silently allow, though ignore, some such
	usages.
Similarly, "worn", "carried" and "here" can now only be used in assertions
	using the verb "to be".
Similarly, "of", "from" and "and" now lose their grammatical meanings as
	introducers of clauses in assertions if they are unexpectedly written
	with an upper-case O, F or A, respectively. Thus
		On the shelf is Of Mice And Men and The Girl From Ipanema.
	places two objects on the shelf, with the obvious names, and doesn't
	get sidetracked into thinking the shelf contains (for instance) an
	item called "Of Mice" together with some "men".
Bug fixed whereby optional clauses matched against action variables would
	sometimes not work for actions which apply to nothing. For instance,
		The jumping action has an object called the situation (matched as "at").
		Instead of jumping at the Place, ...
	was not being recognised.
Bug fixed whereby a rule like
	Check taking: say "You can't, because [if Fred is visible]Fred might
		see.[otherwise]I say so." instead.
	...might only halt the action, as the "instead" implies, if the
	"otherwise" branch is taken through the text.
Bug fixed - well, anyway, sensitivity improved - so that when a kind of value
	is defined with a table, the names of the possible values in column 1
	are no longer so likely to cause namespace clashes with things or rooms
	defined elsewhere.
Bug fixed whereby when a table is used to define a kind of value or a set of
	objects, a bracketed kind of value declaration in a table column name
	would not be recognised. (For instance, if a table column is headed
	"alpha (number)" then the name is "alpha" and the values have to be
	numbers.)
Bug fixed whereby properties which are defined by column names in tables used
	to define objects (or values), for which the entry in row 1 happens to be
	text which has substitutions, would then only allow other texts with
	substitutions as values - not plain text.
Bug fixed whereby giving a value as "object" in a table used to define objects
	would result in peculiar problem messages at best, and an internal error
	at worst.
Bug fixed to do with writing tables containing numbers to files in projects
	using Glulx.
Bug fixed whereby conditions based on actions would sometimes fail to compile
	with I6 errors if the actions involved items or people which were
	specified by local ("let" or "called") or global variables rather than
	named explicitly.
Bug fixed whereby declared plurals (with "The plural of ... is ...") would
	only sometimes be used by room descriptions.
Bug fixed whereby, contrary to the claim in Inform's problem messages, a
	Table could not be created which was named with a number alone ("Table 6").
Bug fixed whereby, if a room or thing existed whose name included a number
	(say, "Room 101"), then
		now X is a random number between 1 and 101;
	would sometimes be rejected as a compound condition for "now", because
	the "and" had been misinterpreted.
Bug fixed whereby extension documentation would sometimes mis-space braces
	"{" and "}".
Story files running on Glulx interpreters now properly check the "unicode"
	gestalt before trying to use Unicode character printing: such checks will
	only fail on old and now deprecated interpreters.
Bug fixed whereby the Phrasebook index would be garbled if words in the
	lexicon includes the characters "<" or ">".
Bug fixed whereby names containing "from" would sometimes have their original
	articles taken as part of the name itself: for instance,
		The telegram from Klaxor is in the Breakfast Nook.
	would produce a proper noun, "The telegram from Klaxor", rather than
	parsing it as "the" (definite article) + "telegram from Klaxor". (That
	this bug was not more widely felt is chiefly because another mechanism
	in Inform tended to compensate for it.)
Bug fixed whereby "called" names were sometimes unable to contain the words
	"with" or "having": for instance, this failed -
		The golf ball is in a container called the flask and cap with flange.
Bug fixed whereby consecutive articles would on rare occasions be allowed
	in noun phrases ("a the tree", say).
Bug fixed whereby RESTORE would not always work as a reply to the final
	question ("Would you like to RESTART, RESTORE a saved game or QUIT?").
Problem message added, in place of a disastrous compiler hang (apologies), for
	the incorrect syntax
		if one person (called the dude - a person) is in Home, ...
	where the user thinks he has to give the kind of value for "dude" - which
	he doesn't and indeed can't, since it's necessarily the kind of value of
	the person in question.
Problem message added to pick up mistakes when people type sentences like
		Jumping when the actor is on the trampoline is high-jumping.
	which don't do what they expect (the only legal reading of this asks
	to put an object called "jumping when the actor" on top of another one
	called "trampoline is high-jumping", and it seems unlikely that this
	is what the writer intended).
Problem message added to catch maps which have more than two rooms connecting
	to a two-sided door. (There was already a problem to catch a door connecting
	to more than two rooms.)
Problem message added (in place of I6 error) for use of "otherwise if..."
	after the "otherwise" clause in an "if".
Problem message added to catch "if ..., repeat ... begin;" where the "begin"
	is ambiguous as to which of "if" and "repeat" it belongs to.
Problem message added (in place of I6 error) for too many 'Understand "verb ..."
	as...' sentences for the same "verb".
Problem message added to catch attempts to create "topics that vary", a form
	of global variable that isn't allowed.
Problem message added (in place of internal error) for writing "[a topic]" as
	a grammar token, in I6 style, instead of "[text]", the I7 way to do the
	same thing; and similarly for "[an object]" instead of "[thing]".
Problem message added (in place of internal error) to catch certain
	complicated and completely wrong ways to define relations.
Problem message added (in place of internal error) for writing a rule based
	on an action applying to a value, where the name of the kind of value is
	written instead of a specific value.
Problem message added to catch attempts to make impossibly unspecific
	requests using cardinality quantifiers with now: "now almost all of the
	doors are open", "now six things are edible", and so on.
Problem message added for creating a property name consisting only of the
	word "presence" (since this causes ambiguities with "...in the presence
	of...").
Problem message added for using "if V is a C listed in T", where V is a value,
	C is a column in a table T, and unfortunately V is of a kind incompatible
	with the contents of C - for instance, a number when C holds only text.
Problem message added for creating constant lists of values where the lists
	aren't recognised because one or more of the entries doesn't make sense.
Problem message added to catch contradictory declarations like:
		Eleven is a 10 that varies.
Problem message added to catch attempts to use punctuation characters in
	Understand ... sentences which can't be matched by the parser anyway,
	so that the sentences appear to the user to be being ignored.
Problem message added to catch bizarre sentences like
		5 is an activity.
	(Or rather, to give them one problem message and not a cascade.)
Last and thoroughly least, but in response to a genuine bug report form,
	code added to protect NI from the "Year 2038" bug. This is the point
	at which 32-bit integer representations of time in non-leap-seconds since
	January 1 1970 begin to overflow. NI itself handles time correctly, but it
	uses C library calls on all its platforms which follow Unix conventions
	(including on Windows), which means they behave incorrectly on computers
	whose system clock is set to later than 2038. Work progresses but there is
	as yet no agreed solution to the Year 2038 bug. When there is, we will
	recompile NI against the improved C libraries then existing. In the mean
	time, users are advised to avoid time travel beyond 18 January 2038.

§11.5. What was new in build 5J39 (December 2007)

As this release was being prepared, the American footballer Antonio Cromartie scored a touchdown with a continuous run of 109.88 yards, a league record unlikely ever to be broken on a pitch 110 yards long; the UK government burned two CDs with unencrypted bank details for every family with children, put them into the unregistered post, and then panicked when they never arrived; a pilot project in Fairfield, Texas, began converting carbon emissions from a power station into (edible) baking soda; there were wildfires in Malibu, floods in Tabasco and Rift Valley Fever in the Rift Valley; and a cruise liner struck an iceberg in the Antarctic and sank, but everyone was saved.

In the world of Inform, build 5J39 introduced lists as first-class values. For any kind of value K, "list of K" was now also a kind of value, and rich support was provided for building and iterating over lists, dynamically resized as necessary.

5J39 (1 December 2007)

This build introduces lists as first-class values. For any kind of value K,
"list of K" is now also a kind of value, and rich support is provided for
building and iterating over lists, which are dynamically resized as
necessary. Otherwise little is new, but once again all known bugs have
been fixed.

For any kind of value K, "list of K" is now also a kind of value. Lists
	resize automatically, can be iterated through, sorted, searched,
	reversed or rotated, and they have a notation enabling constant lists
	to be written down concisely: for instance,
		let L be {2, 3, 5, 7, 11};
	gives the temporary variable L the kind of value "list of numbers",
	and sets it initially to this sequence of five values, whereas
		let M be the list of open doors;
	gives M the kind of value "list of objects", and sets its initial
	contents to be all the doors which are currently open. (Lists can also
	be used in global variables, in properties, or table entries, and can
	include each other: "list of lists of numbers", say, is a kind of value.)
	Values can be added or removed at any point in a list; lists can be merged,
	or compared for differences; and examples are presented to show the
	use of lists as queues, stacks, rings, sets, arrays, and so forth.
	(All memory management is automatic and all bounds are automatically
	checked.) See the new Chapter 20 ("Lists").
Examples:
	"Eyes, Fingers, Toes" added to demonstrate a multi-number safe using
		lists to create a log of dialed numbers.
	"Robo 1" added to demonstrate a programmable robot that will replay the
		player's behavior.
	"Robo 2" added to demonstrate a robot that can learn multiple stored
		action scripts with command names determined by the player.
	"Rock Garden" reformatted to give the general material at the top.
	"The Fibonacci Sequence" added to demonstrate using lists as arrays.
	"I Didn't Come All The Way From Great Portland Street" added to
		demonstrate using lists as sets.
	"Lugubrious Pete's Delicatessen" added to demonstrate using lists as
		queues.
	"Sieve of Eratosthenes" added to demonstrate using lists as sieves.
	"Circle of Misery" added to demonstrate using lists as ring buffers.
	"Lanista 1" corrected to fix a truncated sentence in the commentary.
	"Leopard-skin" added to demonstrate a log of stored actions.
	"What Makes You Tick" added to demonstrate building a fishing rod from
		component parts.
	"Your Mother Doesn't Work Here" added to demonstrate using a list as a
		stack to plan character behavior.
The previous restriction whereby TEST scripts could not exceed 255 characters
	in length has been withdrawn. The new maximum is 9999 (a cap intended
	only to catch accidental runaway cases where the closing quote has been
	forgotten).
Problem message added to prevent the UNDO command being used in a TEST
	script (which can't safely be done since it undoes progress in the test
	itself), and also to prevent individual commands in TEST scripts from
	exceeding 100 characters (since the I6 library would choke on those).
Problem message improved for namespace clashes between variable names and
	descriptions.
Problem message added (in place of previous I6 errors) when a
	description of an action, used as a condition, refers both to the past
	and to values in the present (by means of "called").
Problem message improved for an ambiguity in rule premisses as between
	a description of an actor followed by an action, and an action name
	with no actor attached. (This arose in the case of "standing using ...",
	where "standing" had also been defined so as to describe certain people:
	was the action here "standing using", done by nobody in particular, or
	"using", done by a person matching "standing"?)
Bug fixed whereby pastes of Example text for examples including backslashes
	(such as those arising from the introduction of regular expression
	matching) and, in some cases, other unusual characters would cause
	the text to be pasted incomplete - so that it did not work as it
	was claimed to do.
Bug fixed whereby two or more consecutive double-quoted texts in a single
	table entry would lead to an internal error rather than a problem
	message; something which can happen easily if pasted text converts
	tabs to spaces, when two adjacent table columns are both supposed to
	contain text.
Bug fixed whereby a rule whose premiss involved clauses of several different
	sorts, one of them "when", could sometimes produce an internal error.
Bug fixed - or, really, feature added, but the lack of it was regarded as
	peculiar - whereby an action description used in a rule was not allowed
	to give the name of a kind of value to mean "any value of this kind":
	for instance, "Instead of dialing something to a code symbol", where
	"code symbol" is a kind of value and "dialing it to" is an action
	applying to one thing and one code symbol.
Bug fixed whereby "[']" for apostrophe wasn't being allowed in titles given
	as the opening text of a bibliographic heading.
Bug fixed whereby indexed text and stored action variables were not working
	properly if they belonged to rulebooks, activities or actions.
Bug fixed whereby "if there is a [table-reference]" was not working in the
	case of columns holding indexed text.
Bug fixed whereby spurious "no such entry" run-time problems would occur if
	a table with a column holding indexed text was created with blank rows.
Bug fixed whereby ambiguous phrases requiring run-time checking on some
	arguments would sometimes go wrong if other arguments were stored
	actions or indexed text.
Bug fixed whereby if several "let" variables in a single phrase needed to
	be indexed text or stored actions, they would sometimes have their kinds
	of value rearranged between them, with occasionally bizarre results.
Bug fixed whereby the dynamic memory allocator would print up debugging
	information such as "1+128+256+512+1024+2048+4096+8192+16384+65536"
	after successfully allocating memory via Glulx's @malloc mechanism.
	Apologies for this.
Bug fixed whereby a compound phrase which looks as if it might be in the
	form "total ...", counting the total of some property - but which isn't -
	would generate an internal error rather than being rejected in favour
	of some other interpretation.
Bug fixed whereby a rule predicated on a condition about something being
	listed (or not) in a table would cause I6 errors.
Bug fixed whereby an internal error rather than a problem message would
	sometimes be issued when a condition was used which had no active verb
	but could be taken as a description of things (typically arising if
	"is" had been mistyped as "in").
Infelicity fixed whereby the problem message about minus signs being
	wrongly used in unit constants could be repeated (sometimes quite a
	few times) for the same mistake.
Problem message added (rather than I6 error or mysteriously incorrect
	behaviour) for the case of a phrase so ambiguous that at compile-time
	it is not possible to tell how many values it takes as arguments.
	The problem explains this, shows the phrases it cannot choose between,
	and invites the author to reword one of them.
Bug fixed whereby the old I6 debugging commands CHANGES and ROUTINES, which
	are no longer implemented in I7, still had their grammar visible in
	I7-compiled games, so that it was possible (but usually quickly fatal)
	to try using these commands.

§11.6. What was new in build 5G67 (November 2007)

As this release was being prepared, the 50th anniversary of Sputnik 1 was marked, while Japan's Selene satellite entered lunar orbit; miraculously, all three thousand men trapped underground in an Elandsrand gold mine were rescued; Jason Lewis completed a circumnavigation by bicycle, pedal boat and kayak; the Chicago Marathon ran to a photo finish; the US conceded that it had mistakenly kidnapped a German car salesman; squirrels were declared once again safe to eat in New Jersey; and Albus Dumbledore was outed by J. K. Rowling.

In the world of Inform, build 5G67 extended the range of values which can be handled to include truth states, indexed text and stored actions. Inform was made compatible with Apple's newly-released Mac OS X Leopard (10.5), including suitable QuickLook and Finder plugins for dynamic icons and cover flow showing the contents of ".inform" project bundles. Philip Chimento joined the Inform team as the author of the Gnome user interface for Linux, building on Adam Thornton's work with the underlying tools, and the first easy-to-install packages for Fedora and Ubuntu were made available. This "what's new" chapter was added to the documentation, and further work went into improving the Recipe Book with a view to making it easier to extract general solutions for general problems. All 110 open bug reports were closed: there are now once again no known issues.

5G67 (10 November 2007)

This build presents substantially richer support for handling text: for the
first time, arbitrary and manipulable strings of text are first-class values
in Inform. Substantial internal reforms, notably a new implementation of
the type-checker (now the third such), lead also to other improvements:
notably the ability to store and play back entire actions, and a form of
boolean type for the first time - "truth state". Finally, Inform is now
available for three new operating systems: Mac OS X Leopard (10.5), and
Fedora and Ubuntu Linux. We welcome Philip Chimento to the Inform team as
the author of the Gnome user interface for Linux.

MAC OS X

Mac OS 10.5 (Leopard) incompatibilities corrected; support added for
	QuickLook viewing of Inform projects, and for content-reflecting icons.
Bug fixed whereby replay and double-clicking in the skein sometimes failed to
	do anything.
Provisos such as "(for Glulx only)" are now removed from extension titles when
	making filenames for newly installed extensions.
The '+' button now works when adding Inform 6 extensions: in previous versions
	the only way to install a new Inform 6 extension was by dragging it to the
	window. Additionally, a bug has been fixed that was making it hard to
	add ORLib as a complete directory: in this new release it should be
	possible to just drag the ORLib directory to the Extensions pane and then
	use it by switching it on in the Settings tab of an Inform 6 project.
CocoaGlk 1.0.4 adopted, which includes a number of fixes:
	Fixed an issue that could cause a crash if a text grid window ends up with
		a negative size
	Fixed a problem that was causing games to crash under Leopard
	Various stream calls will now produce a warning when they are passed a NULL
		stream instead of crashing with an error. (The old behaviour was
		technically correct, but gwindows was passing in NULL streams quite often)
	Fixed an issue that was causing script files to be left empty until the
		user typed "script off"
Other minor changes:
	(I6 projects) "Add breakpoint" in the main menu now works in either pane
	Extensions are now displayed in alphabetical order
	The "Open Extensions" menu can now view built-in extensions
	Bug fixed whereby Glulx games were not saving transcripts correctly

WINDOWS

Fixed an intermittent crash in the I7 application, where it would stop
	with a dialog complaining about a "pure virtual function call".
	Thanks to Maryam Gousheh-Forgeot for helping track this problem
	down.
Added a headings menu to the source tab, following the similar menu on
	OS X. The menu initially shows the top-level headings in the
	source. Select a heading to go to it, or click on an arrow to
	see the sub-headings below that heading.

INDEXED TEXT

A new kind of value, "indexed text", exists to hold text which can be internally
	examined or changed. Ordinary text values are automatically converted to
	indexed text format when necessary. For instance,
		if character number 1 in "[score]" is "7", ...
	implicitly converts the text of the current score to indexed form, allowing
	it to be looked at character-by-character, and then examines the first
	character: so the test passes if the first digit of the score is a 7.
	Memory is dynamically allocated to allow for such manipulations in a way
	transparent to the user (and on the Glulx virtual machine 3.1.0 or better,
	Inform story files can allocate arbitrarily large memory heaps).
	See the new Chapter 19, "Advanced Text", in the documentation.
Indexed text can be accessed by character, word, line or paragraph, with
	further options to allow for punctuation; and we can search text to see
	if it contains any other text, and if so, how many times.
Moreover, indexed texts can be matched against regular expressions, with
	replacement also possible. For instance: if V is indexed text, then
		replace the regular expression "\d+" in V with "roughly \0"
	inserts the word "roughly" in front of any number in V. The regular
	expression language supported by Inform is essentially that of Perl
	(once multiline mode, a Perl eccentricity, and hooks to embedded Perl
	code have been removed) and Inform's algorithm has been verified against
	Perl's own compliance tests: see the notes in section 19.6 for details.
A particularly interesting text to manipulate is the command most recently
	typed by the player. Inform stores such text in a kind of value called a
	"snippet", and - like "text" - this automatically converts to indexed text
	when necessary. Moreover, rules in the "reading a command" activity are
	allowed to rewrite the text and reparse the command - for instance,
		After reading a command:
			let T be indexed text;
			let T be the player's command;
			replace the text "\p" in T with "";
			change the text of the player's command to T.
	removes any punctuation characters from what the player has typed.
Indexed text table columns can be written to, and read in from, external files.

STORED ACTION

A new kind of value, "stored action", holds actions - not action names,
	but fully-specified actions, including the information about who does what
	and with what. (The default value is the player waiting.) If V is any
	value of this kind, then
		try V
		try silently V
		silently try V
	all work in the obvious way. The phrase
		current action
	returns the action currently under way. Stored actions can do anything
	that actions can do: in particular, they remember, if necessary, the exact
	wording of the player's command at the time they were stored - so that
	actions like "looking up 'x100' in the code book" can be stored and tried
	later on. Stored actions can be used in "let" variables, in table columns,
	in global variables, and also in properties. See the new section 12.20
	in "Writing with Inform".
To make an explicit stored action, we use the form of words "action of ...":
	for example,
		The best idea yet is a stored action that varies.
		The best idea yet is the action of pushing the button.
When making comparisons, we can of course compare any two stored action values:
		let C be the current action;
		if C is the action of pushing the button, ...
	Although "action of ..." specifies an exact action, we can omit this if
	we want to write a vague description of an action instead - but only when
	writing it in a condition:
		if C is taking something, ...
		if C is doing something to the lever, ...
	(If we had written
		if C is the action of taking something, ...
	Inform would have thrown up a Problem, because "taking something" is not
	a single, definite action, so cannot be a stored action.)
The constituent parts of a stored action can be accessed with the phrases:
		action-name part of S
		noun part of S
		second noun part of S
		actor part of S
As a convenient abbreviation for testing these, the condition
		S involves X
	is true if the object X appears as any of the noun, second noun or actor
	in S, and false otherwise.
The "try" and "action of" constructions are now allowed to specify explicit
	text in place of a topic in actions such as asking. (Beginners to Inform
	often think this must be possible, but up to now it hasn't been, because
	of the difference between a snippet and a text, etc.) For instance,
		Instead of asking Biggles about "German flying machines":
			try asking Biggles about "aircraft".
The kind of value "action-name", used to denote not a complete action but
	simply what form of action it is ("taking", "throwing it at", etc.) can
	now be said for the first time.
The premiss for a rule about actions can now make use of variables which
	exist only inside action rules: for instance,
		Check an actor waving when the noun is not held by the actor: ...
	which was previously not allowed because the second mention of "the actor"
	referred to an action variable which, in a strict reading of the Inform
	syntax, existed only inside the rule (i.e., after the colon). This seemed
	an unnatural restriction.
The change log for build 4U65 claimed that:
		the can't go through concealed doors rule has been renamed the
		can't go through undescribed doors rule.
	This turns out to have been completely untrue. We meant to, but forgot.
	The name change has now been effected. (For the reason why, see 4U65.)
Lastly, either a bug fix or a redefinition, according to taste: an action
	description using "... in ..." refers to the room where the action is to
	happen; up to now this has always meant the room where the player is, but
	that went contrary to the principle that actions ought to treat people
	equally. "... in ..." clauses now refer to the room which is the actor's
	location. Thus
		Instead of an actor going east in the Vast Nothingness, ...
	now has effect if the actor tries this in the V. N., not if the player
	happens to be there at a time when the actor (who might be anywhere)
	tries going east. This sounds a complicated change, but it's clearly much
	more logical, and we doubt if anyone relied on the old behaviour.

OTHER CHANGES TO DO WITH KINDS OF VALUE

A new kind of value, "truth state", represents one of two possible values:
	the constants "true" and "false". (By default, truth state variables and
	properties are false.) We can convert any condition to a truth state thus:
		let victory be whether or not all the treasures are in the cabinet;
	We can then examine a truth state by comparing it against true or false:
		if victory is true, ...
	In fact, this kind of value is not new, but is merely coming out into the
	open. If we try to write (say)
		To decide what truth state is time is short: ...
	then Inform will tell us to rewrite it in the more traditional form:
		To decide if time is short: ...
	A phrase to decide if something-or-other is exactly the same thing as a
	phrase to decide a truth state, and indeed, if we want to then we can use
	"decide on T", where T is a truth state, in its definition. For instance:
		To decide if time is short:
			if the time of day is after 10 PM, decide on true;
			...
			decide on whether or not Jennifer is hurried.
	"Decide on true" is exactly equivalent to the more normally used "decide
	yes", and of course it is optional. The last line is more interesting
	since it effectively delegates the answer to another condition.
>--> The kind of value "object-based-rulebook" has been withdrawn: instead, such
	a value is now called an "object-based rulebook" and is a special case
	of a "rulebook". (The double hyphen was generally found to be clumsy, and
	often led to mistakes.)
The deprecated kind of value "string-of-text", which behaved identically to
	"text" in recent builds, has been withdrawn. It was mentioned in one
	example ("Panache") through a historical accident, but was otherwise
	undocumented.
A "let" variable can now optionally be created by giving its kind of value
	rather than its initial value - the initial value is then the default
	value for that kind. For instance,
		let T be an indexed text;
	creates a "let" variable called "T" to hold indexed text, and which is
	initially holding the blank text "".
A table column name can now optionally give its kind of value in brackets.
	Thus "darts tally (a number)" would create a column called "darts tally"
	whose contents were required to be numbers.
A phrase to decide a value is now checked to make sure that doesn't try to
	return a type which is not a value (something which typically produced
	problem messages in earlier builds, too, but less helpful ones).
Where a value property is declared for one kind of object as holding a value
	of kind of value X, and for another as holding kind of value Y, X and Y
	now have to agree: previously they were allowed to differ as long as they
	were each kinds of object, but this was not quite type-safe, and led to
	subtle bugs.
In previous builds of Inform, values of units had to be positive or zero:
	thus defining
		An elevation is a kind of value. 100 cubits specifies an elevation.
	creates a kind of value where -10 cubits, say, would not be a legal
	expression. Owing to a bug, however, no problem message was produced,
	and the minus sign was simply ignored - the value "-10 cubits" was read
	as if it were "10 cubits". This bug has been fixed, and a new convention
	adopted: if the initial specification of the unit is negative, then
	negative values are permitted, and otherwise not. Thus:
		An elevation is a kind of value. -100 cubits specifies an elevation.
	means that (say) "6 cubits" and "-3 cubits" are both legal.
When U is a numerical value - a number or a unit, that is - the phrase
	"random U from X to Y" now gives truer results for very large ranges
	in the Glulx virtual machine.
Bug fixed whereby "random U from X to Y" would sometimes seed the random
	number generator as a side-effect when X was greater than Y. This is now
	a symmetrical phrase - "a random number from 5 to 2" now has the same
	effect as "a random number from 2 to 5". (The phrase "seed the
	random-number generator with..." is the proper way to seed the RNG.)
If U is a unit, the phrases "random U", "U after X" and "U before X" have
	been withdrawn - these don't really make sense for unbounded ranges. (What
	is a random height? It's a question which can only be answered in context -
	a random height for buildings is quite unlike a random height for people.)
Problem message added to catch literal numbers (and literal units) which are
	too numerically large to fit into the Z-machine: for instance,
		An RGB value is a kind of value. 255-255-255 specifies an RGB value.
		Scarlet is an RGB value which varies. Scarlet is 255-0-0.
	...is fine in projects compiled for Glulx, but would overflow the
	16-bit word size on the Z-machine.
Bug fixed whereby nameless properties ("conditions" - not in the sense of
	"if", but in the sense of something being in good or bad condition, say)
	specified for kinds but only at the "usually" level of certainty would
	sometimes have such sentences ignored.
Problem message added for unit specifications which overlap or make ambiguous
	existing ways to write constant kinds of value; for instance,
		"250" specifies a weight.
	clearly clashes with Inform's existing notation for text.
Problem message added to catch the case of multiple initialisations of the
	same variable, for instance,
		Foobar is a number which varies. Foobar is 1. Foobar is 2.
Bug fixed whereby no problem was detected if a property required to hold one
	kind of object as a value (for instance, a property holding a room) was
	initialised by an assertion with another kind of object altogether (for
	instance, a container).
Bug fixed whereby spurious typechecking problems would be produced if the
	same kind of value was used both as a self-named property of one kind of
	thing, and also as the value of other-named properties of other kinds.
Bug fixed whereby conditions used for the start and end of a scene would not
	always be fully typechecked, if it appeared at least syntactically valid.
	For instance,
		Fairytale Wedding begins when the player is kissing the frog.
	looks superficially right, but in fact involves comparing an object
	(the player) with an action (kissing the frog) - something we may one day
	legalise in Inform, but which at present should be rejected. In builds
	before this one, it compiled but to a condition which was always false.
A number of subtle bugs have been fixed in handling ambiguous multiple-phrase
	text; if a phrase can be read as A or B, then A wins if
		- it has more fixed words;
		- they have the same number of fixed words, but A has more tokens;
		- taking fixed words alone, A is lexicographically earlier;
		- A is a subschema of B in the sense that each value of a token
		in B can be coerced to the corresponding kind of value in A;
		- A was created earlier than B in the source text;
		- fixed words of A occur earlier than B in the actual text parsed.
	In practice these changes cured some bugs, but did not change the
	interpretation of any text in the examples, and we expect they will
	probably not be noticed as changes by users. The final rule is notable
	for making phrases "right associative" when iterated, so for instance
		two minutes before three minutes before 12:00 AM
	is read as
		two minutes before (three minutes before 12:00 AM)
	rather than
		(two minutes before three minutes) before 12:00 AM
	and thus evaluates to 11:55 PM, not 11:59 PM.

MISCELLANEOUS OTHER CHANGES

>--> In order to reduce namespace clashes, a fairly significant change has
	been made to the way Inform reads noun phrases in the source text.
	Objects can, of course, be referred to using abbreviated names: for
	instance, if we write
		The Great Hall of Infinity is a room.
	then we can also write
		The Panjandrum is a man in the Hall.
	where "Hall" is a read as referring to the Great Hall of Infinity. This
	convention of course remains. However, the same is no longer allowed
	with names of kinds. Thus:
		A Scrabble piece is a kind of thing. The Q is a piece.
	will no longer work: the second assertion must be written out in full as
		The Q is a Scrabble piece.
	This led to tiny changes in six of the Examples (and detected a typo in
	a seventh), but in all cases the change was easily made and the result
	more legible or no worse than the original, so we hope that users will
	not find this change to the rules too inconvenient. The point of it is
	so that text such as:
		Beautiful scenery is a kind of thing. A wall is a kind of thing.
		A wall is usually scenery.
	will now work: previously the "scenery" in "A wall is usually scenery"
	was taken as referring to the "beautiful scenery" kind, not the built-in
	"scenery" property. (And so on for many other cases.)
>--> An ambiguity has been removed from the syntax for actions. The convention
	when indicating an action by a character other than the player is that
	the full form reads like so:
		Miss Hodges trying taking the lime
	Inform, however, allows the usually redundant word "trying" to be omitted
	where this leads to no ambiguity. The change is that, for safety's sake,
	Inform now forbids this abbreviation where the object's name includes
	a participle (or indeed any word ending in "...ing"). This prevents, for
	instance,
		Mr Geoffrey Taking
	from being read as an action rather than a noun phrase, or (a case which
	actually arose for one of our users)
		newspaper cutting
	being read as the newspaper itself doing some cutting.
>--> The accessibility rules have had one anomalous case removed. Previously,
	an object in another room was considered inaccessible, yet an object out
	of play was not. The only reason this rarely caused trouble was that
	actions involving such objects were seldom generated, because the parser's
	scope rules would prevent it from recognising commands referring to them.
	But it could occasionally happen, if a command such as TAKE ALL fired off
	a run of actions, and the outcome of an earlier take caused the object
	from a later take to be moved out of play; and with stored actions this
	sort of thing becomes much more likely to happen. At any rate the anomaly
	has been removed, but this had the consequence that a few examples
	which used physical things to represent abstract concepts went wrong.
	For instance,
		An emotion is a kind of thing. Envy and gratitude are emotions.
	is likely to produce a world in which "envy" and "gratitude" both exist
	as physical things but are permanently out of play. If we then write
		Understand "experience [any emotion]" as experiencing.
	then commands like EXPERIENCE ENVY will be recognised, but what happens
	next depends on how the action is defined. If like so:
		Experiencing is an action applying to one thing.
	then I7 will now strictly apply the rule that the thing must be touchable,
	that is, with no physical barriers between it and the player: which means
	EXPERIENCE ENVY will now fail accessibility. To get around this, define
		Experiencing is an action applying to one visible thing.
	instead: this weakens the requirement to the point where being allowed
	to refer to the object is enough. ("Visible" here means visible in the
	sense of parser scoping rules, not with one's own eyes: they are almost
	always the same thing, but "[any emotion]" overrode that.)
>--> Another change which will probably make little difference, but which
	clears up an ambiguity: given two descriptions in the form (adjectives)
	plus (kind), which are of different kinds, and where Inform cannot prove
	that either is necessarily a special case of the other, then the one with
	more adjectives is now considered more specific - and this affects rule
	ordering. So, for instance,
		Instead of examining an open door: ... (A)
		Instead of examining a vehicle: ... (B)
	rule (A) is now considered more specific than (B), whereas in previous
	builds they were equally specific and so would appear in rulebooks in
	source text order. (This change made no difference to the behaviour of
	any of the examples, or any other of our test cases: it's pretty esoteric,
	but we are trying to reduce the number of ways source text ordering is
	used, where sensible.)
We can now give unusual or alternative names for the understanding of either/or
	properties, when these are used to describe objects. For instance, if we
	have:
		The box is a container which is carried by the player.
		It is openable and closed.
		Understand the open property as referring to the box.
	then EXAMINE OPEN BOX will work only if the box is open, and so forth. But
	we can now add:
		Understand "opened" as open. Understand "shut/sealed" or "tightly
		sealed" as closed.
	and now EXAMINE TIGHTLY SEALED BOX, etc., will work only when the box is
	closed.
"now T is X", to change the value of a table entry T to a value X, now works
	as might be expected. (This case seems to have been overlooked before: it
	wasn't intentionally left out of the design, and consistency clearly
	requires it.)
Previous restrictions on the use of "let" names, phrase parameters and
	table entries in text being written or appended to external files have
	been lifted. Thus:
		The currently erased jotter is an object that varies.
		To erase (pad - a jotter):
			now the currently erased jotter is the pad;
			write "[heading of the currently erased jotter][paragraph break]"
				to the text file of the pad.
	can now be done more simply thus:
		To erase (pad - a jotter):
			now the currently erased jotter is the pad;
			write "[heading of the pad][paragraph break]" to the text file of the pad.
	This affects both "write ... to ..." and "append ... to ...".
The location of external files written or read by Glulx story files now uses
	the same convention on both OS X and Windows. (In 4X60, Inform for OS X
	differed from this.) Such ".glkdata" files are now always stored in the
	same folder as the project "Whatever.inform", unless the user has created
	a "Files" subfolder of a "Whatever Materials" folder, in which case that
	will be used as the location.
The Kinds index now presents the initial state of either/or properties
	associated with kinds in a more legible way, avoiding double negatives.
	Thus
		Not normally portable not fixed in place.
	(which admittedly looks worse without the italic) is now written
		Usually fixed in place not portable.
The SHOWME testing command is now more detailed, and shows what properties
	an item or room currently possesses. For instance:
		>showme guide
		Guide to Desert Fauna - book
		location: in Death Valley
		unlit; inedible; opaque; portable; singular-named; improper-named
		printed name: Guide to Desert Fauna
		printed plural name: books
		contents: Table of Critters
	(This brings it roughly into line with the old I6 verb SHOWOBJ, but has
	much more legible output, since property values can be printed better.)
The syntax of phrases to access tables has tended to be annoyingly picky
	about prepositions: it has been liberalised a little, so that one can
	now write "from T" equivalently to "in T" in phrases like
		choose a random row from the Table of Soft Fruit
	Similarly, in the phrases with the form "choose ... row ...", either
	the definite or indefinite article can be used, or omitted altogether:
	there will be times when any of these may seem clearest. So any of
	these (for instance) will be allowed:
		choose a random row from T
		choose the row with citrus entry of 5 from T
		choose blank row from T
Use options can now specify numerical values, along with default values which
	the source text can choose to raise: this should help extension-writers
	who want to provide "enough" storage for the user's needs, since the
	user can now use such an option to tell the extension exactly how much
	he does need.
Bibliographic data text normally doesn't recognise text substitutions, for
	obvious reasons: it has to be literal text supplied to outside programs.
	(The story title, author's name, and so on.) It is now allowed to contain
	just one text substitution: ['] for a literal apostrophe. (This allows
	titles like "Summer of [']69" to be handled properly.)
The previous maximum of 500 I6 inclusions and use options used all at once
	in any single source text has now been removed.
Inform now chooses further contrasting colours for World Index maps which
	include more than 10 different regions, and now cycles through its
	colours rather than reverting to grey for subsequent regions when the
	shades run out.
Bug fixed whereby complicated descriptions involving the contents of a region
	would fail to work: for instance, "the number of rooms in R", where R
	is the name of a region, or "a random room in R", would return 0 and
	nothing respectively.
Bug fixed whereby releasing along with a custom website was not working
	(NI was issuing the wrong instructions to cBlorb, the packaging agent.
	Standard websites did work: only those with custom templates failed.)
Bug fixed whereby assemblies which involved properties as well as kinds
	would sometimes not always have those properties set, particularly if
	multiple assemblies took place with similar circumstances. For instance:
		A box is a kind of container. An open box is in every room. A closed
		box is in every room.
Bug fixed whereby a player's holdall which is a part of the player - rather
	than being carried or worn by the player - will now function correctly.
	(This was requested by someone wanting to implement "a robot or marsupial".)
Bug fixed whereby recent changes to table-handling caused properties of
	values to be wrongly read and written. (Typically a property of V would
	be confused with a property of the value whose numerical form at run-time
	was one less than V's.)
Bug fixed whereby route-finding (and counting shortest distances) through
	one-to-various relations would give wrong results, usually false claiming
	that no route existed.
Bug fixed whereby the phrase "direction of (D - door) from (R1 - room)"
	didn't work at all, really (it returned the I6 direction property, not the
	compass direction object - an elementary I6 mistake).
>--> Bug fixed whereby after rules were being applied to out of world actions,
	in spite of the documentation's clear statement that they would not be.
	It is just possible that some authors might have relied on this working:
	to give after-effects to out of world actions, use the report rules.
Bug fixed whereby "change ... to ..." would sometimes cause I6 errors where
	the thing changed was a variable holding an object, and the value changed
	to was something other than an enumerated property-value constant.
Bug fixed whereby "if ...; otherwise if ... begin;" would cause I6 errors
	rather than produce a Problem message (to point out that "begin" should
	not be used with "otherwise if ..." clauses).
Bug fixed whereby placing items by referring to the currently discussed room
	as "here" would sometimes give strange results if (i) the current subject
	of discussion when the sentence is first read is not what will prove to
	be a room, and also (ii) the room being discussed most recently was
	created some time ago and other rooms had been created since then. The
	new interpretation of "here" should be more robust and predictable.
Bug fixed whereby restrictions applied to headings, such as
		Volume 1 - not for release
		Volume 1 - for Glulx only
	would be ignored (but only for Volume headings, not for headings of any
	other level).
Bug fixed whereby implications (such as "A locked thing is usually lockable.",
	an implication in the Standard Rules) are ignored if the thing to which
	they apply cannot have the property which is given as the consequence;
	previously, a somewhat mysterious problem message would be produced.
Bug fixed whereby implications would sometimes override definite statements
	made negatively (e.g. "A locked thing is usually openable" overriding
	"The safe is locked. The safe is not openable"); again, the symptom
	was usually a mysterious problem message.
Bug fixed whereby the use of a relation in an indirect clause with a value
	of a kind which is also used as a property, and has the same name as
	that property, would cause I6 errors.
Bug fixed whereby grammar using a newly defined token for a value belonging
	to a new kind of value, would cause I6 errors.
Bug fixed whereby giving alternatives in grammar for understanding specific
	times of day (e.g. 'Understand "lunch" or "lunch time" as 11:30 am.')
	would cause an internal error.
Bug fixed whereby a few malformed assertions involving impossible callings
	(e.g. 'X (called Y) and X has Y.') produced an internal error rather
	than a problem message.
Problem message added for attempts to create multiple objects with a single
	'called' clause ('Bill and Ben are men in the Garden.').
Bug fixed (or, in a sense, feature added) so that "X is a backdrop which is
	everywhere" will now successfully create an omnipresent backdrop;
	previously one had to write "X is a backdrop. X is everywhere."
Bug fixed whereby actions sometimes continued and reported even if the
	carry out rules had already killed the player.
Bug fixed whereby 'Understand ... as a mistake' would produce the mistake
	reply even when the text was being addressed to another person, rather
	than being intended as a command by the player.
Bug fixed whereby tokens for understanding names which involved various-to-one
	relationships to other objects would not work in concert with specific
	additional names made using 'Understand'. For example,
		Understand "[something related by loyalty]" as a team.
		Understand "Glasgow Rangers" as a team.
	would correctly match the token, but not the additional name, which would
	be ignored.
Bug fixed whereby "now the player is X" would be read differently from
	"change the player to X", and would not properly change perspective.
Bug fixed whereby an assertion sentence setting the description of the player
	caused a contradiction with the default setting for this made in the
	Standard Rules. For instance,
		The description of the player is "Frankly harrassed-looking."
	is now legal again. (It was legal in early builds of Inform, too.)
Slight anomaly resolved (it wasn't really a bug) in the determination of
	which items are concealed, using the "deciding the concealed possessions"
	activity: previously the activity would test items belonging to the player
	even though a subsequent rule would force them to be unconcealed regardless
	of the activity's decision - an actor can't conceal something from himself,
	since concealment in I7 by definition means concealment from the view
	of other people. Now, the activity is not asked about such items.
Bug fixed whereby "( -" was sometimes read as "(-", opening a passage of
	literal I6 code, which was unfortunate if it had actually been part of
	a calculation ("let X be ( -1 * count )", say).
Various bugs fixed to do with the use of the I6 string escape characters
	\, @, ~, ^ in I7 source text and quoted text (for instance, these followed
	by digits would in some cases cause I6 compilation errors).
Problem message added to catch situations where the source text would require
	ridiculous lengths of time to parse, using Inform's normal algorithms:
	this is something which seems only ever to have happened to one user,
	through the accidental omission of lots of punctuation, but it had the
	effect of Inform apparently never completing compilation, which is
	inconvenient to recover from on some platforms.
Problem message added to clarify why some mixtures of actions like 'dropping
	the CD or inserting the CD into the jewel box' are not allowed as the
	premiss of a rule; and bug fixed whereby other illegal mixtures, such as
	'inserting the CD into the jewel box or dropping the CD' were previously
	miscompiling rather than producing a problem.
Problem message added to help diagnose a common mistake with 'if' phrases,
	missing out the 'begin' at the end.
Problem message added to explain why sentences like
		Understand "take [things]" as "drop [things]".
	are not allowed.
Problem message added to explain why sentences like
		Understand "trevor, look" as looking.
	are not allowed.
Problem message to catch attempts to use "carry out", "report" or "check"
	rules applied to named action patterns rather than specific actions;
	previously these would sometimes be allowed provided that some subset
	of their names coincided with the name of some actual action (but with
	unhappy results, since the rule would end up applying to that action,
	which would certainly not have been what the user intended).
The problem message produced by sentences like
		The coin is in the strongbox.
	(where "coin" is a kind of thing, so that this is too vague) has been
	lifted in the case of writing sentences like
		One coin is in the strongbox.
	since, after all, higher multiplicities like
		Two coins are in the strongbox.
	have always been allowed.
Problem message added for trying to define the same test name to mean two
	different tests.
Problem message added for trying to use a kind of thing to relate multiple
	objects to single values in single sentences. (Ideally this would work,
	but there are awkward implementation reasons why it doesn't, for the
	moment, and the problem message replaces a less polite internal error.)
Problem message clarified when trying to make a property which must hold an
	object of a given kind, when no objects of that kind exist anywhere, so
	that this property can never have a legal value.
Problem message added for contradictory indications of where something
	initially is, for instance,
		Fred is in the Kitchen. Fred is in the Dining Room.
	(How we overlooked this obvious case in four years of testing...)
Problem message added for an Understand attempting to give a name to
	an object qualified by a relative clause or properties. (The same effect
	can be achieved by other means - the problem message explains how.)
Problem message added for an attempt to test if a vaguely described past
	action succeeded. (Previously these apparently compiled, but gave
	usually wrong answers.)
Problem message added to give more helpful diagnosis if an action definition
	incorrectly gives a past participle longer than a single word.
Problem message added (rather than an internal error) for using a relation
	which relates objects to values in a "[something related by...]" token
	in an 'Understand' sentence.
Bug fixed whereby the parser would give slightly misleading replies if
	pronouns other than "her" were used in commands before they had ever
	been set.
Bug fixed whereby scenery items, never mentioned in room descriptions, could
	nevertheless silently become pronoun values. (Thus "it" might mean the
	sky in a room where the sky was scenery.)
Bug fixed whereby the parser would reply "That noun did not make sense in
	this context." in response to certain scope-filtering tokens where
	nonsense had been typed, but without a proper paragraph break.
Bug fixed whereby duplicate problem messages would result from a phrase
	defined with alternate wordings, but also defined incorrectly. (The
	problems would be repeated for each possible wording.)
Bug fixed whereby the "Use serial comma" option did not result in a serial
	comma being used in clarification questions like
		Which do you mean, the fish, the fowl, the chalk, or the cheese?
Documentation bug fixed whereby the "return to contents" links in Writing
	with Inform would sometimes return to the contents of the Recipe Book
	instead.

Examples:
	"Xot" added to demonstrate storing an erroneous command and replaying it
		later, as seen in Infocom's HHGttG.
	"Terracottissima Maxima" added to demonstrate understanding an indexed text
		property.
	"Fido" added to demonstrate a dog that the player is allowed to name and
		re-name.
	"Pre-alpha" added to demonstrate a beta-testing command that allows the
		player to preface any line with a punctuation mark to show it is a comment.
	"Blackout" added to demonstrate replacing letters in a printed name under
		certain circumstances.
	"Identity Theft" added to demonstrate asking the player for a name at the
		start of play.
	"Mr. Burns' Repast" added to demonstrate a fish that renames itself
		depending on how the player refers to it.
	"Endurance" added to demonstrate a way of modeling time so that it depends
		flexibly on the actions undertaken during a turn.
	"Uncommon Ground" tweaked to repair a couple of cosmetic flaws held over
		from earlier versions of the extension
	"Panache" corrected to remove a reference to the elderly (and now
		withdrawn) type "string-of-text"
	"Disenchantment Bay 12" corrected to remove a reference to the captain as
		"transparent", which was a holdover from a time (before the first public
		beta of Inform) when characters could be opaque or transparent and this
		quality would determine whether their possessions could be seen.
	"Straw Into Gold" added to demonstrate a character whose name is concealed
		until the player guesses it.
	"Celadon" added to demonstrate extending DROP to apply even to objects the
		player is carrying inside a container or on a supporter.
	"Northstar" added to demonstrate modifying the player's command using a
		regular expression, so that ASK JOSH TO TAKE INVENTORY will be
		understood as JOSH, TAKE INVENTORY.
	"Burning", "Gelato", "Originals", "Solitude", "Stately Gardens", "Tilt 2",
		and "Tilt 3" revised to make use of the new truth state kind of value.
	"Cactus Will Outlive Us All" added to demonstrate stored actions and
		characters who respond when they occur.
	"Anteaters" added to demonstrate stored actions that include topics.
	"Bosch" added to demonstrate an alternative full score system using
		stored actions.
	"Kyoto" revised to reflect the current state of the actions rules.
	"Dinner is Served" revised to change the way closed containers are described.
	"Chronic Hinting Syndrome" "Ferragamo Again", "Being Peter", "The Problem
		with Edith", and "Introduction to Juggling" revised to reflect new
		restrictions about acting on out-of-play objects.
	"Broughton" revised to fix a very tiny bug in which "greeting" was not
		specified as a subject.
	"Lucy" added to demonstrate redirecting the ASK command to a new topic
		other than the one the player typed.
	"Fine Laid" added to demonstrate redirecting most actions from one object
		to another.
	"Mirror, Mirror" revised to use indexed text rather than an external file,
		which means that it can be used in z-machine games as well.
	"Actor's Studio" added to demonstrate a video camera that records actions
		occurring in its presence, then plays them back later.
	"Capital City" added to demonstrate capitalized text in the status line.
	"Rocket Man" added to demonstrate sentence- and title-casing for any to-say
		phrase.
	"Rubies" added to demonstrate a scoreboard of high-scoring players.
	"Witnessed", "Sand", "Modern Conveniences", "Hot Glass Looks Like Cold
		Glass", "Model Shop", "Nickel and Dimed" slightly changed to spell
		out kind names in full rather than use abbreviations.
	"Situation Room" added to provide 24-hour time printing.
	"Tamed" revised to get rid of the magician's booth being closed.
	"Starry Void" added to demonstrate a simple case of a room whose exterior
		is visible from another room.
	"The Cow Exonerated" added to demonstrate matches for starting fires, using
		indexed text to make the reporting more elegant.
	"Savannah" added to demonstrate liquid used to put out fires.
	"Slouching" added to demonstrate sitting, standing, and lying down postures
		for the player and other characters.
	"Costa Rican Ornithology", "Crusoe", "Farewell", "Juggling", "Nickel and
		Dimed", "Money for Nothing", "Aftershock", "Channel 2" edited to make
		it easier to extract the generalizable portions for use in other games.
	"Four Cheeses" edited for portability and to clean up a few clumsy
		phrasings due to the age of the example.
	"Bogart" edited for portability and to remove a special-case bug.
	"What Not To Wear" added to demonstrate a more complete clothing system
		combining layers with a concept of different regions of the body, for
		whole classes of shirts, trousers, etc.
	"Port Royal 1" and "Port Royal 2" edited for length and clarity.

Extensions:
	"Basic Screen Effects" edited for a small bug that prevented the "show
		current quotation" phrase from being available under Glulx. Version
		advanced to 5.
	"Glulx Entry Points" changed to treat glulx replacement command as indexed
		text, which means that it can be edited more flexibly or even
		constructed through multiple hyperlinks. Version advanced to 3.
	"Locksmith" changed to make the "you lack a key..." message more flexible
		and keyed to individual objects. Version advanced to 4.
	Minor one-line addition to the documentation of "Basic Help Menu" to
		clarify how to replace the enclosed menu with one of our own.

§11.7. What was new in build 4X60 (August 2007)

As this release was being prepared, Russian submersibles planted a flag on the North Pole, 4.2 km underwater; there was a crackdown on counterfeit toothpaste in Mozambique; forest fires threatened Dubrovnik, while Minnesota flooded; there was a single, unconfirmed sighting of the Yangtse River Dolphin, thought extinct since 2004; the Unix court case, SCO v. Novell, found for Novell; the quarterback of the Atlanta Falcons pled guilty to "conspiracy to sponsor a dog"; and Peter Stoychev of Bulgaria broke the speed record for swimming the English Channel.

In the world of Inform, build 4X60 introduced the Recipe Book to the in-application documentation, and made a number of internal reforms, notably improving the speed of table handling at run-time.

4X60 (23 August 2007)

This build adds 19 new examples and modernises a dozen others, and presents
a new volume of built-in documentation: the Inform Recipe Book. It also
provides new features for variable text, improves and extends table-handling,
allows Glulx-format games to read and write files and communicate with
external programs, and allows extensions to create more readable and
useful documentation.

(Windows only) Added support for Glulx mouse events and hyperlinks to the
	game tab.
(Windows only) The justification style hint is now supported when running
	a Glulx game in the game tab. As a result, games using Emily Short's
	"Glulx Image Centering" will now work when run within the application.

A new manual, The Inform Recipe Book, has been added to the application. It
	sits alongside the previous manual (Writing with Inform) and presents
	the examples thematically, with connecting advice and comparisons of
	techniques to achieve a wide range of IF effects. This should make the
	(now 357) examples much easier to browse and to borrow from.
The "[one of]" text substitution previously provided by Jon Ingold's
	extension "Text Variations", which built on code by Andrew Plotkin and
	Roger Firth, has now been adopted into Inform's core language. Examples
	of its use include:
		say "You flip the coin. [one of]Heads[or]Tails[purely at random].";
		say "[one of]The phone rings[or]The phone rings a second time[or]The
			phone rings again[stopping].";
		say "You turn the light switch [one of]off[or]on[cycling]. Nothing
			happens.";
		say "The newspaper headline is: [one of]War Casualties
			[or]Terrorists[or]Banks[sticky random] [one of]Continue To Expand
			[or]Lose Out[sticky random].";
		say "The light changes randomly again; now it's [one of]green
			[or]amber[or]red[at random].";
		say "Zorro strides by, [one of]looking purposeful[or]grim-faced[or]deep
			in thought[or]suppressing a yawn[or]scratching his ribs[or]trying
			to conceal that he has cut himself shaving[as decreasingly
			likely outcomes].";
		say "You dip into the chapter on [one of]fish[or]mammals[or]birds
			[or]reptiles such as the black salamander[in random order]."
	See the new section 5.6 in the documentation: note that "[as decreasingly
	likely outcomes]" and "[in random order]" are new options, the former
	using a tapering probability distribution, the latter a random permutation.
>--> It should be noted that the new implementation of this substitution is
	completely different to the one provided by the extension. The previous
	method involved printing all the text to a buffer array, then hash-coding
	it and taking choices based on this hash, which meant that the same
	sequence of choices occurring twice in the same text would be effectively
	the same (because of having the same hash code); thus
		"This is [one of]A[or]B[at random] versus [one of]A[or]B[at random]."
	could never print "This is A versus A." or "This is B versus B." The new
	implementation treats each "[one of]..." individually. To get around this,
	define
		To say A-or-B: say "[one of]A[or]B[at random]".
	and then change the text to
		"This is [A-or-B] versus [A-or-B]."
	Furthermore, there is no buffer array, no hash code, and it is no longer
	possible to extract state information by deliberately printing the text
	with an incomplete "[one of]" construction. (To quote the Text Variations
	documentation: "a terrible way to solve that kind of problem", so we don't
	feel too bad about withdrawing it.) Thus the phrases "the index of the
	last buffer" and "the index of the buffer" no longer exist.
	In any case, the new implementation polices the use of the construction
	so that leaving it incomplete is no longer possible. "[one of]" must be
	matched by one of its possible conclusions "[purely at random]",
	"[stopping]", ..., or problem messages will be generated; similarly,
	"[or]" can only legally be used inside the construction. On the other
	hand, the new implementation does allow the construction to be nested, both
	explicitly in a single text and also implicitly (where a text substitution
	inside one of the options itself does something which also involves a
	"[one of]"), where the old implementation would silently have failed.
	As an explicit example:
		"[one of]A palace on the [one of]Nile[or]Euphrates[purely at random]
		delta[or]A hovel by the [one of]Tigris[or]Rhine[purely at random]
		river[purely at random]."
	In practice, if a work in progress used "Text Variations" and did not
	try to use "the index of the last buffer" then there is a good chance
	that simply deleting the line
		Include Text Variations by Jon Ingold.
	will be the only change required.
	We thank Jon Ingold and his collaborators for donating their design. The
	extension "Text Variations" will continue to be available from the website
	for the time being, but marked as no longer needed or compatible with
	builds from here onwards. We suggest that users uninstall it once they
	are sure that any works in progress continue to work without.
	This change implements proposal (6.20) from the January 2007 consultation
	document.
The run-time code for handling tables has been rewritten to improve its
	reliability and efficiency. A number of minor bugs have been fixed in
	the process, notably a failure to sort correctly on tables which contain
	mixed blank and non-blank rows, and a rarely occurring problem to do with
	storing the number 32739 in table entries under the Z-machine.
Table sorting is now carried out using a hybrid algorithm: insertion sort
	from 1 to 11 rows, and in-place mergesort for 12 rows and up. This is
	much faster on even medium-sized tables (e.g. about ten times faster on
	tables of 200 rows), and is also stable in all cases: that is, if
	two rows have the same value in the X column of a table, and that
	table is then sorted (forwards or backwards) on the X column, then
	they will stay the same side as each other. As a consequence, all sorts
	are idempotent, that is, performing the same sort operation twice always
	results in the second operation making no changes at all. (The previous
	algorithm was idempotent but, owing to a bug, not in all cases stable.)
	Insertion/in-place mergesort was chosen because we needed stability,
	O(n log n) average running time (together with good performance
	on nearly-sorted tables, which are the commonest usage cases in
	actual Inform source text), O(1) storage overhead (the Z-machine is
	extremely short of table space), and reasonably predictable stack usage.
Projects compiled for Glulx rather than the Z-machine now have the ability
	to make use of external files. Like sound effects and figures, these
	are declared and given names before use:
		The File of Glaciers is called "ice".
	This creates a new named constant "File of Glaciers" (whose kind of value
	is "external-file") for use in file contexts. (The prefix "binary file"
	rather than "file" can be used to make the file binary in the Glk sense,
	but the default is to use text files for all purposes.) Each file is
	considered to be owned by some project, identified by its IFID. By
	default, a newly declared file is owned by its own project, but we can
	also specify that we want to use somebody else's file, either explicitly
	or vaguely:
		The file of Spectral Sequences (owned by project
			"4122DDA8-A153-46BC-8F57-42220F9D8795") is called "adams".
		The file of Boundaries (owned by another project) is called "milnor".
	We can write or append to a file owned by anyone, but can only read a
	file whose ownership matches this description.
	External files are indexed in the Contents index, alongside figures and
	sound effects.
	Files sometimes exist, and sometimes do not: they are sometimes complete,
	sometimes only partly written. (For a file shared between two games
	running simultaneously, one might try to read a file the other is still
	in the middle of writing.) We can test this with:
		if the file of Invariants exists...
		if ready to read the file of Invariants...
	A file cannot be ready if it does not exist, so the latter is a stronger
	condition.
Tables can be saved to external files, and loaded them back in again, during
	play: all file-handling is done automatically. The user only needs to use
	the phrases:
		read the File of Glaciers into the Table of Antarctic Features;
		write the File of Glaciers from the Table of Antarctic Features;
	Blank entries are preserved; it is legal to write a small file into a
	large table, and if so, all unwritten entries are blanked; a run-time
	problem is shown if the file contains more rows or columns than will
	fit into the table which it is being loaded into; similarly, a run-time
	problem is shown on trying to write a table which contains data not
	safely exchangeable with other story files (or other compilations of
	itself).
Text can also be saved to a file, and again all file-handling is automatic:
		write "Jackdaws love my big sphinx of quartz." to the file of
			Abecedary Wisdom;
		append "Jinxed wizards pluck ivy from the big quilt." to the file of
			Abecedary Wisdom;
	The quoted text can, of course, contain substitutions, so can be
	long and complex if need be. On an append, the file is created if it does
	not already exist.
Text from a file is printed back with the text substitution:
		"[text of the File of Abecedary Wisdom]"
	To copy one file to another, for instance,
		write "[text of the file of Abecedary Wisdom]" to the file of
			Secondary Wisdom;
>--> The implications to do with lockability have been improved:
		A locked thing is usually lockable.
		A locked container is usually closed.
		A locked door is usually closed.
		A lockable container is usually openable.
		A lockable door is usually openable.
	Thus writing "The ballot box is a locked container." will now deduce that
	the box is probably lockable, closed but openable. These are only guesses
	by Inform, and can be overridden by giving explicit instructions to the
	contrary: "The ballot box is a locked unopenable container."
Definitions of adjectives, which previously had to refer to their subjects
	only by the pronoun "it" (or in some cases "his", "her", etc.), can now
	make callings. For instance:
		Definition: a direction (called thataway) is viable if the
			room thataway from the location is a room.
	is a good deal easier to read than
		Definition: a direction is viable if the room it from the location
			is a room.
	which was previously the only way to write this. Only a single calling
	can be made, and it must refer to the specific object to which the
	definition applies.
A new rule in the Standard Rules, the "can only take things rule", prevents
	the taking of objects which are not things - for instance, rooms or
	directions. (Such an action can never normally be generated by the
	grammar for typed commands, but if Understand sentences are written
	to open the possibility then the player will see ugly "programming error"
	messages: the new rule prints a more suitable reply.)
Extension documentation can now request "paste into the source text" icons
	like those found in the main documentation and its examples. If an
	indented paragraph of quoted source text begins with an asterisk and
	then a colon, like so...
		*: A dog is a kind of animal.
	...then the asterisk-and-colon are replaced in the final documentation
	by a paste icon: clicking this will insert the copy which follows into
	the source text. The text to be pasted is considered to begin after the
	colon, and to continue until the next unindented text, i.e., it can
	run for many quoted paragraphs, but as soon as the quotation is broken
	the paste extent will end. Any tables within the quoted range should
	be safely rendered with tabs in between the columns.
Large extensions which need to include a large amount of documentation
	can now subdivide it using headings and/or subheadings, like so:
		Chapter: Pesky Meddling Kids
		Section: Dog Food
	A suitable table of contents with navigation links will be automatically
	added to the extension documentation, if so.
The Extensions chapter of the documentation has, appropriately enough, been
	extended: it now opens up a limited number of previously restricted
	syntaxes to public use. These will only be useful to experienced Inform 6
	programmers.
Fixed a further namespace clash: a "let" name can now coincide with the
	column name of a table. (This was preventing John Clemens's extension
	"Scheduled Activities" from working in recent builds.)
Extensions:
	"Basic Screen Effects" very slightly updated so that the documentation
		is clearer about the lack of colored letters in Glulx, and suggests
		that the author turn to Glulx Text Effects for these capabilities
		instead; also given a new example to demonstrate forcing the player
		to type what we want him to type (since this is becoming something
		of a frequently-asked question); chapter and section headings and
		paste-able examples added.
	"Basic Help Menu", "Glulx Text Effects", "Locksmith", "Menus",
		"Punctuation Removal" tagged so that the example can be pasted.
	"Complex Listing", "Plurality" tagged and given chapter and section
		headings.
Examples:
	"Radio Daze" example from Jon Ingold's Text Variations extension brought
		into the main documentation.
	"Camp Bethel" added to demonstrate several other common applications of
		text alternatives.
	"Chanel version 1" added to demonstrate paired "[i]...[/i]" and
		"[b]...[/b]" italic and boldface tags, similar to HTML's.
	"Blink" added to demonstrate creating one's own text variations keyed
		to values, using the special terminology explained in the Extensions
		chapter.
	"Uncommon Ground" added to demonstrate creating one's own text variations
		keyed to the identity of the player character.
	"Labyrinth of Ghosts" added to demonstrate recording the deaths of all
		previous players of the story file by storing them in a file.
	"Alien Invasion Part 23" added to demonstrate saving preference files
		from one game in a series for use in the next episode.
	"Flathead News Network" added to demonstrate communicating with a simple
		Unix script running in the background, in order to provide live news
		headlines (drawn from RSS feeds) inside a story file.
	"Ferragamo Again", "Straw Boater" slightly cleaned up to be better filed
		in the Recipe Book.
	"Cinco" edited to fix a particularly bone-headed bug that vitiated the
		whole point of the example.
	"When?" adjusted to slightly improve the way the example is described.
	"Modern Conveniences" added to demonstrate standard kitchen and bathroom
		appliances.
	"Do Pass Go" added to demonstrate a pair of dice.
	"Mirror, Mirror" added to demonstrate remembering the current room
		description by preserving it in an external file.
	"The Unbuttoned Elevator Affair" added as an example of a simpler lift
		than the elaborate one in "Dubai".
	"Further Reasons Why All Poets Are Liars" added as an example of using
		action variables for an action which moves a box around internal
		positions inside a location; a much thinner version of this example,
		"A pushable box", has been removed.
	"M. Melmoth's Duel" added, similarly to replace "Tinted wallpaper".
	"The Second Oldest Problem" added to demonstrate using action variables
		to make the going action react to moving between dark rooms.
	"Saint Eligius" added to demonstrate an additional comment added to a
		room description when the player first enters.
	"Baritone, Bass" added to demonstrate defining the character at the
		start of play.
	"Bic" added to demonstrate testing whether any defined objects are missing
		description properties.
	"Meet Market" added to demonstrate relations involving multiple values.
	"Depth" rewritten to improve the simulated geometry used to test whether
		an item could fit inside a container.
	"Patient Zero," "Today Tomorrow," "Reporting rules for other characters'
		behavior," "Uptown Girls", "Full Moon" edited to take advantage of
		new text variation features.
	"Belfry", "Bikini Atoll", "Dearth and the Maiden", "Hayes Code",
		"Lies", "Safety", "Undertomb" and "Weathering" all made into formal
		numbered examples rather than, as in previous builds, appearing in
		the running text of the manual.
Bug fixed (or, if you prefer, feature added) whereby sentences providing
	alternative names for times of day, like:
		Understand "lunch time" as 11:30 am.
	...now work as might be expected.
Bug fixed whereby Understand ... as a person would fail with I6 errors.
	(Apologies for this: an oversight in 4W37's abolition of the
	player-character kind, which had the same flaw, but nobody noticed
	because it was so little used.)
Bug fixed whereby "if S is not happening", for S a scene, would incorrectly
	think that a completed once-only scene was still happening.
Bug fixed whereby implications would in some cases be ignored in circumstances
	which it would be tiresome to write out, but to do with multiple things
	being simultaneously present, some qualifying and some not.
Bug fixed whereby using I7 to rerelease an existing I6 story file in
	blorbed format with bibliographic data would fail because of the lack
	of a room (needed to initialise certain room variables).
Bug fixed whereby a few either/or properties could not be changed in play
	without spurious run-time problems being produced. (In particular,
	"now X is transparent" or "now X is opaque" caused problems.)
Bug fixed whereby declaring that the player is a person who happens to be
	initially somewhere other than in the earliest-created room, or outside
	the map altogether, would cause programming errors or other strange
	phenomena at run-time.
Bug fixed where a player attempting to UNLOCK a door which is "locked" but
	which, unbeknownst to the player, has no matching key, would cause a
	run-time problem complaining about the lack of a "matching key" property.
Problem message added for trying to use "[something related by...]" to
	understand something which can have no relations.

§11.8. What was new in build 4W37 (July 2007)

As this release was being prepared, Chinese archaeologists remotely sensed an unknown chamber in the Tomb of the Terracotta Army; Corporal Willie Apiata became the only living New Zealander to hold the Victoria Cross, won in Afghanistan; the Ghanaian cedi became the strongest African currency; Live Earth concerts were held worldwide, and the Boeing 787 was unveiled; the US Congress passed the "Honest Leadership and Open Government Act"; prolonged dust storms swept Mars, while floods in Tewkesbury submerged the whole town save only the 12th-century Abbey.

In the world of Inform, build 4W37 made miscellaneous improvements mostly centred around parsing the names of objects. A significant change not linked below, since it was an excision, was the removal of the former "player-character" kind of person: any person can now be the protagonist.

4W37 (27 July 2007)

This build adds 21 new examples and provides miscellaneous new features.
Chief among these are substantial improvements to the parsing of names:
nouns can now be recognized by their number or unit properties, and also by
their relations, so that 'Understand "bottle of [something related by
containment]" as the bottle' will parse BOTTLE OF SAND if and only if the
sand is contained in the bottle. We have also made a tentative beginning on
support for sound effects to match the existing support for illustrations.
As usual a number of bugs are fixed, and although a few issues still remain
(the current tally of open issues stands at 13, as compared with a peak of
about 330 earlier this year) none are severe and most users seem to find
that Inform is fairly reliable, so recent effort has gone into advancing
the language rather than maintaining the compiler.

INFORM FOR WINDOWS

All tabs (save the settings tab) have a row of buttons at the top of the
	tab, allowing navigation and access to common functionality,
	similar to the OS X application.
Fixed a bug preventing the installation of an extension with brackets in
	its name.
Added support for multiple windows to the game tab. Any combination of
	text, grid and graphics windows can be opened by a game running
	within the application.
Added support for graphics windows to the game tab. As a result, games
	using Emily Short's "Simple Graphical Window" and "Location Images"
	extensions will now work when run within the application.
Added support for timer events to the game tab. Combined with the above,
	games using the "Graphical Window Animation" extension will now work
	when run within the application.
If saving a project fails, the application now shows an error message.
	If the project was being saved as part of being closed, then
	after the error you get a chance to save to a different place.

GENERAL

>--> The kind "player-character" has been abolished. Previously, this was a
	kind of person able to be the player's persona in the model world: for
	most games, there was only one player-character in existence, the one
	automatically created by Inform and called "yourself". From this point
	onwards, any "person" can be the player, and indeed "player" is now
	a person variable, not a player-character variable. This means that the
	player object can now be any man, woman or animal in the source text,
	and these can be switched between freely in play. Moreover, we can
	much more simply specify who the protagonist is:
		Lord Bowler is a man in the Pavilion. The player is Lord Bowler.
	If we do not specify the player's identity, the "yourself" is still
	created and used as before.
	This change will affect only works which create "player-characters" in
	their source text: to adapt them to work again, it should be enough
	simply to change every usage of the kind name "player-character" to
	"person", "man", "woman" or "animal" as appropriate.
	This change implements proposal (6.56) from the January 2007 consultation
	document.
>--> Up to now, all scenes have been able to take place many times: if a
	scene ends, and then later on its starting conditions once again hold,
	then it will start all over again. This is sometimes very useful, but
	also a source of confusion, and it has led to people writing "S begins
	when ... for the first time" over and over to stop S from recurring.
	As from this build, a scene can be declared either as recurring or not
	when it is first created. So for instance:
		Hourly Patrol is a recurring scene.
		Apocalyptic End is a scene.
	makes one of each kind of scene. (An ordinary scene can also be declared
	as a "non-recurring scene" for clarity's sake.) Note that any scene
	declared as just "scene", and in particular any scene declared in
	source text for previous builds of Inform, is now non-recurring: so if
	you need a scene to recur in a work-in-progress, you need to insert the
	word "recurring" into its definition.
	This change implements proposal (6.52) from the January 2007 consultation
	document, though in a slightly different way from that proposed.
Partial sound support has been added to Inform: see the new sections 19.6
	and 19.7 of the documentation. As with picture support, Inform provides
	the groundwork and leaves it for more sophisticated extensions to go into
	more elaborate facilities. The present state of completion is that Inform
	can, on all platforms, read Ogg Vorbis or AIFF sound files from the
	Materials/Sounds folder for a project, and embed them correctly into a
	Blorbed Glulx story file, compiling correct code for the Glulx machine
	to play the sounds back at the appropriate moment. However, these
	sounds will only be audible in Windows Inform, or when playing a
	released Glulx story file in Windows Glulxe or Spatterlight for OS X:
	Glulx support for sound has been implemented in the glulx interpreter
	used in both Inform and Zoom for OS X, so that placeholder text is
	printed instead.
	Sound support was proposal (6.61) from the January 2007 document.
Up to now, the only properties which could be used as part of an object's
	name for parsing purposes were either/or properties and enumerated named
	properties. This restriction has been almost completely lifted: we
	can now understand properties whose kind is number, time, or a unit.
	For example:
		An aspect ratio is a kind of value. 16:9 specifies an aspect ratio.
		A television is a kind of thing. A television has an aspect ratio.
		The widescreen TV is a television in the Office. The fifties TV is
		a television in the Office. The widescreen TV is 16:9. The fifties
		TV is 4:3. Understand the aspect ratio property as referring to
		a television.
	...allows us to type EXAMINE 16:9 TV, for instance.
	In addition, further grammar used to specify unusual values is now
	recognised in such situations: for instance if we wrote...
		Understand "European standard" as 16:9.
	the EXAMINE EUROPEAN STANDARD TV would also work. (Previously this did
	not work, because the implementation was incomplete.)
	Finally, a problem message has been added for the (now fairly few) cases
	where the property still does have a kind which cannot be parsed:
	previously no problem was issued in cases Inform could not handle, and
	the feature simply did not work.
	(This change did not appear in the January document, but has been much
	requested since.)
A new form of grammar token has been added to enable names of objects (and
	rooms) to include names of other objects (and rooms) related to them.
	For instance, if we write:
		A box is a kind of container. Understand "box of [something related
		by containment]" as a box. The Toyshop is a room. The red box is a
		box in the Toyshop. Some crayons are in the red box.
	then TAKE BOX OF CRAYONS will work, because CRAYONS matches against
	"[something related by containment]" for the red box - or it does for
	as long as the crayons are there. We can have similar matches against
	relations of all kinds, but have to name the relation explicitly, using
	its one-word name. We can also reverse the sense:
		A box is a kind of container. Understand "box in [something related
		by reversed containment]" as a box. The Toyshop is a room. The crate
		and the hammock are in the Toyshop. In the crate is a box. In the
		hammock is a box.
	makes TAKE THE BOX IN THE HAMMOCK work. (Where more than one object
	matches the criterion, for instance if the original box contained both
	crayons and chalk, any of the names can be used.)
Inform normally decides whether an object has a singular or plural name,
	or whether it has a proper name, by looking at how it is first
	introduced. This mainly works well, but people have also asked for
	more explicit control, especially to cope with changes in an object
	during play. Accordingly, there are now two new either/or properties
	for all things:
		A thing can be plural-named or singular-named.
		A thing can be proper-named or improper-named.
	This change implements proposal (6.46) from the January 2007 document.
The phrase for changing the exits of a room can now accept "nothing" or,
	equivalently, "nowhere" as the new exit, thus allowing map connections
	to be explicitly deleted in play. For instance:
		change the east exit of Stage to nowhere;
	Bugs in type-checking to do with the handling of "nothing" have been
	removed.
Some authors have recently asked for the facility to make extensions go
	uncredited in the VERSION command output, since this might give away
	story details, or generally produce verbosely self-laudatory output.
	A new "authorial modesty" use option has been created for this purpose.
	Inform has to tread a careful line here, because people make extensions
	available under a Creative Commons licence which requires that they be
	credited: so you can only be modest about your own work. If the sentence:
		Use authorial modesty.
	is found in an extension, then its credit line is omitted from the VERSION
	output of any game using it. If the same sentence is found in the main
	source text of a work, then credits are omitted for every extension with
	the same author's name as the work itself. (In other words, it credits
	everyone else's extensions, but suppresses mention of your own.)
	The "say" phrase "[list of extension credits]" uses the same convention,
	but the new "say" phrase:
		"[complete list of extension credits]"
	ignores all these efforts at modesty and prints the whole list. (An
	otherwise modest author might want to print this posthumously after the
	end of play, for instance, or in response to a secret debugging command.)
The the ambient odour rule, the ambient sound rule and the block vaguely
	going rule now apply to actions by all actors, not just the player, so
	that (for instance) the command XERXES, LISTEN will be read as a
	request to listen to the ambient location, rather than printing out a
	parseresque objection such as "What do you want Xerxes to listen to?"
The grammar "switch on [something]" has been added to the standard rules,
	and has the same effect as "switch [something] on". This is more consistent
	with switching off.
The maximum length for an extension rubric has been increased from 250 to
	500 characters. (Rubrics exceeding that length are silently truncated
	in extension documentation.)
It is now allowed to create a temporary value (i.e., a local variable) with
	"let" whose name coincides with that of a thing, room or property.
	Previously this triggered problem messages, and was a particular problem
	for extensions and the Standard Rules, which had to avoid "let" names
	that might hit any of the things created by the user. (For instance,
	several people reported it as a bug that creating a property called
	"target" caused problems - this was because the Standard Rules use a
	"let" variable called "target" in places.)
The resolution of noun phrases has been slightly changed so that a single-word
	kind of value name will take precedence over the name of a thing or room
	in an assertion sentence. For instance:
		The scene script is in the wardrobe.
		Grand Finale is a scene.
	would previously have read "scene" as a reference to the scene script,
	a physical thing, not the kind of value "scene". (This in practice makes
	it easier to have rooms and things whose names include the names of
	kinds such as "number", "time" and so on.)
Examples:
	"Lanista" parts 1 and 2 added to demonstrate randomized combat, first in
		a simple form and then with weaponry and an ATTACKING IT WITH action
	"Night and Day" added to demonstrate recurring sequences of scenes
	"Candy" added to demonstrate making a randomly selected item poisonous
	"Puff of Orange Smoke" added to demonstrate redirecting all actions from
		one object to another
	"Disappointment Bay" examples changed to the more geographically accurate
		Disenchantment Bay; typo fixed in the final, finished example
	"Entrapment" modified to correct a bug due to changed handling of actions
		in recent releases of Inform
	"Terror of the Sierra Madre", which demonstrates player-switching,
		greatly simplified as a result of the abolition of player-character
	"Exit Strategy", demonstrating how to set up non-recurring scenes, removed
		(since all scenes are now non-recurring unless otherwise stated)
	"Pine 3", "Pine 4", "The Prague Job", and "Space Patrol" modified to
		reflect the usage of "recurring" scenes
	"Snip" modified to remove bugs and make use of the new ability to
		understand unit properties; "Snip Snip" withdrawn, as the hack it
		demonstrates is no longer needed and the same functionality was
		achieved instead by a single line added to "Snip"
	"Totality" (example about scheduling an eclipse) given a "test me" script,
		and a syntax bug removed
	"Dinner is Served" revised to work better when the object reached for
		is the second noun rather than the noun, and also to have less
		cryptic syntax; the test for the example has been extended
	"Tilt" added to demonstrate an implementation of a deck of cards using
		individual card objects, in which ranks and suits of cards are
		automatically parsed
	"Tilt 2" added to demonstrate an implementation of poker hands, where
		the cards in a player's inventory are described according to their
		value; illustrates use of a complex rulebook
	"Tilt 3" added to demonstrate use of text colors to make poker suit
		symbols appear in red, under both Glulx and the Z-machine
	"Aspect" added to demonstrate the automatic parsing of unit properties
	"Channel" added to demonstrate the automatic parsing of number properties
	"Channel 2" added to demonstrate a combination of advanced parsing
		features, in the creation of tunable televisions
	"Cheese-makers" added to demonstrate a TALK TO action tied to a
		scene-structured plot
	"Alias" added to demonstrate telephone-number-sized units functioning
		under Glulx
	"Claims Adjustment" added to demonstrate a camera that produces instant
		photographs of things; the photographs can then be referred to as
		in X PHOTOGRAPH OF APPLE
	"Puncak Jaya" added to demonstrate characters who can be referred to in
		their absence
	"Cinco" added to demonstrate containers referred to by their contents
	"Originals" added to demonstrate disambiguating objects from models of
		those objects
	"Removal" simplified to use action variables rather than the more
		complicated source
	"Gopher-wood" added to demonstrate the use of the proper-named attribute
		to change someone's name during play
	"Carnivale" added to demonstrate the simple scoping case of a large object
		that should be visible from other rooms
	"Rock Garden" added to demonstrate the simple scoping case of multiple
		rooms that can see into one another (as opposed to the rather more
		complex "Stately Gardens" which autogenerates a lot of room
		description as well)
	"Latin Lessons" added to demonstrate supplying a missing noun when the
		action is being performed by someone other than the player
	"Uber-Complete Clavier" (the big Unicode test) slightly changed so that
		it can now be compiled for Glulx as well as the Z-machine
	Paragraph breaking adjusted in "In Fire or in Flood", "Misadventure",
		"Goat-Cheese and Sage Chicken", "Owen's Law"
	Minor typos removed from "Wight", "Alpaca Farm", "Apples"
Extensions:
	"Glulx Text Effects" modified to make it easier to set custom colors
		for text in Glulx; this appropriates the color-management source from
		the extension "Simple Graphical Window" by Emily Short, so those
		using Simple Graphical Window should update to version 4 of the
		extension in order to avoid overlap. Advanced to version 2.
	"Punctuation Removal" revised to include a phrase that corrects
		instances of "mr.", "mrs.", etc., to "mr", "mrs", and the like, to get
		around parsing frustrations commonly encountered with these titles.
		Also added the means to remove apostrophes as well as the other
		punctuation marks; example added for parsing such phrases as "Jack's
		tie" if and only if Jack is currently wearing the tie object. Version
		number advanced to 3.
	A bug fixed in "Complex Listing to deal with the marking of regions";
		version number advanced to version 5.
	Bug fixed in the screen-width-determining routine of "Basic Screen Effects".
Bug fixed whereby past tense conditions in the form "in ... for the first time"
	would sometimes have the temporal requirement ignored, particular in the
	preambles to rules like:
		Every turn when in the Hall of Mists for the first time;
Bug fixed whereby rules which depend on action taking place at the same time
	as a compound condition would sometimes produce spurious problem messages:
	for instance,
		Check turning the dial to  when the number understood < 0 or the
		number understood > 99:
	...is valid but generated a problem message in 4U67.
Bug fixed whereby "otherwise if ... begin" (which is incorrect since otherwise
	if divides the existing code block, rather than beginning a new one) led
	to I6 errors rather than a problem message.
Bug fixed whereby using "(called ...)" to create temporary named values at
	a time in the past such that they could not survive to the present
	would lead to I6 errors rather than a problem message.
Bug fixed whereby rules taking effect if "doing something to ..." and some
	description would sometimes false take effect when the action took a
	non-object as its noun, when the value which happened to have been
	typed coincided with the internal object number of an item matching
	the description.
Bug fixed whereby changing player to someone else and then back again, and
	then using the short name of the player, would crash both the Z and
	Glulx virtual machines at run-time.
Bug fixed whereby I7 would crash if told to understand empty text as something.
	(This is not allowed, and a problem message has been added.)
Bug fixed whereby scenes predicated on past tense actions ("Mayhem begins when
	we have waited") would cause an internal error.
Bug fixed whereby the condition "we have taken inventory" gave false positives
	after the first turn.
Bug fixed whereby nameless variables attached to activities gave internal
	errors rather than a problem message.
Bug fixed whereby creating an object called "nowhere" caused a crash rather
	than a problem message.
Bug fixed whereby grammar introducting alternative textual names for numbers
	(e.g. 'Understand "a/b/c" as 2.') could lead to I6 errors.
Bug fixed whereby vaguely named properties in adjective definitions would
	result in internal errors rather than a problem message.
Bug fixed whereby naming actions which happen to include "with" can create
	spurious out-of-play things (doing no harm, but doing no good either):
	for instance, "Unlocking the box with the key is bizarre behaviour."
	would create an object called "Unlocking the box", in addition to doing
	what it was supposed to do.
Bug fixed whereby matching the player's command against text rather than a
	topic would cause an interpreter crash at run-time.
Bug fixed whereby verbs defined as auxiliaries required participles to be
	named unnecessarily, contrary to the documentation: thus "The verb to be
	able to approach implies the approachability relation." would fail for
	no good reason.
A bug introduced by the actions rewrite in 4U65 caused player's holdall
	objects not to work properly if they were being worn rather than carried
	(as in the documentation's example "Sackcloth"). This is fixed: apologies.
In past builds the grammar token "[a number]", in Understand sentences, has
	required the number in question to be something which can be stored in
	a signed 16-bit variable, that is, to be between -32768 and 32767. This
	is correct for story files running on all versions of the Z-machine, but
	the Glulx virtual machine has 32-bit variables, so for Glulx the
	restriction is unnecessary. It has now been lifted: thus on Glulx, we
	can parse numbers in the range -2147483648 to 2147483647 inclusive.
The Inform 6 debugging verb DAEMONS (aka TIMERS), which is undocumented and
	meaningless in I7 since this lacks either daemons or timers in the crude
	I6 sense, could under some circumstances crash if tried in an I7 game.
	The verb is now removed altogether.

§11.9. What was new in build 4U65 (April 2007)

As this release was prepared, the US Supreme Court ruled that greenhouse gases were a pollutant; the Paris-Strasbourg TGV set a new world record railway speed of 357 mph, three-quarters the cruising speed of a Boeing 737; Charles Simonyi, author of Microsoft Word, became an astronaut; the genome of the macaque monkey was published; 80,000 people attended Wrestlemania 23 at Ford Field, Detroit; and Kryptonite, Superman's fictional mineral, was unearthed in a Serbian mine.

In the world of Inform, 4U65 saw a reform to the handling of actions, making it easier for actions to handle all actors equally, and the introduction of variables shared in common amongst rules which collaborate to perform a task between them. This allowed almost the entire world model of 70 built-in actions, previously hand-coded in Inform 6, to be moved into much more legible Inform 7 source text. 4U67, a Mac OS X variant, was identical except for user interface improvements.

4U67 (7 May 2007)

This build, for Mac OS X only, is identical to 4U65 except for the OS X user
interface, in which the secondary controls in the various different panels
have been harmonised into new-style bar icons. (In addition, new forward
and back arrows provide the long-requested "browser-style history buttons".)
We are releasing this now rather than waiting because it also fixes the
minor but annoying bug to do with selecting detail pages in the Actions
index (see the 4U65 release notes).

4U65 (27 April 2007)

This build once again fixes all bugs reported up to 22 April, but in fact
few were found in 4S08; and it removes a hole in the type-checking system,
to do with phrases to make decisions, but this will have affected few users.
The main aim is an across-the-board reform of how actions are handled and
implemented in Inform. Proposals (6.33), (6.35), (6.37) and (6.39) from the
January 2007 consultation document are all carried through. It is now much
easier to create actions which work equally for all actors, and which need
a complicated interaction of rules to work.

INFORM 7 FOR MAC OS X

>--> A minor bug in the OS X application means that viewing the new details
	pages for actions in the index will cause the application to think we
	have switched to the Documentation panel, with the effect that the tabs
	normally present for switching between index pages will disappear:
	switching panel and going back to the Index will cure this. Apologies
	for the inconvenience: the bug will be fixed in the next release.
Fixed bug in 4S08 for OS X only which caused Inform to create spurious empty
	Materials folders in cases where this was not really necessary (although
	this did no harm, and could not damage any existing Materials folder).

INFORM 7 FOR LINUX

i7 now has the -r story-directory and -c story-directory command-line options.
	These force it into non-interactive mode, where it compiles or releases
	the story file and exits. They can be combined with -s (for settings)
	and -p (for prefix of installed inform7 package); see the man page for
	details. It is hoped that these options will be useful for IDE authors.

INFORM 7 FOR WINDOWS

Skein and Transcript improvements:
A single click on a red badge in the skein is enough to go to the knot
	in the transcript, rather than a double click as before.
Any knot can be shown in the transcript by selecting "Show in
	transcript" from the context menu or clicking on a red badge, not just
	knots in the current thread.
A knot selected in the above way is now indicated in the transcript by
	having a thin blue border around it.
The last played knot is now indicated in the transcript by having a
	yellow border around it.
The thick line in the skein now always shows the thread that is visible in
	the transcript.
The new menu item "Play All Blessed" plays through all threads that end in a
	knot with an expected transcript.
If the expected text in the transcript tab is double clicked on, the window
	goes into edit mode, in which the expected text can be amended.
When editing the expected text in the transcript tab, holding Ctrl+Enter
	adds a carriage return to the expected text.

RULEBOOKS

Variables can now be given to rulebooks. For instance:
		The every turn rulebook has a number called accumulated bonus.
	creates a variable called "accumulated bonus", which holds a number.
	Such variables are initialised to the default values for the relevant
	kind when the rulebook starts, and are accessible only within rules
	belonging to that rulebook (or which have historically belonged to it,
	but been displaced by a "listed in... instead" sentence). Rulebook
	variables have a namespace of their own: so their names can freely
	clash with those of things, rooms, etc.) If the rulebook should
	recursively start again within itself, each new run-through of the
	rulebook has its own set of variables. In short, they behave exactly
	like "let" values except that they last for a whole rulebook, not an
	individual rule or To phrase. (This was (6.33) in the January document.)
As we can now add a potentially unlimited number of new clauses to the
	descriptions of actions to say whether or not rules apply (see below),
	Inform must refine its method for sorting rules in order of how specific
	they are. The rules on "going" are unchanged and we believe that no pair
	of existing rules not using the new features will have their orderings
	changed in any rulebook. Rules which do use new clauses are now subject
	to a new sorting principle, "III.2.4 - Action/Where/Other Optional
	Clauses". This follows the standard conventions.

ACTIVITIES

Variables can also now be given to activities. These are created just
	before the "before" rules for the activity begin, and destroyed when
	the "after" rules end (or when the activity is abandoned, though this
	is a rare occurrence). They are visible to the rules for that activity,
	and nowhere else, and again they have their own namespace; again, if
	the activity should happen a second time within its first run, that
	second occurrence gets its own copies of the variables. A simple
	example of an activity variable:
		Analysing something is an activity.
		The analysing activity has a text called first impression.
		Before analysing: now the first impression is "unremarkable".
		Rule for analysing someone: now the first impression is "living tissue".
		After analysing something (called the sample):
			say "Your professional opinion of [the sample] is that it is
			[first impression]."
		Instead of examining something (called the sample):
			carry out the analysing activity with the sample.
If an activity is called X, we can now also refer to it as "the X activity"
	for clarity's sake. (As with rulebooks called Y, which can already be
	called "the Y rulebook". This has been done in order to make the syntax
	for creating activity variables more explicit in its intentions.)

ACTIONS

Variables can also now be given to actions. These are created just before
	the "before" rules for the action begin, and destroyed when the action ends
	(by whatever means that should happen). If one action is interrupted by
	another, the new action gets its own copies of these variables.
	The names of action variables are visible only within rules in action-based
	rulebooks ("before", "carry out", etc.).
	But note that every action's variables are visible to every such rule -
	as has to be true, because we can have "before" rules which take effect
	for many different actions, for instance, and such rules might need
	access to any of their variables. In consequence, there is only one
	namespace for all action variables: if two different actions name
	a variable "item", say, clashes will occur. As a result, action variables
	should be named in a way marking out to which action they belong, and we
	recommend including the past participle of the action name - so for
	instance, "vehicle gone by", "door gone through", "sticky item taken", etc.
	A simple example of an action variable:
		The singing action has a text called the lyric sung.
		Before singing: now the lyric sung is "Destruction of the empty spaces
			is my one and only crime."
		The block singing rule is not listed in any rulebook.
		Carry out singing: say "You cheerfully warble: [quotation mark]
			[lyric sung][quotation mark][paragraph break]".
	One more warning: since any action-based rule can see all the action
	variables, it's possible to refer to the variables for an action which
	is not actually happening. For instance:
		Before doing something when the lyric sung is "Yesterday..."
	would compile without problems, but fail at run-time when any action
	other than singing was tried.
In the above example, the variable "lyric sung" was set in a before rule.
	In practice, though, it might be needed by other before rules, and then
	the order of operation of before rules would become uncomfortably
	important. To get around this, a new rulebook has been created: the
	"setting action variables" rulebook. For instance, we could write:
		Setting action variables for singing:
			now the lyric sung is "Mystifying eyes."
	This rulebook is run through before even the before rules, and could be
	used to detect the context and set variables accordingly: but it does
	not have any power to stop or change the action, and its rules should
	ideally say nothing and do nothing other than set rulebook variables,
	please. (Such a rulebook must work for any actor, not just the player:
	so if the idea is to set variables based on the local situation where
	the action will take place, look to see where the "actor" is, not
	where the "player" is.)
There is a new kind of value built into Inform: "action-name". (As its
	hyphenated name suggests, this is primarily intended for internal use,
	but there are no restrictions on it.) An action-name identifies the
	particular action but none of the nouns attached: it corresponds to
	numerical Inform 6 values such as ##Go. When an action called X is
	created, the constant value "the X action" is also created: thus
	"the looking action", "the putting it on action", etc., are all valid
	constant values of this kind. (For those who wish to make variables
	properties, table columns, etc., of this kind, the default value is
	"the waiting action", that being a sort of zero among actions.)
It is now legal to declare a "specification text" for an action, analogously
	with kinds, and this is used in the Actions index.

ACTION-BASED RULES

Inform source text describes actions with so-called "action patterns", and
	these specify among other things who the actor must be. Up to now, there
	have only been two ways to specify the actor, as in these examples:
		taking a container
		X trying taking a container
	The former means the actor must be the player: the latter allows any
	description X so long as X is not the player. Thus,
		someone trying taking a container
	allows the actor to be any person in play except the player. This made
	it impossible to write a single rule applying to any actor equally.
	A new third form has been added to allow for this:
		an actor taking a container
	For instance, we could write:
		Instead of an actor jumping: ...
	This implements proposal (6.35) in the January document.
The second form of actor description above is often found to be clumsy:
		Before X trying taking a container...
		try X trying eating the cake...
	Here the word "trying" is cumbersome. In a few cases it is needed to
	make the text unambiguous, and if the description of the actual action
	is the name of a kind of action, it is positively a good thing:
		Before X trying risky behaviour...
	but very often it is a nuisance. The word is now optional provided that:
	(a) the actor is described using a description ("someone", say, or
		"Captain Haddock") or a variable name;
	(b) the eventual action is something explicit (like "taking...") rather
		than a named kind of action (like "risky behaviour");
	(c) the action is being used in a "try" (or other phrase with an action
		as its parameter) or as the premiss for a rule.
	In other cases, "trying" will remain obligatory, but in practice they will
	be very few. The Examples for 4S08 contained some 120 uses of "trying"
	between them: this reform enabled every "trying" to be removed except one,
		Instead of someone trying disorderly conduct in the presence of
			the policeman:
	where it would clearly not be grammatical to remove it anyway.
As mentioned above, every action variable is visible from every action rule.
	But so far they have all been specific in nature to particular actions:
	for instance "lyric sung" makes no sense for non-singing actions. But
	we can also make general action variables, also visible from all action
	rules, by creating variables for the "action-processing rulebook".
	This is really a concept which has always existed - "noun" and "second
	noun" are exactly such variables. Joining them henceforth is "actor":
	the person trying the action.
>--> Thus if existing source text contains references to something called
	simply "actor", perhaps in a work of IF about the theatre, it may now
	fail to work. (Something like "stage actor" or indeed "thespian" would
	of course work instead. When we made this change it affected only one of
	the Inform examples: Ballroom, which was previously using "actor" as a
	let value in just such a rule - we changed it to read "dancer" instead.)
Although the following is a bug fix, it is worth recording as a change in
	behaviour. The room description at the end of a going action to a new
	location is not technically the result of a looking action. (It doesn't
	quite do a LOOK: for instance, it suppresses the body text for a room
	visited before, and the paragraph spacing is different, etc.) In principle,
	then, during such a room description the action ought still to be "going",
	but that means that a rule such as
		After printing the name of a person while looking: ...
	would not take effect, which is clearly incorrect. This bug has been
	fixed and such a rule now takes effect.
It has always been the case up to now that the "going" action had a special
	status in Inform: it allowed special clauses such as "... through ..."
	(for the door gone through) not allowed for any other action, and this
	behaviour was hard-wired into the syntax of the language. The ability
	to create such clauses is now available to any action. For instance,
	the following adds "...into..." and "...onto..." to Inform's syntax
	for writing rules about dropping:
		The dropping action has an object called the container dropped into
			(matched as "into").
		The dropping action has an object called the supporter dropped onto
			(matched as "onto").
		Rule for setting action variables for dropping:
			if the actor is in a container (called C), now the container dropped
				into is C;
			if the actor is on a supporter (called C), now the supporter dropped
				onto is C.
	What's new here is the "(matched as...)" clause attached to the action
	variable. We have declared that "... into X" should test to see if the
	action variable "container dropped into" matches X, and similarly for "onto".
	As a result, we can now write:
		Instead of dropping something onto something, say "Don't drop things
			onto platforms or ledges."
		Instead of dropping something into an open container, say "Don't drop
			things into open containers."
	(Note that these clauses are only descriptions of the action: it makes no
	sense to write
		try dropping A onto B;
	since the question of whether or not B is dropped onto depends on where the
	player is, and is not something we can choose. Note that this is exactly
	the same position as "going" was in before: for instance,
		try going east from the Ballroom;
	was and is not allowed, because the question of whether it's from the
	Ballroom or not depends on where the player happens to be.)
	This change implements proposal (6.37) in the January document.
In previous builds, Inform has used a messy compromise in its handling of
	check, carry out and report rules. These sometimes look to the user as
	if they are single rulebooks: as if "check", for instance, is on a par
	with "before" (which is indeed a single rulebook). In fact, for efficiency
	reasons, there are individual check rulebooks for each action, as shown
	by the diagram at 12.2 in the documentation.
	Up to now, it has been legal to write a rule like
		Check doing something: ...
	even though this clearly can't belong to any rulebook in the diagram at
	12.2. What was actually happening was that the checking stage used _both_
	a single generic "check" rulebook _and_ a family of rulebooks with names
	like "check taking". Rules defined in the Standard Rules would always go
	into the individual rulebooks, but most (not quite all) rules created by
	the user would end up in the generic "check" rulebook. While this gave a
	pretty convincing illusion that all was well, it led to violations of
	the rule-sorting principle that specific rules come before generic ones
	("check doing something" would come before "check taking an open
	container in the presence of a vehicle when the time of day is 11:13 AM",
	say), and attempts to explicitly list rules into these rulebooks could
	have odd consequences because of misunderstandings between "check" and
	"check taking", say. Moreover, for implementation reasons, the actions
	in the Standard Rules created check, carry out and report rulebooks
	with funny properties which no other rulebooks had.
	All of this has been abolished:
	- the position is now strictly as shown in the diagram at section 12.2:
		there are now no generic "check", "carry out" or "report" rules.
	- all such rules are now placed into rulebooks specific to the actions
		they belong to. Thus, e.g.,
			Check an actor going: ...
		is filed in the "check going" rulebook.
	- problem messages now result from creating rules such as
			Carry out doing something: ...
			Report dropping or taking a container: ...
		which cannot be filed into single unambiguous rulebooks;
	- the Standard Rules now use the same action-creating syntax and
		semantics as anyone else.
	The one respect in which "check A", "carry out A" and "report A" rulebooks
	are unlike other rulebooks is that rules in them do not check that the
	action is indeed A. This is partly because there is no need (if we are
	looking at the check taking rulebook, the action must be taking) but
	mostly so that a single rule can be explicitly placed in the check (etc)
	rules for more than one action at once. For instance, if we write:
		Check an actor taking (this is the hypothetical rule): ...
	and then say
		The hypothetical rule is listed in the check removing it from rulebook.
	the rule can be effective in both rulebooks: if it tested to see that the
	action was taking, it would never have any effect in the check removing
	it from rulebook, and thus it would be impractical to share rules between
	more than one of these rulebooks - which would be inconvenient to the
	Standard Rules, and also to extensions wanting to consider or abide by
	rules from one action while processing another.
We appreciate that this will cause a small amount of pain (we had to change
	7 not-specifically-action-worded rules in the Inform examples) but we
	think the pain is worth it for the simplification resulting, and most
	such rules are fairly easy to recast. For instance,
		Carry out doing something: ...
	can probably become
		Instead of doing something:
			...
			continue the action.
	without any practical change in the outcome.
Detailed index pages on individual actions now appear in the Index. We hope
	these give a truer picture of what happens to any given action, by
	showing every rule which can affect it, and making the sequence more
	explicit.
Problem message added to catch action descriptions which name unknown actors
	(e.g. "Xerxes the Otherwise Never Mentioned examining the bucket" was
	being read as simply "examining the bucket").

THE BUILT-IN ACTIONS

Inform provides about 70 built-in actions which form part of the model world.
	(That is, not counting out-of-world actions such as saving the game.)
	In previous builds these have been implemented using a special action
	definition syntax reserved for use of the Standard Rules only, and
	consisting essentially of tables of rule names against I6 identifiers:
	all the rules involved were implemented by I6 code. This was bad because
	it meant that the built-in actions were treated as special in all sorts
	of ways (not a very clean design technique) and because it was quite
	hard to work out how the built-in actions worked, since one needed to
	be able to puzzle out the I6 code at the bottom of all this. On the
	other hand, it had the advantage of speed, since Inform did not have
	to read and compile the built-in action rules from I7 source text.
	As discussed in the January document at (6.39), there are trade-offs
	here, but we have now bitten the bullet and reimplemented all of the
	(not out of world) actions in I7 source text.

THE GOING ACTIONS

The "going" action is the second most complex in Inform ("looking" probably
	takes the palm) and the re-implementation in I7 has turned up two bugs
	which have also been fixed. In addition, numerous rules have been
	renamed or removed:
	- the can't go through concealed doors rule has been renamed
		the can't go through undescribed doors rule ("undescribed" being
		the I7 word for what I6 called "concealed");
	- the following rules have been abolished:
			set up going rule
			check to see if in a vehicle rule
			determine direction property rule
			print textual map connections rule
			consult routine map connections rule
			determine what's through door rule
		These all clumsily worked out what we now regard as action variables,
		except for the textual and routine map connections rules, which were
		to provide backwards compatibility with traditional I6 use of the map
		properties, which I7 doesn't recognise or use; however, we retain the
			determine map connection rule
		whose purpose now is to recalculate the "room gone to" variable
		immediately before the "can't go" check. (This is done because people
		often use before rules to modify the map, in order to make dynamic
		map structures which respond to movement.)
	- in the check rules, the can't go that way rule has been moved to after
		the rules checking on undescribed and closed doors: after all how is
		one to know that a door leads nowhere if it is closed? But if you do
		succeed in opening such a door and try going through it, the
		traditional I6 response "You can't, since the X leads nowhere."
		has been restored in place of I7's recent practice of simply saying
		"You can't go that way."
A bug has been fixed which caused a person other than the player getting
	off something to be reported as if he were getting out of it.

THE LOOKING ACTIONS

The following rules have been abolished:
		consult LookRoutine entry point rule
		standard searching rule
	The former provided vestigial I6 support; the latter in all cases did
	nothing.

THE OBJECT MOVEMENT ACTIONS

Under the taking action, actors other than the player can now also use a
	"player's holdall" (if carried) to overcome carrying capacity limits.
The following rules have been abolished:
		default inventory style rule
		check let-go-before rule
		check let-go-after rule
		check receive-before for supporter rule
		check receive-after for supporter rule
		check receive-before for container rule
		check receive-after for container rule
	These provided vestigial I6 library support and are irrelevant for I7.
The following rules for the removing it from action have been abolished:
		can't remove from closed containers rule
		check after-rules for taking too rule
		standard report removing rule
	They had no effect in 4S08, having been pre-empted for some time by the
	automatic conversion of removing to taking: they had been left in the
	Standard Rules by accident but could never have any effect.
Similarly: the
		can't insert component parts rule
	was redundant in 4S08 and has been removed.

THE ACTIONS WHICH CHANGE THE STATE OF THINGS

When the opening action by the player is successful, Inform shows the contents
	of what was opened, provided it was opaque (so that the contents were
	previously not visible) and provided that the player is not inside it.
	The rule causing this was called the
		reveal any newly visible exterior rule
	which is a misleading - it has been renamed the
		reveal any newly visible interior rule

THE ACTIONS INVOLVING OTHER PEOPLE

The following rules have been abolished:
	check life property for giving rule
	check life property for showing rule
	check life property for waking rule
	check life property for throwing at rule
	check life property for attacking rule
	check life property for kissing rule
	check life property for answering rule
	check life property for telling rule
	check life property for asking rule
	check thrown-at rule
	These provided vestigial I6 library support and are irrelevant for I7.
As for the do-nothing actions (see below), these are now also handled
	symmetrically for all actors. (Thus, for instance, the block attacking
	rule now blocks any actor attacking any other.)

THE DO NOTHING ACTIONS

The actions indexed as "Actions which always do nothing unless rules
	intervene", which consist only of a single checking rule to block them,
	behaved asymmetrically in previous builds since they blocked the
	action for the player, but allowed it to run through untouched and
	with no rules applying for any other actor. This could result in odd
	transcripts such as:
		> SING
		Your singing is abominable.
		> PETER, SING
		>
	...because no rules at all fire for Peter trying singing, so the
	action succeeds by default, and nothing is said or done.
	In this build, the blocking rules for do-nothing actions now block
	all actors. Thus:
		> PETER, SING
		Peter is unable to do that.
	or with ACTIONS switched on:
		> PETER, SING
		[asking Peter to try singing]
		[(1) Peter trying singing]
		[(1) Peter trying singing - failed the block singing rule]
		Peter is unable to do that.
		[asking Peter to try singing - succeeded]
	This affects the actions:
		Saying yes, Saying no, Burning, Waking up, Thinking, Smelling,
		Listening to, Tasting, Cutting, Jumping, Tying it to, Drinking,
		Saying sorry, Swearing obscenely, Swearing mildly, Swinging,
		Rubbing, Setting it to, Waving hands, Buying, Singing,
		Climbing, Sleeping
>--> While this is much more logical, and means that every (non-out-of-world)
	action in the Standard Rules now works equally for all actors, it does
	mean that a rule in the form:
		After Peter trying singing: ...
	will no longer work, because Peter's singing action will be blocked and
	never reach the "after" stage. To get around this:
		Instead of Peter trying singing:
			...
			the rule succeeds.
	Note the last line, forcing the action to be considered a success: actions
	stopped by instead rules are normally deemed to fail, but making this
	succeed means that no "Peter is unable to do that." text will be printed.

PHRASES

Inform has been made a little stricter in when it allows certain phrases
	to be used. For instance, the phrase "decide on X", which chooses a
	value X, is now only allowed in a phrase "To decide which ..." - of
	course it didn't make sense anywhere else, but this is now policed.
	Similarly, "decide yes" is now restricted to phrases which need to
	decide if something is or isn't true, and so on. (We're pretty certain
	that this new check only rejects uses which do not at all achieve what
	they look as they ought to do.)
Similarly, "decide on X" now checks the kind of X to see if it matches the
	required kind. This may produce problems either at compile time, or
	at run-time. Note in particular that "nothing" is forbidden as a
	value to decide on if we are required to produce a particular kind
	of object such as, say, a "room", but is allowed if we are only required
	to produce an "object". (This agrees with the conventions used for
	variables.)
Finally, phrases to decide a value now return the default value of the
	appropriate kind if execution runs through to the end of the definition
	without having reach any "decide on X" phrase.
Problem message added to explain why two bracketed phrase terms immediately
	next to each other, with no word in between, is against the rules -
	e.g. "To combine (X - a number) (Y - a number)". (Previously Inform
	would allow the definition, but then never recognise it in source text,
	which was not a very helpful way of rejecting it.)
Bug fixed whereby setting up a phrase "To decide what X is ..." might
	read X as a description of a thing rather than a kind of value in
	cases where X is both the name of such a kind, and also part of the
	name of a thing. (For instance, if there is an object somewhere called
	"number puzzle", then a phrase "To decide what number is ..." was
	being misread as if its type had to be always the number puzzle object,
	not a number.)

PROPERTIES

Two changes have been made to the way that assertions about either/or
	properties of kinds are read. To demonstrate, consider the sentence in
	the Standard Rules which reads
		A thing is usually inedible.
	What if we want to contradict this? In previous builds, we could write:
		A thing is never inedible.
	This worked, but owing to a bug,
		A thing is always edible.
	did not work - this bug has now been fixed. In either of these sentences,
	we undo the sentence in the Standard Rules by writing a sentence which is
	more definite - certain ("never", "always") rather than merely likely
	("usually"). But what if we don't want extra certainty? In previous builds,
	writing
		A thing is usually edible.
	would have no effect, because when two inferences are drawn about the
	same property which contradict but which are each uncertain, the original
	first-drawn inference is allowed to stand, and the second is ignored.
	This convention has been reversed in the case of inferences drawn about
	properties of kinds:
		A later uncertain assertion about a property of a kind beats
		an earlier uncertain assertion about the same property.
Problem message added for saying that a kind has an either/or property
	without previously having said that it can have that property. This
	would usually not work anyway, but in previous builds, saying "K is
	usually openable." would make it so: Inform now insists that we write
	"K can be openable. K is usually openable.", as the documentation implies.
	(The examples A Haughty Spirit and Disappointment Bay 12 needed to be
	corrected in just this way.)
Problem message added (rather than internal error) to reject implications
	where the implied outcome is a value property rather than a simple
	either/or property like open/closed.
Problem message added to explain why "D can be X or Y" makes no sense if
	D is something qualified by adjectives - e.g. "An open door can be
	rickety or sturdy" makes no sense because the door still has to have the
	property even at times when it is not open. (Previously Inform simply
	ignored the adjectives, and assigned the property to the underlying kind.)
Bug fixed whereby saying "now X is P" could be misconstrued if P refers to a
	property but does so inexplicitly: for instance, "now X is the colour of
	the button" would try to change X to be equal to this colour whereas
	"now X is green" would simply change the colour of X. Both forms now
	change the properties, not the identity, of X.
Bug fixed whereby large numbers of either/or properties created for things,
	followed by an either/or property being created for rooms, would sometimes
	lead to bogus programming errors at run time.
Bug fixed whereby creating a new either/or property but giving its antonym
	as an existing one would sometimes wrongly be allowed, leading to
	peculiar run-time problem messages. (E.g. writing "The Catwalk can be
	flaming or unlit." causes this, because "unlit" is already the antonym
	of "lit", a property of things.)
Bug fixed whereby certain complicated forms of property assignment in
	assertions could cause an internal error (e.g., "Blinky is an ephemeral
	ghost with reaction "Boo!".").

EXAMPLES

New example "Croft" added to demonstrate action variables.
The now usually unnecessary word "trying" (see above) has been removed from
	most of the examples involving actions.

MISCELLANEOUS

Problem messages added for creating table columns whose names are articles
	or existing values such as literal numbers.
Problem message added (rather than internal error) for initialising a
	K that varies (where K is a kind) to the value "nothing". This is legal
	for an object that varies (though in 4S08 a bug blocked this), but not
	where the variable always has to hold something of a given kind.
Problem message added (rather than internal error) for an attempt to total
	the column of a table rather than a property.
Problem message added (rather than eventual I6 errors) for defining plurals
	using quotation marks, e.g., writing 'The plural of "coin" is monies.'
	rather than 'The plural of coin is monies.'
Better problem message added for close square brackets used wrongly as
	literals in quoted text.
Bug fixed whereby continuations of tables would sometimes wrongly be reported
	as containing columns not found in the original tables, and would
	sometimes (even when they worked) have their columns incorrectly matched
	up to the original table, in cases where the columns had been reordered.
Bug fixed whereby a compound sentence asserting a relationship both with a
	new specific object and also a new object described only generically by
	naming its kind, as in:
		The big box contains a container and Peter.
	...would fail complaining of an overly complicated relationship.
Bug fixed whereby the word "visible", redundantly used in a grammar token
	as in e.g.
		Understand "inspect [any visible thing]" as examining.
	would cause a hang because I6 scope loops can't be nested.
Bug fixed whereby hanging dependent clauses which depended on local variables
	would sometimes be construed unexpectedly. (This really only affected
	descriptions which were not very useful anyway, e.g., "the number of
	things worn by X which fit Y", which is not good style since it in
	fact evaluates the number of things worn by an X-which-fits-Y - that
	is, the "which fit Y" clause appends to X and not the things.)
Bug fixed whereby the "after reading a command" rulebook would sometimes
	fail to be able to replace matched text in a command in cases where it had
	been rewritten as a result of a "Which do you mean...?" question.
Bug fixed whereby the character @ could not be parsed at run-time, and an
	attempt to write something like 'Understand "@" as the giant at-symbol'
	would produce I6 errors.
Bug fixed whereby expressions containing more than one bracketed subexpression
	would sometimes be misparsed: e.g. "let a be (x + y) / (x - y)" would
	produce spurious problem messages despite being legal syntax.
Bug fixed whereby Definitions involving looking up entries in tables would
	sometimes compile through I7 but cause I6 errors.
Bug fixed whereby calculations of the other side of a door, or the direction
	taken by a door, would sometimes be incorrect in darkness.
Bug fixed whereby problems to do with variable initialisation were
	reported at the correct sentences but under the wrong headings.

§11.10. What was new in build 4S08 (March 2007)

As this release was prepared, the fence dividing Cyprus was dismantled at last - just as, for lack of such a fence, Switzerland accidentally invaded Liechtenstein; Mr Stark of California became the first Congressman in US history to declare his non-belief in God; the UK legislated for a 60% cut in carbon emissions by 2050; enigmatic lakes were imaged on Titan, and heavy snow fell in Kashmir; Martha Jones became Doctor Who's first black companion (if we don't count Frobisher the penguin); and the Bornean Clouded Leopard was declared a new species.

In the immortal words of Robert Heinlein: "Bugs, Mr. Rico! Zillions of 'em! I'm a-burnin' 'em down!" Build 4S08 saw the first release of I7 for Linux, and there were useful reforms of the default value for kinds of value and of the paragraph breaking algorithm, but this was primarily a maintenance release. This release closed all 335 open bug reports, and marked the end of the experimental early days since the original Public Beta release.

4S08 (25 March 2007)

This build represents a substantial update in five respects: it fixes all
known bugs - some 335 bug reports have been acted on since 4K41 and the
database of open bug report forms is now empty for the first time since
the public beta was released as 3K27; it introduces the first batch of
improvements proposed in the January 2007 consultation document (called
simply "the January document" below); it makes the first real reform of
paragraph-spacing since 3K27; it makes the first tentative steps towards
Inform 7 for Linux, though at present as a command-line system without the
graphical user interface; and it is accompanied by more supporting
materials than previous builds, notably free-standing documentation and a
formal grammar.

Inevitably it has a lengthy change log, which is grouped thematically below.
Enough minor changes have been made to the interpretations of syntax that
authors of any large work in progress will find at least one or two things
they need to change. Possible trouble-spots are marked with an arrow >-->.

INFORM 7 FOR LINUX

Inform 7 is now available for Linux for the i386, ppc, armv5tel, and s390
	architectures. All compilers and interpreters supplied as part of the
	Inform 7 package are statically linked and should have no dependencies
	beyond stdio. The i7 shell itself is written in Perl, but does not
	require any modules not customarily shipped as part of the Perl
	distribution. The only additional dependency is the uuidgen program;
	this is part of the ext2tools package and has so far been present as
	part of the default installation on all systems we have examined.
	Installation instructions can be found in the file INSTALL, and
	operational instructions in README or the manual page installed by
	the Inform installer.
Users on Intel 386-and-descendants machines should download the package
	I7_4S01_Linux_i386.tar.gz. All users on other architectures
	should download I7_4S01_Linux_all.tar.gz. The difference between
	these two is simply whether or not non-i386 compilers and interpreters
	are bundled - the "all" version will function perfectly well for Intel
	users, but it is substantially larger to download. The correct set for
	your architecture will be detected at installation time.

INFORM 7 FOR MAC OS X

The OS X application contains a number of bug fixes in the CocoaGlk layer,
	that is, to the underlying interpreters used in the Game panel.

INFORM 7 FOR WINDOWS

Pasting text into the source panel should no longer lose any trailing
	carriage returns.
Echo streams are supported in the game panel's Glk implementation.
Skein and transcript improvements:
	Knots that have been played in a game session are coloured
		yellow, and all other knots are coloured green.
	Knots with blessed text are lighter than those without.
	If the last played text for a knot does not match the blessed text,
		the node is shown with a red badge. Double clicking the red badge
		goes to the appropriate point in the transcript tab.
	The skein's context menu has been reworked to match the OS X
		application.
	A confirmation dialog appears when deleting a locked knot.
	Threads are automatically locked when blessed or when a label is added
		or changed.
Bug fixed whereby blue "link to documentation" icons were, in the most recent
	Windows build, in some cases off by one or two sections.

SUPPORTING DOCUMENTATION

As from this build, we are uploading the "Writing with Inform" documentation
	in two plainer formats than those already available: plain text, and
	a zipped archive of minimally-tagged HTML files. We hope that this will
	make reference easier for those using screen-reading software, in
	particular. (This was (6.7) in the January document.)
We are also uploading a PDF document extracted from the NI source code which
	specifies the formal grammar read by NI (or rather, that part of it not
	already specified in the Phrasebook index): in the January document we
	expressed scepticism that this would really be useful, but responders
	disagreed. We continue to be sceptical, but it wasn't too hard to generate
	the document, so here it is.

EXAMPLES AND EXTENSIONS INCLUDED WITH INFORM

Examples:
	Added "Apples" to demonstrate "asking which do you mean" rules.
	Added "Ahem" to demonstrate phrases with alternate elements
		(the 300th example to be written).
	Added "Pages" to demonstrate phrases pertaining to specific values
	Added "Hover" to demonstrate interior descriptions of vehicles placed
		before the rest of a room description.
	Added "Walls and Noses" to demonstrate advanced modification of the
		disambiguation question.
	Added "Electrified" to demonstrate modification of the action-processing
		rule sequence.
	Added "Straw Boater" to demonstrate testing for the default text "".
	Added "Ferragamo Again" to demonstrate phrases applying to specific objects.
	Added "Mattress King" to demonstrate modifying the action to push things
		between rooms.
	Added "Lollipop Guild" to demonstrate turning off implicit takes when
		eating an object that is fixed in place.
	Modified "Abolition" to reflect changes in the handling of "to" in
		action names.
	Corrected "Neighborhood Watch" to add a check for cases where the door
		is already locked or unlocked.
	Assorted minor changes to examples to handle spacing changes.
Extensions:
	Locksmith: advanced to version 3 and made modifications due to the new
		spacing mechanisms.
	Glulx Image Centering: Corrected documentation.
	Rideable Vehicles: advanced to version 2. Rules added for people other
		than the player to mount and dismount vehicles; rule names given to
		the existing rules, so that they may be more easily revised or
		replaced by the user of the extension.
>--> Plurality: advanced to version 5, and forms of phrases changed to is-are
		(etc) rather than is/are. This will require authors using Plurality
		to do a search and replace to change formats. (Sorry.)
>--> Complex Listing: advanced to version 4, and forms of phrases change to
		is-are (etc) rather than is/are. This will require authors using
		Complex Listing to do a search and replace to change formats. (Sorry.)
		Behavior of "[prepared list]" changed to use no articles, just as
		"[list..." uses no articles now in Inform by default. More flexible
		phrasings added to several phrases, so that "prepare list..." is
		accepted as well as "prepare a list...", and "register the things..."
		is accepted alongside "register things...".
	Menus: advanced to version 2. Added options allowing up and down arrows
		to function properly under Glulx.

KINDS OF VALUE

When Inform has to initialise variables or property values, but the source
	gives no value, it uses a default value for the appropriate kind of value.
	For instance, a number is 0 unless otherwise specified, and a text is
	the empty text "". The Kinds index (in which a number of minor bugs have
	been fixed) now tabulates the default values used for each kind of value
	which can be stored in variables or properties. (This and related changes
	following cover (6.34) in the January document.)
It is now legal to declare a "specification text" for a kind of value,
	analogously with kinds of object, and this is used in the Kinds index.
New scene "Entire Game" created which, as the name implies, contains the
	whole of play except for the posthumous restart, restore or quit
	conversation. (This is the default value for scenes.)
The constant "nothing" now means the absence of an object, in the context
	of testing an object-valued variable or property to see if it holds the
	default value for "object", and is also useful when looking at the
	result of things like "best route from the Drawbridge to the Keep"
	(if there is in fact no route).
Problem message added to explain more fully when an action name is used as a
	new value (for instance, if we write "Lamp strength is a kind of value.
	The lamp strengths are burning and gone out.", then "burning" would clash
	with the name of the action).
Bug fixed (in consequence of above) whereby creating but not initialising a
	scene variable or property caused an internal error.
Bug fixed whereby comparison of a text with "" often gave false negatives.

NAMED VALUES

>--> When ambiguous values occur, local variable names (created by 'called'
	or by 'let') are now given priority over other possibilities.
When a "(called...)" name appears in a rule, any article used will not be
	taken as an immutable part of the name. For instance, "Instead of examining
	a door (called the portal): ..." will now create a temporary value called
	just "portal", not "the portal". Of course, "the portal" can still be
	used to describe this value, but now being parsed as "the" + "portal",
	and this means that text substitutions "[a portal]" and "[the portal]"
	can differ.
Problem message added to forbid the use of "(called ...)" when giving a
	complex range of things to be repeated through: this was accidentally
	allowed in previous builds, and produced subtly incorrect results.
Problem message added (in place of internal error) to catch attempts to use
	local values created by 'let' or 'repeat' or 'called' in past-tense
	references which pertain to times when they did not exist.
Problem message added to report contradictions of kind when a variable is
	declared more than once and each time as a kind of object.
Bug fixed whereby conditions involving negated existential quantifiers, and
	giving called names to the results, would sometimes incorrectly fail.
	(For instance, "a person who is not wearing anything" would work but
	"a person (called the extrovert) who is not wearing anything" would fail.
	The negated existential here is the clothing being worn - which is
	required not to exist.)
Bug fixed whereby "a random D", where D is a description including a
	"(called ...)" clause, would (although legal) cause I6 errors.
Bug fixed whereby variables set up with non-existent kinds ("Z is a
	bogosity that varies") would sometimes produce internal errors rather
	than a problem message.

TEXT

>--> Inform has a fairly delicate mechanism for placing paragraph breaks
	automatically at "the right" points in text produced by various different
	rules. Its aim is to save the writer from having to think about this.
	Four main defects have been found in the original Public Beta algorithm,
	and in this build we address all of them. We believe the result is a
	better system, but it does mean that the dodges people have used up to
	now to compensate for faults of the old algorithm will need to be
	removed or changed. (We had to remove a dozen or so spurious
	"[line break]"s from the Examples, for instance: the end result was
	much less intervention in how paragraphs were being broken, and this
	suggests that the automatic system is now more trustworthy.) This
	addresses proposal (6.45) in the January document.
When defining a new text substitution, it is now legal to add "-- running on"
	as a note at the end of the preamble. The effect of this is that any
	newline implied by the immediately preceding text is ignored. Thus
		To say note -- running on: say "(1)".
	can be used in text such as
		"I prefer to avoid footnotes.[note]"
	without a newline being forced after the full stop under the "sentence
	ending punctuation at the end of literal passages of text implies a
	newline" convention.
This has been applied to the following character-level text substitutions in
	the Standard Rules:
		[unicode N]
		[bracket]  [close bracket]  [apostrophe]  [']  [quotation mark]
		[line break]
		[conditional paragraph break]  [paragraph break]  [run paragraph on]
		[bold type]  [italic type]  [roman type]
		[fixed letter spacing]  [variable letter spacing]
As a result, [line break] now does just and only what it suggests: prints a
	line break, regardless of circumstances, and with no side-effects for
	subsequent paragraph breaking. [paragraph break] is now the better way
	to force a paragraph break, and various bugs have been fixed so that it
	can more reliably be used in mid-string, in table entries, in values,
	more than once in the same quoted text, etc.
A new form of paragraph break has been created for one special circumstance:
	printing clarificatory text after a command, when we are guessing what
	was meant. For instance:
		> N
		(first opening the Wicket Gate)
	Conventional spacing here is that text should immediately follow on the
	next line, unless we are going to a different room and looking around,
	in which case a line break should be added. We can get this spacing
	convention using the text substitution "[command clarification break]";
	for instance:
		say "(first opening [the noun])[command clarification break]";
Another change made to the paragraph breaking mechanism removes the previous
	discrepancy between the effect of printing an object property which does
	contain a text substitution, and one that doesn't; and similarly for texts
	used as values in miscellaneous other circumstances.
Finally, the text substitution "[no line break]" suppresses a line break
	which might otherwise arise under the sentence-ending punctuation rule
	as it applies to literal text in a "say", so:
		say "This is not the end![no line break]";
	leaves the printing position after the exclamation mark.
>--> The meaning of the text substitution "[list of ...]" has been changed so
	that it now lists the items referred to without articles: for instance,
	it might produce "apple, orange and nectarine" rather than "an apple,
	an orange and a nectarine". (Which is what would have been produced in
	previous builds: to obtain the articled list, use "[a list of ...]"
	or "[the list of ...]" according to whether indefinite or definite
	articles are wanted. This was (6.21) in the January document.)
The text substitution ['] is now synonymous with [apostrophe], and makes
	extended runs of Cockney dialogue easier to type ("put down that bleedin[']
	[']eavy Joanna", and so forth).
Problem message added for using 'say' (or a text substitution) to print a
	value of a kind which cannot be printed up (such as a parsing topic).
	(This already produced a problem message, but a generic unhelpful one.)
Problem message added for using a comma inside a text substitution, which
	in previous builds concatenated the items in the substitution - but that
	was almost invariably not what people expected, and it was being reported
	as a bug. (Thus previously "[1, 3]" was a legal substitution and printed
	up "13", for example.)
Bug fixed whereby text substitutions which ended with one digit and were
	immediately followed by another digit in literal text would be corrupted.
	(For instance, in "[if x is 2]2".)
Bug fixed whereby the little-used but legal "say X, Y, Z" comma-separated list
	form of "say" would lose some text substitutions occurring in terms in the
	list before the final one.
Bug fixed whereby replacing or cutting snippets in the player's command could
	cause spurious line breaks to be printed if the new text contained text
	substitutions.
Bug fixed whereby long texts containing almost the maximum legal number of
	text substitutions could crash NI.
Bug fixed whereby improperly closed double-quoted text, e.g., "'fish"' (note
	the mismatch of quotation marks) could produce I6 errors rather than a
	problem message.
Bug fixed whereby specifying literals involving double-quotes could cause
	I6 errors (e.g., writing: 5'10" specifies a height). Still not a good
	idea since it throws syntax-colouring, but it's not meant to be illegal.
Bug fixed whereby the activity "printing the name of something" now applies
	to the player - previously, it applied to everything except the player.

PROPERTIES

>--> The ability to create a property without specifying its kind (by writing,
	say, "A room has a property called history.") has been withdrawn. This
	was an undocumented syntax which gave the property the kind
	"miscellaneous-value", whose use has for some time been deprecated.
	(In almost all cases, the property will be storing either objects or text,
	and should be given a kind accordingly. The Standard Rules no longer
	use properties or variables of this kind, and this change improves the
	reporting of problems in assertions using the properties in question.)
>--> We can now test to see if an object provides a property using the syntax
		if O provides the property P
	so for instance "if the noun provides the property lockable" - which a
	container or door would pass, but which a person would not, and so on.
	This was previously allowed as "if O has a/an P", but that was too
	ambiguous and has been withdrawn. (It made grammatical sense only for
	value properties P. "if the noun has a lockable" not only read badly,
	but due to a bug (now fixed) it also compiled to an incorrect test.)
An indefinite article is now permitted in a negated assertion which sets the
	converse of an either/or property: thus "X is not a P" is permitted,
	just as "X is not P" would be. Grammatically this is incorrect if P is
	an adjective, which is what the original design of Inform intended, but
	people occasionally use nouns in an adjectival sort of way - for instance,
	"A monkey can be a hairy critter. The ape is a monkey in the Serengeti.
	The ape is not a hairy critter." (Here P is "hairy critter".) We continue
	to think this is poor style, but since the assertion would be allowed
	if in the positive sense, it seemed better to legalise it in the negative
	sense as well.
Problem message added for writing 'X can have P' rather than 'X has P' to
	create a property, since this is a common mistake and currently produces
	rather unhelpful problem messages.
Problem message rather than I6 errors for using a non-constant value (say,
	a variable) as the initial value of a property.
Problem message rather than I6 errors for creating a property with a name
	consisting solely of an article (e.g.: "A thing has a number called the."),
	and similarly for property names containing commas or quoted text.
Problem message added to clarify what kind of contradiction has occurred
	when the same property is set to different values in different sentences.
Problem message added to report that new either/or properties or possible
	conditions (created by 'X can be Y or Z'-style sentences) clash with
	existing meanings - something which previously led to peculiar errors.
Run-time problem messages now result from attempting to change (with "now")
	either/or properties for objects which are not permitted to have them.
Run-time problem messages now result from attempting to read or write value
	properties for the "nothing" non-object. (Previously writes were ignored
	and reads produced 0, but this was unsafe for kinds of value where 0 was
	not valid, and in any case allowing people to treat "nothing" as an
	object seems unwise.)
Bug fixed whereby "now X is Y" would compile I6 code which failed at run-time
	if X is a K that varies (K being some new kind of value) and Y is one
	possible value of K, in circumstances where K is also a property of objects.
	For instance, suppose we have colours blue and red, and colour is a
	property of cars. Suppose "jalopy" is a car that varies, "hue" a colour
	that varies. Then "now the jalopy is blue" and "now the hue is blue" are
	semantically very different - one changes a property, the other assigns
	a value - and this difference was being missed, hence the bug.
Bug fixed whereby tests of whether something has an either/or property would
	compile to code failing at run-time (whereas value properties would work).
Bug fixed whereby I6 errors might result from heavily ambiguous source texts
	where confusion could occur between wording of one phrase which does not
	include a property and another which does, where that property usage is
	itself incorrect.
Bug fixed whereby giving a property of something with an additional clause
	requiring it to be somewhere (e.g. "the Portable Lamp in the Yard")
	would cause an internal error rather than produce a problem message.
Bug fixed (see KINDS OF VALUE) whereby creating but not initialising a
	scene property caused an internal error.

DEFINED ADJECTIVES

In "Definition:" sentences, it's now possible to refer to the object to which
	the definition applies as "he", "she" or "they", or indeed "him", "her"
	or "them", and no longer only as "it". Thus "Definition: a person is other
	if he is not the player." is legal, as is, and let's not squabble over the
	rightness of this, "Definition: a person is other if they are not the
	player." The accusative forms mean that "Definition: a person is a target
	if the player can see him.", etc., should also work now.
A problem message has been added to forbid ambiguous settings of
	properties for adjective-qualified kinds, as in "The description of an
	open door is ...": such a sentence looks as if it might create a rule
	which would dynamically check the door during play, but in fact being
	an assertion it only looks at the initial state. (In previous builds,
	a bug caused this to set the description for every door, initially open
	or not: rather than fix this, it seemed better to forbid this form of
	assertion entirely, since if it worked it would still not do what it
	looked as if it did.)
Similarly, a problem message has been added to forbid assertions at compile
	time about adjective-qualified kinds where the adjective cannot be
	determined until run-time (because it is created with "Definition:" and
	involves some computation to decide whether an object satisfies it or not).
Problem message rather than I6 errors for using "change O to P" where O is
	an object and P is a defined adjective (rather than a property), so that
	it is not logically possible to change P by merely saying so.
Run-time problem messages now result from attempting to change (with "now")
	adjectival properties which cannot be forced to come true, since their
	truth is governed by a fixed definition.
Bug fixed whereby definitions of adjectives based on testing a property to
	see if it equals some specific value (e.g. "Definition: A container is
	standard if its carrying capacity is 7.") would in fact test a range
	of values with this as boundary (e.g. capacity <= 7).
Bug fixed whereby definitions of adjectives with a specific object as domain
	(e.g. "Definition: the Ballroom is dusty if...") would not always be given
	priority over definitions with a more general kind as domain (e.g.
	"Definition: a room is dusty if...").

HEADINGS

Problem message added to report that a heading stops before the end of its
	line, something which generally happens when a full stop has been misread.
Bug fixed whereby an author name including a comma would be mis-spaced in the
	banner (for instance if the first line is: "Trio" by Rod, Jane and Freddy).
Bug fixed whereby a heading which followed a long comment without an intervening
	skipped line would sometimes wrongly be rejected as containing a line break.

ASSERTION SYNTAX

When ambiguous assertion sentences occur, where more than one word is in
	principle valid as the primary verb, we now assume that "to have" is the
	most likely verb, followed by "to be", and then the other built-in verbs.
	This replaces the previous doctrine that the earliest valid verb in the
	sentence was the true one. For instance, "The last support is a thing
	that varies." is now read with "is" as the primary verb, not "support".
Problem message added to catch what look like mistaken uses of the pronoun
	"they". (E.g., in "A and B are things. They are portable.", I7 can't
	cope with "they" as meaning the collection of A and B, and would previously
	latch onto some other meaning, e.g., either A or B alone.)
Problem message added for using 'every' on the wrong side of the verb in an
	assertion sentence (mostly to take the opportunity to explain how to
	reword such a sentence so that it works).
Problem message added (in place of internal error) to catch misreadings of
	'of' leading to misunderstood property values in assertions, e.g. in
	"The dining room is a room in the house east of the kitchen."
Problem message added (in place of internal error) to catch relative clauses
	which seem to express a location in a way too complicated to follow, e.g.
	"Sleeping Beauty is a woman who is asleep in the Spinning Tower."
Bug fixed whereby listing complicated descriptions of things which involved
	at least one negated property would cause I6 errors.
Bug fixed whereby negated relative phrases would mistakenly be read as
	positive, so that for instance "The broken box is a container which is
	not openable." would, very unfortunately, make an openable container.
Bug fixed whereby implications in the form of "An X is usually Y", where X
	involves a kind and also properties, would in fact cause all things of
	that kind to be Y, whether they matched or not. (For instance, "an open
	container is usually lockable" would cause all containers not otherwise
	described to be lockable.)
Bug fixed whereby "some" as an article would be confused with "some" as a
	determiner in such a way that the actual object being referred to was
	lost: this especially happened with singular mass nouns, e.g. "some clay",
	where "if the player is carrying some clay" would be misread as "if the
	player is carrying something" if the clay was a single thing, not a kind.
Bug fixed whereby the assertion "X is here." might fail if X had already
	been defined before the room denoted by "here" had been declared; and
	also another case in which the room, having been mentioned long ago,
	is only recently made the subject of discussion again.
Bug fixed whereby descriptions with multiple relative clauses, some of them
	ambiguous, could result in an interpretation which is none of the
	possibilities an English speaker would choose. (This is difficult to
	define, but for instance, "a random woman who is not Zoe in the location
	of Zoe" was being interpreted in such a way that "in the location of Zoe"
	was being applied neither to the random woman, nor to Zoe. Inform now
	applies it to Zoe. This affects only a handful of sentences - e.g., it
	makes no difference to any sentence in any of the examples - and only
	to sentences which are fairly evidently risky in the first place.)
Bug fixed whereby object names containing "with" could, in the middle of
	lists, crash NI.

PLURALS

The previous requirement that a plural definition sentence had to appear before
	it could be used has been lifted. Such definitions now apply throughout
	the source text, wherever they appear. This avoids traps like the following:
	"Clothing is a kind of thing. The plural of clothing is clothes. Clothes
	are wearable." In previous builds, this would have created an object called
	"Clothes", which is wearable but is not of the kind "clothing", and a
	kind called "clothing" with the plural "clothings".
Bug fixed whereby non-specific references to properties in "every turn" rules
	would be taken to be properties of the I6 library placeholder object,
	usually leading to strange I6 veneer errors: they are now assumed to be
	properties of the player. Thus for instance
		A person can be poised or flustered. Before jumping: now the player
		is flustered. Before waiting: now the player is poised.
		Every turn when flustered: say "You feel flustered."
	...now works as expected.
Bug fixed whereby ordinal numbers were being taken as counting determiners
	for noun phrases, so for instance "2nd Room" was being read as if it
	had the same meaning as "two rooms". This led to confusion when room
	names (in particular) began with an ordinal, e.g., "2nd Floor Balcony".
Bug fixed whereby words which indicate plurals will not always be recognised
	as such if the object whose name is being parsed has a complex range of
	possible names (i.e., if I7 is obliged to compile a parse_name routine to
	handle it).

RELATIONS, PARTS AND REGIONS

>--> Some people have had problems with the relation "in", when applying it
	to regions. Inside Inform, there are two forms of "in": there is object
	containment - the ball is in the box, the box is in the Summer House -
	and also region containment - the ball is in the Garden Area, the
	Summer House is in the Garden Area. These two forms of "in" are not
	as similar as they look - object containment has the property that a given
	X can be "in" Y for at most one possible Y, and Inform makes heavy use
	of this in optimising searches and loops; but region containment does
	not, becase the Summer House could be in the Garden Area and also in
	the super-region the Outside World, say. In practice, Inform always
	reads "X in Y" as object containment except when Y is the literal name
	of a region. Up to now, there has been no way to describe the hidden
	internal relation for region containment: in this build, we provide
	"regionally in" to allow users to clarify what sense they mean. Thus
	"repeat with P running through the rooms regionally in R begin; ..."
	makes clear that we are talking about all rooms in R (and not, for
	instance, rooms immediately in R rather than in some subregion of R).
"A part of" is now synonymous with "part of": for instance, one can now write
	"if the tail is a part of the fish", with the same effect as "if the tail
	is part of the fish".
Problem message added to prevent foundational errors involving an object being
	indirectly a part of itself ("X is a part of Y. Y is a part of X.", and
	so on).
Problem message added to report that a region has been placed inside more than
	one other region. (This is forbidden because it could lead to configurations
	whereby regions overlap, whereas they are required always to include each
	other or else be disjoint.)
Problem message added for an attempt to declare an already-existing object as
	a region. (This is never necessary, and when it occurs it is almost always
	a symptom of an inadvertent clash of names.)
Run-time problem message added for attempts to find routes or count steps
	through relations not permitting this. (Previously such attempts would
	be allowed but, not very helpfully, invariably come back as finding no
	possible route. This was misleading.)
Bug fixed whereby finding best routes through the map from A to B would fail
	with a programming error at run-time if A or B were nothing: Inform now
	works in these cases, returning the information that no route exists.
	(Similarly for counting steps, and for finding routes through relations.)
Bug fixed whereby the built-in relations were not being given names as values,
	so that for instance Inform would fail to understand "containment
	relation" even though there is a relation called "containment".
Bug fixed whereby relations defined by a condition would, if defined between
	different kinds of thing, sometimes lose track of what kinds they were
	defined over: so that run-time type-checking errors could be produced
	because the definition was applied to objects of the wrong kind.
Bug fixed whereby some tests amounting to seeing whether a given room is in
	a given region, in the course of a condition, would fail.
Bug fixed whereby a backdrop asserted as being in more than one region would
	only appear in the first region asserted (though also in any rooms it was
	asserted as being in: the bug applied only to multiple regions).

TABLES

"Increment" and "decrement" are now synonyms for "increase" and "decrease".
	Moreover, they can now also be used on table entries (e.g. "increase
	pollen count entry by 2").
"Choose the row with..." is now synonymous with "choose row with...".
Problem message added for placing blank entries in the first column of a table
	which is creating named objects or values, something which makes no sense
	since the first column provides the names.
Problem message added to report duplicated table names (which are not
	continuations of each other).
Problem message for using a table reference at a time when no row has been
	selected has been clarified to explain why text substitution can make
	this time not the time which several users thought.
Problem message for using a table reference in a condition set in the past
	tense and thus relating to a time when no row had been chosen.
Problem message for using a table reference in a complex condition which
	requires loops over objects in ways very likely resulting from a
	misunderstanding (and which in any case can't be compiled safely if
	taken at their literal meanings).
Problem message added for "Some X are defined by the Table of T" where X is
	something unrecognised, and another for where X describes a specific
	object rather than a kind. (It needs to be a kind of object or value.)
Bug fixed whereby repeating through a table "in reverse order" (not in reverse
	order of any specific column, just in reverse order of its natural order)
	would produce I6 errors.
Bug fixed whereby sorting a table would (almost) always move blank rows to
	the top: it now invariably moves blank rows to the bottom, regardless of
	the direction or column of sorting, as the documentation implies it should.
Bug fixed whereby any continuation of a table was being treated as if written
	under the same heading in the source text as the start of the table:
	which meant that any problem messages, and also any object name
	disambiguation, would be handled at the wrong position.
Bug fixed whereby "change TE to V", where TE is a table entry and V is some
	value to be put there, was not being type-checked - so that one could,
	for instance, change a textual entry to a number, with subsequently
	unfortunate results. (This is particularly insidious in the case of
	changing a topic entry to a textual string, which can't safely be done
	at run-time, and will crash the interpreter during later parsing.)
Bug fixed whereby the condition "if S is a topic listed in T", where S is a
	snippet (e.g. "the player's command") and T has a topic column, would
	produce programming errors at run-time rather than perform the necessary
	matching.
Bug fixed whereby the condition "if there is an X of Y in T", to see if the
	X column of table T ever contains Y, failed to compile if T was
	expressed in a way not using the word "table" (for instance, if T was
	a table-name which varies).
Bug fixed whereby naming a table in such a way that the first word of the
	name was an article (e.g. "Table of A Students") would make that table
	subsequently difficult to refer to.
Bug fixed whereby some properties given by columns in tables which define
	a batch of objects would, if they seemed always to contain other objects,
	sometimes cause an internal error and so fail to compile.
Bug fixed whereby references to entries in tables in the past could produce
	internal errors.
Bug fixed whereby defining a quoted text as an enumerated value of a kind of
	value using a table (a foolish but just about legal thing to do) caused
	I6 errors.

TO... PHRASES

>--> Phrase declarations can also now give literal values as the only possible
	match. For instance, defining:
		To hazard (N - a number): say "[N]! That's Numberwang."
		To hazard (N - 14): say "[N]... oh, sorry, Julie, that's NOT Numberwang."
	means that using a phrase like
		hazard X;
	will produce the exceptional message if X is 14, and the standard one
	otherwise. For instance, if we tried this with X repeating through a
	loop, we might see:
		13! That's Numberwang.
		14... oh, sorry, Julie, that's NOT Numberwang.
		15! That's Numberwang.
	If we had not defined the general case ("To hazard (N - a number)"), then
	attempting to use
		hazard X;
	for any value of X other than 14 would have produced a run-time problem.
	(This was (6.29) in the January document.)
Phrase declarations can now give alternatives for any single literal word
	using slashes (using the same convention that grammar tokens follow).
	For instance,
		To pour (N - a number) gallon/gallons: ...
	makes the phrase match with either "gallon" or "gallons" as the last
	word; except that "say" is never permitted as the first word of a
	phrase, just as now, because "To say ..." declares a text substitution
	instead. (This was (6.26) in the January document.)
>--> Because of this, all existing To... definitions containing words with
	a slash in them, such as "and/or", will need to be changed. In particular
	the text substitution "[is/are a list of...]" and similar forms have been
	changed to "[is-are a list of...]", and the same principle (exchanging
	slashes for hyphens) has also been followed for the extensions: see above.
Problem message added to prevent source text trying to redefine "now ..." by
	creating "To now X is 2" and similar constructions - these tend not to
	work, and are highly misleading when they do.

IF AND OTHERWISE

An additional problem message has been added to catch a subtle syntax mistake
	which previously led in some cases to I6 errors. This is to do with the
	possible interpretations of "otherwise if", as shown by the following:
		Report going from Alpha to Omega:
			if Omega is visited begin;
				say "You retrace your steps, but it's just not the same.";
				otherwise if turn count < 2, say "Unhesitatingly, you set out.";
			end if.
	This is actually illegal, because "otherwise (phrase)" can only occur
	immediately following an "if (condition), (phrase)": the form of otherwise
	used to divide up cases within a blocked if (such as the "Omega is visited"
	one) is just "otherwise if (condition)". The new problem message intercepts
	this mistake. The correct text would be:
		Report going from Alpha to Omega:
			if Omega is visited begin;
				say "You retrace your steps, but it's just not the same.";
			otherwise if turn count < 2;
				say "Unhesitatingly, you set out.";
			end if.
	(While at first sight the incorrect syntax looks innocuous enough - why not
	simply allow both forms? - this becomes ambiguous if the statement does
	indeed follow a simple "if" within the larger "if" block.)
The problem message arising from "if C", where C is not recognised as a
	condition, has been made more helpful in the case where C is a compound
	condition. (For instance: "I was expecting that 'score is 1 or 2 or lemon
	sherbet explodes in the dark' would be a condition, but I couldn't make
	sense of it that way. 'score is 1' was okay; '2' only made sense as a
	value, which can't be used as a condition; 'lemon sherbet explodes in the
	dark' did not make sense; and nor did the condition make sense as all
	one text.")
Problem message rather than I6 errors for using "otherwise ..." as following
	immediately on an "if ... begin" block opening. (It would be legal to
	use "otherwise", or to use "otherwise ..." after a non-blocked "if".)
Bug fixed whereby "if ..." might fail to yield problem messages where a
	complicated condition included arithmetic performed on named values
	which do not exist.
Bug fixed whereby giving more than one "otherwise;" clause in an "if" block
	did not provoke any problem message. (It now does.)

CONDITION SYNTAX

When a phrase can be used as a condition (i.e. when it is a phrase "to decide
	if..."), "not" followed by that phrase can also be used as a condition.
	In particular, "when not in darkness", "if not using the memory economy
	option", etc., now work.
"Can not" is now synonymous with "cannot": for instance, "if the player can
	not see the fish" is equivalent to "if the player cannot see the fish",
	and similarly for "if the player can not be seen by the fish".
Problem message added to catch accidental omissions of verbs in some
	descriptive conditions (say, writing "if small key inside box" instead
	of "if small key is inside box": it would open the door to too many
	ambiguities to allow these customary omissions in general).
Bug fixed whereby tests of whether "A is unable to B" would be parsed as if
	they were "A is able to B", i.e., with the negation lost: for instance,
	"...when Peter is unable to see the bridge" would be read as if "...when
	Peter is able to see the bridge".
Bug fixed whereby testing whether something unlocks something else would
	compile through I7 but then cause I6 errors.

MISCELLANEOUS SYNTAX

An explanatory problem message, rather than an internal error, now results
	from using 'total ... of' in a way too complicated to handle.
Bug fixed whereby clashes of names as between ordinary phrases and arithmetic
	phrases could result in unhelpful problem messages on legal source text:
	for instance, creating a property called "times played" and then
	evaluating "total times played of all tracks" would be confused with
	trying to multiply "total" by "played of all tracks", even though this
	interpretation made no sense.
A name-space clash causing the Standard Rules to conflict with any kind whose
	name included the word "item" has been removed.

RULES AND RULEBOOKS

Problem message rather than internal error for the case of a rule which
	happens when an activity is being applied to X, but X is not a
	description of something.
Problem message rather than I6 errors for attempting to write an inline
	I6 definition of a rule. (Only allowed when defining "To..." phrases.)
Problem message added for a rule whose name contains a comma. (No, really.
	People have tried to do this.)
Bug fixed whereby saying that a named rule is listed first, in a rulebook
	already containing other named rules, would sometimes have no effect.
Bug fixed whereby declaring that a new named rule should be listed instead
	of an existing (and built-in) action rule, e.g. the "can't go that way
	rule", would sometimes cause the new rule not to have the same implied
	actor conventions as the old one - for instance, even though the "can't
	go that way rule" applies to all actors, its replacement might only
	apply to the player, so that NPCs were able to walk through walls.
Bug fixed whereby the result of a rule was not allowed to be another rule,
	so that "rule succeeds with result X" would fail in the case of X being
	a rule - while printing a problem message explicitly claiming that a rule
	was one of the legal alternatives here.
Bug fixed whereby rules attached to actions happening "for the first time"
	(or with similar stipulations) would sometimes, in the case of complex
	actions, fire more than once during the same turn. This bug has been
	seen particularly in response to "After going from X to Y for the first
	time", where the rule fired both after the going, and then also after
	the subsequent looking action in the same turn.
Typo fixed in Rules index: it should be "action-processing rules", not
	"action processing rules". (Some people thought this rulebook could not
	legally be referred to as a value - actually it can, but this typo
	caused them to get the name wrong. Apologies.)

ACTIONS

>--> The relationship between the actions "getting off" and "exiting" has been
	reversed. Suppose the player is on a chair, a supporter. In previous
	builds, EXIT would cause the exiting action directly, but GET OFF CHAIR
	would cause the getting off action, which would quickly convert into an
	exiting action. This worked fine, but meant that a rule like:
		Instead of getting off the sticky chair, say "You can't! It's too
			sticky."
	would only apply to one of the two commands, anomalously. In this build,
	it is exiting which converts to getting off (provided that the actor is
	indeed on a supporter). (This also fixes a bug to do with NPCs and the
	convert get off to exit where possible rule, which no longer exists.)
The problem message for mis-describing an action with the form "A or B or ..."
	now itemises the listed actions to say which are valid and which not,
	and also warns if one of these is a named kind of action (which is not
	allowed in a list like this). It also handles the case of "doing something
	except A or B or ...".
Problem message added for past-tense references to the "noun" or "second
	noun" which certainly will not do what their authors intend, because
	the values of these quantities have changed over time.
Problem message added for complicated past-tense references to the "going"
	action. (The old problem message amounted to "I don't understand this",
	the new one "I do understand this, but I'm still not going to do it".)
Problem message added for describing a "going" action in terms of objects
	which are of the wrong kind to make sense - going from or to a non-room-
	or-region, through a non-door, with or by a non-thing. This only catches
	cases which the compiler can spot, involving specific named items, but
	this is more useful than it sounds (especially if a room name includes
	the word "by" in lower case, and Inform has wrongly taken this as a
	preposition).
Bug fixed whereby moving the player during the course of a rule attached
	to an action being carried out by somebody else would cause any resultant
	looking action to apply to that other person, rather than the player,
	so that instead of a description of the player's new room we might either
	see nothing or something like "Miss Marple looks around.", depending
	on where the third party is at that point in the action.
Bug fixed whereby somebody arriving in the player's room as a result of a
	"going" action would always be described as arriving from the opposite
	direction as that of initial travel - so if he had gone east, he would
	now be said to have arrived from the west, for instance. This is fine
	for untwisted, two-way routes, but not otherwise. Inform now only does
	this where the reverse journey can be made in the reverse direction,
	possibly via a two-way door; and otherwise simply says that the person
	"arrives".
Bug fixed whereby a spurious "You must name an object." error would be printed
	in response to a command requesting somebody to carry out an action which
	applied only to a single topic.
Bug fixed whereby "try looking" would sometimes fail with a spurious "You
	must name an object." error if it occurred during an action which applied
	to a value rather than a thing.
Bug fixed whereby an action caused by "try" would sometimes not have the
	appropriate "... understood" values correct if the action applied to a
	value rather than a thing.
Bug fixed whereby an action whose name takes the form "... to something"
	could be referred to without the "to". As a special case and because
	of its status as an optionally-nouned action, this is still allowed
	for "listening" (properly speaking the action is called "listening to"),
	but forbidden for new actions.
Bug fixed whereby lists of actions would sometimes, in certain orders and
	where ambiguity between different length actions occurred, wrongly cause
	problem messages. For instance, "Instead of taking off or dropping the
	jodhpurs" would fail (note ambiguity between "taking" and "taking off")
	whereas "Instead of dropping or taking off the jodhpurs" would work.
Bug fixed whereby ambiguities caused by abbreviation of action names
	(for instance if we have actions "weighing" and "weighing it with",
	what do we say that the rule "Before weighing" applies to?) are now
	resolved in favour of the least abbreviated name (here, "weighing").
Bug fixed whereby tests of intransitive past tense actions (e.g. "we have
	woken up", no object, rather than "we have taken the box") were
	performed incorrectly, usually producing false negatives.
Bug fixed whereby action reporting would suddenly cease after a NPC tried
	an action involving a door or backdrop. (The mystically-named "untouchable
	silence" bug, which Khelwood posted a (correct) fix to RAIF for.)
Bug fixed in the implementation of the ACTIONS testing command whereby
	the information that a tried action had just failed would sometimes be
	destroyed by the act of printing things information out.
Bug fixed whereby some complicated check, carry out or report rules would
	fail to appear in the Actions index.
Bug fixed whereby check rules applying to the final action performed would be
	posthumously applied also to the attempt at restoring the game produced
	by typing RESTORE in reply to the post-game question "Would you like to
	RESTART, RESTORE a saved game or QUIT?"

SCENES

>--> A small but quite important change has been made to the scene changing
	mechanism which affects the order in which things happen when there are
	multiple scene endings. For instance:
		Home is a room. The cube and the ball are here.
		Shape Choice is a scene. Shape Choice begins when play begins.
		Shape Choice ends roundly when the player carries the ball.
		Shape Choice ends squarely when the player carries the cube.
		Consequence is a scene. Consequence begins when Shape Choice ends.
		When Consequence begins:
			if Shape Choice ended roundly, say "Roundly.";
			if Shape Choice ended squarely, say "Squarely."
	Suppose the cube is taken. This used to cause the following sequence of
	events:
		Shape Choice ended
		Consequence began
		Shape Choice ended roundly
	It was necessary for Shape Choice to end the regular way before the exotic
	way, so that consequent rules could happen, but the ordering was unfortunate,
	because it meant that the rule in the source above happened at a time when
	it wasn't known whether the scene had ended roundly or squarely - only that
	it had ended. Since it's very useful to know how the previous scene ended
	in order to begin the next one, this is unfortunate. The change means that
	the sequence is now:
		Shape Choice ended
		Shape Choice ended roundly
		Consequence began
	and so the rule above works after all, printing "Roundly."
It is now possible (optional, that is) to use a "the" in giving a rule for
	a scene beginning or ending: thus "When the Afternoon begins:" is now
	synonymous with "When Afternoon begins:".
Two new phrases for scenes have been added: "the time since S ended" and "the
	time when S ended", exactly parallel to "the time since S began" and "the
	time when S began". (Previously, the "began" time was being interpreted as
	the most recent time at which S either ended or began - this was a bug, and
	has been fixed.)
New scene "Entire Game" created: see KINDS OF VALUE.
Bug fixed whereby a scene which begins "when play begins" and also when a
	condition holds now begins in either case (previously, the condition was
	being ignored, and some users thought it was illegal to specify a condition
	in this case - actually it was a bug).
Bug fixed whereby begin/end conditions of scenes would not be properly
	disambiguated if relying on an ambiguously phrased phrase to decide
	the outcome, resulting in I6 errors for what was correct source text.
Bug fixed whereby begin/end conditions of certain forms, such as past tense
	actions, were rejected altogether with spurious problem messages.
Bug fixed whereby if scene A is set to end when scene B ends, but in fact
	B ends at a time when A has never started, ending rules for A would be
	erroneously run anyway.
Bug fixed whereby creating a scene that varies called X could sometimes also
	create a scene called X. (Except for cluttering the index, this would
	only be harmful if the name of X happened to end with "scene", but of
	course people do tend to name such things "current scene", etc., so...)
Bug fixed (see KINDS OF VALUE) whereby creating but not initialising a
	scene property or variable caused an internal error.

WHEN PLAY BEGINS

Bug fixed whereby attempting to enter a closed container which in fact
	already enclosed the actor (but indirectly so) would fail the "can't enter
	closed containers rule" rather than the "can't enter what's already
	entered rule", resulting in a slightly misleading reply.
Bug fixed whereby calculations of visibility made during "when play begins"
	rules would be incorrect because the player object had not yet been put
	into its starting position.
Bug fixed whereby changing the player to a new player-character and then
	moving that PC during "when play begins" rule to a container or supporter
	would have the final movement disregarded.

OBJECT MOVEMENTS

>--> Scenery is now usually "fixed in place". This makes little difference
	since it can't normally be taken, but in previous builds it usually had the
	"portable" property, and this meant that (for instance) "repeat with the
	item running through the portable things in the location ..." would
	unexpectedly include scenery.
Bug fixed whereby moving an object from room to room (say, by writing "now
	the row-boat is in the Rapids") would cause the location to be wrongly
	set internally if the object contained the player (because an I6 PlayerTo
	call would never occur), which would make certain room descriptions print
	wrongly.
Bug fixed whereby "remove D from play", where D is only a vague description
	of things, would compile I6 code which failed at run-time rather then
	produce a problem message.

LIGHT

Bug fixed whereby another person in the same room, openly carrying a light
	source, was not counted as lighting that room.

UNDERSTANDING

In previous builds, the activity "reading a command" has happened only around
	the original command being typed. If the player types TAKE POLISH, the
	activity winds up: if, later, the parser asks a follow-up question such
	as "Which do you mean, the Polish sausage or the shoe polish?", this
	question is not framed by the activity. That remains the case, but if
	the question results in a rewritten command, Inform now - exceptionally -
	follows the "after reading a command" rulebook for a second time.
Problem message rather than internal error for confusing an activity with an
	action in an "Understand ... as ..." sentence.
Bug fixed whereby, if we give define a noun as a legal command by writing e.g.
	"Understand "[something]" as examining." and then the player types
	something unrecognisable, the parser replies "You can't see any such
	thing." (presuming we were intending to type a noun) rather than "That's
	not a verb I recognise." (presuming a verb - which seems more likely).
Bug fixed whereby the message "** Warning: grammar properties might not work
	correctly **" would occasionally appear when a game began playing (but
	not in a released version).

USE OPTIONS

The "the" in the condition "using the ...option name... option" has been
	made optional: for instance, "if using no scoring option" is now allowed.
Bug fixed whereby using memory economy did not suppress all the RULES ALL text,
	thus not economising as much as it might.

EXTENSIONS

Problem message added to explain that extension names should be unquoted
	in Include sentences.
Bug fixed whereby extensions ending without documentation would sometimes
	produce a spurious problem message on their end lines, unless these
	were followed by at least one one blank line.

PUBLISHING

Bug fixed whereby releasing along with a website stopped working in 4K40/1.
	Particular apologies for this.
Bugs fixed whereby Unicode translations were not properly preserved in
	released websites, notably in title, blurb and source text when written
	as HTML.

WORLD INDEX

Problem message added to clarify that mapping hints can only be given laterally
	(so e.g. "Index map with Overlook mapped above Great Plain" does not work).
Bug fixed causing "yourself" (the player) to appear twice in the World index
	in some situations.
Bug fixed whereby disconnected areas of map would sometimes appear on vastly
	distant vertical levels from each other, with peculiar resulting map
	legends. (See e.g. the map for "Port Royal 2" under 4K41 or earlier.)

PROBLEM MESSAGES

Bug fixed whereby some problem messages concerning phrases would be reported
	as being in the text under the final heading in the source text, rather
	than the headings under which they actually occurred.
Bug fixed whereby problems occurring in text substitutions inside quoted text
	which forms a whole sentence (e.g., as an implicit room description)
	were reported as being at peculiar sentences.
A number of problem messages which users reported as unclear have been reworded.