26.5. What's new in build 5T18 (April 2008)

| Chapter 26: What's New in Inform? |

| 26.5. What's 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.

See Begin and end for the new way to group phrases in "if", "while" and "repeat"

See Next and break for ways to skip to the next iteration, or to immediately exit, a "repeat" or "while" loop

See Otherwise for a new form of "if", somewhat like a "switch" statement in C or Inform 6

See If for the new ability to use "unless" as a reversed form of "if"

See Text with variations for the new ability to use "[unless ...]" as a reversed form of "[if ...]"

See Moving backdrops for a new way to move backdrops to any set of rooms matching a given description

See Table amendments for a way to define a new table which would amend selected rows in an existing one

See Adjacent rooms and routes through the map for how to use a fast route-finding algorithm when there's memory enough to handle it

See Indirect relations for similar fast route-finding through a relation

See Making new substitutions for defining text substitutions which differ only in their casing, e.g., making "[Security Notice]" different from "[security notice]" - in previous releases, these were considered identical

See Lists of objects for accessing the multiple object list generated when the parser acts on a command like TAKE ALL

See Defining new assertion verbs for defining verbs to have meanings which are the reversal of relations, that is, have the subject and object the other way round

See The built-in verbs and their meanings for the new verb "to incorporate", which expresses having something as a part: for instance, "the TV set incorporates the off button" means the same as "the off button is part of the TV set"

See A word about nothing for clarification of how "nothing" can be used: this build handles "nothing" much better than previous ones

See Multiple endings for how to check if a scene did not end in a particular way

See Printing a number of something for a new activity allowing the form of plural entries in lists, like "five gold rings", to be reworded

See Printing the locale description of something for the first of three new activities which, between them, provide much finer-grained access to how room descriptions are printed

See Printing the announcement of light for a new activity, used when light returns after a period of darkness

See Deciding the scope of something for better control over the "place ... in scope" phrase

See Understanding names for supplying additional text to be understood as referring to things in the plural

See Context: understanding when for a new property, "privately-named", which enables the name of something in the source text to be kept private from the player at run-time

See Printing a parser error for a new parser error, "noun did not make sense in that context"

See The TEST command for how to write literal apostrophes and slashes in test scripts, which previously couldn't be done

See Extensions can interact with other extensions for new ways to allow an extension to vary according to which other extensions are in use at the same time, and to override parts of an included extension while keeping the rest

See Authorship for more liberal extension identification: author and title can now be up to 50 characters, not up to 31; accented letters and mixed casing are now allowed; the word "and" is now allowed in extension titles; there's provision for additional credits to clarify who contributed to earlier versions, or from what an extension is converted or translated

See The template layer for a description of the new system for I6 supporting code, replacing the old I6 library with something much more customisable

See Translating the language of play for the beginnings of a new system for translating I7 to produce IF in languages other than English

See Inform 6 objects and classes for the new unified way to force I6 translations of I7 constructions, the verb "translates into I6 as"

See Longer extracts of Inform 6 code for referring to properties or adjectives using the "(+" and "+)" markers

346
| Example Casino Banale Creating room descriptions and object descriptions that change as the player learns new facts and pieces things together. |
RB

348
| Example Copper River Manipulating room descriptions so that only interesting items are mentioned, while objects that are present but not currently useful to the player are ignored. |
RB

197
| Example Delicious, Delicious Rocks Adding a "sanity-check" stage to decide whether an action makes any sense, which occurs before any before rules, implicit taking, or check rules. |
RB

399
| Example Escape from the Seraglio Replacing the usual response to TAKE ALL so that instead of output such as "grapes: Taken. orange: Taken.", Inform produces variable responses in place of "grapes:". |
RB

417
| Example Formicidae Manipulating the order in which items are handled after TAKE ALL. |
RB

371
| Example Jamaica 1688 Adding a feature to the final question after victory, so that the player can choose to reveal notes about items in the game. |
RB

347
| Example Kiwi Creating a raised supporter kind whose contents the player can't see or take from the ground. |
RB

284
| Example The Left Hand of Autumn The possibility of using a [things] token opens up some interesting complications, because we may want actions on multiple items to be reported differently from actions on just one. Here we look at how to make a multiple examination command that describes groups in special ways. |
RB

345
| Example Low Light An object that is only visible and manipulable when a bright light fixture is on. |
RB

196
| Example Noisemaking Creating a stage after the report stage of an action, during which other characters may observe and react. |
RB

120
| Example Orange Cones Creating a traffic backdrop that appears in all road rooms except the one in which the player has laid down orange cones. |
RB

344
| Example Priority Lab A debugging rule useful for checking the priorities of objects about to be listed. |
RB

330
| Example Prolegomena Replacing precise numbers with "some" or other quantifiers when too many objects are clustered together for the player to count at a glance. |
RB

108
| Example Provenance Unknown Allowing something like PUSH TELEVISION EAST to push the cart on which the television rests. |
RB

312
| Example Quiz Show In this example by Mike Tarbert, the player can occasionally be quizzed on random data from a table; the potential answers will only be understood if a question has just been asked. |
RB

274
| Example Trieste Table amendment to adjust HELP commands provided for the player. |
RB

41
| Example Vouvray Adding synonyms to an entire kind of thing. |
RB

366
| Example WXPQ Creating a more sensible parser error than "that noun did not make sense in this context". |
RB

107
| Example Zorb Replacing the message the player receives when attempting to push something that isn't pushable, and also to remove the restriction that objects cannot be pushed up or down. |
RB

    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.

Previous | Contents | Next