*** Change log for Inform 7 ***

Versions of Inform 7 are identified by "build number", a combination of
digit, letter, and two digits: for instance, 2P75 comes after 2P74 and
long after 2G14, but before 2Q02 and long before 3A07. This log briefly
notes the changes in Inform from the first Public Beta. All changes
apply to all platforms unless otherwise noted. The log is reverse-ordered,
so that more recent builds appear earlier. Minor changes to documentation
are not listed.

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.


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.

INFORM FOR WINDOWS

If you try to create a new project in the same place as an existing one,
	you are warned before the existing project is overwritten.
If you try to create a project in a directory that doesn't exist, the
	application will try to create it.
Text can be copied, cut and pasted when editing the expected text in the
	transcript window.


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.
	"Great Portland Street" added to demonstrate a game-show using lists
		to create a set of actions performed.
	"Robo" 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.


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 messages about doors opening and closing were grammatically
	incorrect if the doors had a plural name: e.g. "The double doors opens"
	instead of "The double doors open".
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.


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 n