[I7] Current state, internal build 5N27, and library messages

[Graham Nelson]

Dear all,

The scheme to merge the I6 support files in I7 with the
I6 library is now complete, at least in so far as there is
a detailed draft which is very much clearer and more
readable than before. It's been possible to unpick many
tangles due to the I6 library not quite matching what
I7 needed, and to remove a lot of clutter, such as
support for V3 of the Z-machine (which would never
work with I7 anyway) and for old, buggy versions of
the I6 compiler (which are not included with I7). There
is also quite a bit more documentation of what
everything does and how it fits together.

Similarly, the revised Standard Rules (version 2) are
now in a nearly complete draft: its loose ends more
or less correspond to the loose ends in the template,
since the two work closely together.

Work continues on optimising story files for run-time
speed on both the Z-machine (where the worst-case
test "Bronze" is now more than twice as fast), and
on Glulx. Since Andrew Hunter is already working
on Zoom for iPhone, where a 600MHz processor
probably means we're looking at story files running
only 1/5th as fast as they would on a modern
desktop, this may be more pressing than it has
been in the past. This work has been greatly helped
by Jesse kindly writing a profiling version of dumb-frotz.
We are also looking at mechanising tests on Glulx
using cheapglk and glulxe, a long-overdue measure:
it may prevent accidents like the one Aaron reported
the other day (in which the example "Pink or Blue"
fails rather gracelessly under Glulx). And work
continues on the new activities for what used to
be called the "locale" routines in the old VerbLib,
and is now a set of activities, with the code ported
out of the I6 library and into I7 source text: Emily is
working on this. Finally, code to support fixed-point
arithmetic already exists in draft form: square root,
sine, cosine, tangent, etc., and exponentiation are
all written, while work advances on logarithms.
So there is movement on several fronts.

The NI compiler itself has not advanced very much
in recent weeks, except to add table amendments,
which work much like table continuations: these
are motivated by the goal of moving all of the
library messages into tabular form and then making
it possible for translators and others to amend any
rows they please from these tables. There's
more to do on extensions before the current builds
of NI can go live to public use; esp. on case sensitivity
of filenames, implementing the proposed ".i7t"
filename extension for extensions, and so on.

But this seems a good point to make a second
try at releasing an internal build which may help
David Fisher's work on library messages. I've
uploaded source code for the current build,
5N27, to the usual place, i.e.:

http://users.ox.ac.uk/~nelson/OS%20X/x/private/

If David K. could kindly make a Windows build
for David F. to play with, that would be much
appreciated. Anyone else who wishes to play
with this intermediate version is welcome to, but
at his own risk. There's probably no need to port
to other platforms: this is a build which doesn't
play well with some existing extensions, and
could cause trouble for end users, so we should
keep it amongst ourselves.

The two PDF files at the above address, called
Appendix-A.pdf and Appendix-B.pdf, are the
typeset forms of the Standard Rules and the
template as they currently stand. The files are so
called because they form the first two appendices
to the full "document" of the NI source code. (NI
is written under the doctrine of Literate
Programming, according to which programs should
be published such that they can be either compiled
or typeset and read. When complete, the typeset
form of NI will be around 2000pp, but of course
nobody will read it: it's meant to be dipped into
by people maintaining I7. Anyway, these two
appendices are a slightly scruffy draft of about
600pp of the whole.)

The old "library messages" (in the absence of a
library, the term is obsolete) have been divided
into three: the old Miscellany messages, the old
ListMiscellany messages, and all of the others.
The point of this division is that ##Miscellany
and ##ListMiscellany are fake actions, in I6, and
are therefore not type-safe values for the I7
kind of value "action-name". (There used to be one
message under the fake action ##Order, but that
has been moved into the miscellany set.) Thus
the "all of the others" category are all messages
pertaining to specific actions.

Most of the messages are generated by rules
written out in I7 source text in the Standard Rules,
but others are generated by calls to an I6 routine
in the template. Wherever they come from, all
requests to print a message are now routed
through three I7 phrases defined in the Standard
Rules as follows:

To decide if intervened in miscellaneous message:
	decide on false.

To decide if intervened in miscellaneous list message:
	decide on false.

To decide if intervened in action message:
	decide on false.

(Deciding false goes through the usual I6
library messages system instead: that used to
be in the I6 library's language definition file,
English.h, but is now in the template's Language.i6t.)

Redefining these to print messages in some way,
and deciding on true instead, provides a hook
with which we can experiment on different
schemes to provide the messages. (These
phrases are probably a temporary expedient
rather than part of the final design.) The sample
code in LMS.inform (zipped at the same site
as above) shows how these can be used to
tabulate the messages in all three categories.

The current change log since the last build is
below.

The number of bug report forms to deal with
is now up to around 200 again. Many thanks to
everyone sending these: they aren't being
ignored, however it may look.

Happy first Sunday after the first ecclesiastical
full moon that occurs on or after March 21,

   Graham


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.)
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 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.
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.)

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

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 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.)
	- 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.)

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 I6 library is dead; long live the I6 library.
The template layer consists of a set of more than 20 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

Bug fixed whereby a skipped line for a paragraph break would in some
	circumstances be omitted between subsequent paragraphs in a room
	description.
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 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.
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 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 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.
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".
Problem message added for creating a property name consisting only of  
the
	word "presence" (since this causes ambiguities with "...in the presence
	of...").
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).

Examples:
	"Provenance Unknown" added to demonstrate how PUSH TELEVISION WEST  
might
		be converted to pushing the cart on which the television rests.
	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.

Extensions:
	"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.


--
Graham Nelson