26.2. What's new in build 6E59 (June 2010)

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

| 26.2. What's new in build 6E59 (June 2010)

As this release was being prepared, the world's largest census was taken, in India; the Eyjafjallajökull volcano in Iceland cut off air routes to Europe; in Ireland, pubs in Limerick opened on Good Friday, and a grey seal which had escaped from London Zoo was found in the seaside town of Skerries; element 117, ununseptium, was created inside atomic reactors; the Vatican declared that the Turin Shroud was not a forgery, but a mystery beyond human artistry; Lactococcus lactis became Wisconsin's official State Microbe following the passing of Assembly Bill 556 (Wisconsin's State Dance, incidentally, is the polka); Lady Gaga became the first singer to break one billion plays on YouTube, while Rukidi IV of Toro came of age and inherited his kingdom; and Cambridge had its revenge in the 156th Boat Race, defeating Oxford.

In the world of Inform, the Release mechanism was improved, with better feedback and a new ability to generate websites in which the project can be played in-browser. The system of kinds was made much more flexible and expressive, and phrase definitions gained in power as a result. A new chapter on Advanced Phrases was added to the manual, covering functional and generic programming. Properties, assemblies and relations were all reworked to be applicable much more consistently across the whole range of values, rather than being restricted only to objects, simplifying the language. Limits on the lengths of names of relations, verbs, prepositions, and directions were all lifted. The documentation and the Phrasebook index were revised and harmonised.

See A playable web page for how to release a project as a website which includes a version of the story file which plays inside the visitor's web browser

See Generic phrases for writing generic-programming-style definitions of phrases

See Map, filter and reduce for performing functional-programming-style computations on whole lists of values at once

See New kinds for how to rearrange the built-in hierarchy of kinds

See The showme phrase for the convenient new "showme" phrase

See Default values of kinds for how to access the default value of any named kind

See Relations involving values for how to make dynamic relations on even unbounded kinds like numbers and texts

See Relations as values in their own right for handling relations abstractly

See Temporary relations for creating relations as temporary data structures to hold calculational results

See Basis of a rulebook for having rulebooks based on values of any kind

See Rulebooks producing values for having rulebooks produce values of any kind

See Adding and removing rows for new ways to blank out columns from tables, or the entire contents of a table

See New activities for having activities on values of any kind

See Descriptions as values for using descriptions of any kind as values

See Assemblies and body parts for using assemblies to create values other than objects

See Names made in assembly for giving assembled objects or values a better variety of names

See Implications for writing implications about values other than objects

See Defining adjectives for values for defining adjectives for single named values

See Creating a scene for the new description property for a scene

See Creating a scene for writing rules about when families of scenes begin or end

See Removing things from play for using "now" with the adjectives "on-stage" and "off-stage"

See Going by, going through, going with for writing rules about "exiting from" something

See Text with random alternatives for three new forms of "[one of]..."

See Plural assertions for better pluralisation of nouns

See Irregular English verbs for better past participles of verbs

See Deciding whether all includes for new rules on TAKE ALL

See Administering classroom use for adding test and release instructions to the Options.txt configuration file

See Use options for new use options on VERBOSE, BRIEF and SUPERBRIEF room description style

See Inform 6 adjectives for making low-level adjectives which can be asserted with "now" as well as being tested

163
| Example Entrevaux Organizing the game by scenes, where each scene has a location and prop lists so that it can be set up automatically. |
RB

236
| Example Wainwright Acts A technical note about checking the location of door objects when characters other than the player are interacting with them. |
RB

240
| Example Number Study The parity and joint magnitude relations explored. |
RB

239
| Example For Demonstration Purposes A character who learns new actions by watching the player performing them. |
RB

49
| Example The Undertomb 2 Flickering lantern-light effects added to the Undertomb. |
RB

369
| Example Finality Not mentioning UNDO in the final set of options. |
RB

314
| Example Pot of Petunias Responding sensibly to a pot of petunias falling from the sky. |
RB

81
| Example Unblinking Finding a best route through light-filled rooms only, leaving aside any that might be dark. |
RB

    6E59 (12 June 2010)

    This is a major release of Inform: the first in a little over a year, and
    with a change log well over double the previous record size - large enough
    to need a table of contents for the first time. Inform has new icons, and
    a slightly revised design; more than 250 bug reports have been closed, so
    that it currently has no issues open. There are minor surface enhancements
    right across the language, and these are (mainly) the result not of fiddling
    but of substantial rewrites of the underlying compiler. Many exceptions
    have gone, and the language's design is more uniform as a result. 6E59
    contains many changes from 5Z71 and it may take authors a day or two to
    adapt their existing source text to these changes, but it should also prove
    a stronger and more reliable Inform to work with. For the first time there
    was a substantial third-party exercise in beta-testing the release, and
    as from this build we are also launching a public suggestions forum and
    an open bug-tracker.

    Contents:
    	1. INFORM FOR OS X
    	2. INFORM FOR WINDOWS
    	3. INFORM FOR GNOME ON LINUX
    	4. RELEASING
    	5. RELATIONS
    	6. ASSEMBLIES
    	7. KINDS
    	8. MAP, FILTER AND REDUCE
    	9. GENERIC PHRASES
    	10. PROPERTIES
    	11. SCENES
    	12. RULEBOOKS
    	13. INFLECTIONS
    	14. MINOR NEW FEATURES
    	15. WORD LIMITS ON RELATIONS, VERBS, PREPOSITIONS AND DIRECTIONS
    	16. ACTIONS IN THE STANDARD RULES
    	17. DOCUMENTATION, PROBLEMS AND INDEX
    	18. DEPRECATED PHRASES
    	19. MAINTENANCE
    	20. EXAMPLES
    	21. BUILT-IN EXTENSIONS
    	22. A NOTE ABOUT FIGURE AND SOUND NAMES
    	23. A NOTE ABOUT EXTERNAL FILES

    1. INFORM FOR OS X

    The user interface has been tidied up in a number of small but, we hope,
    pleasing ways, and the menu structure should be easier to navigate,
    especially for newcomers:

    	File  Edit  Format  Play  Replay  Release  Window  Help

    The preferences have similarly been reorganised, and the Settings panel is
    more explanatory. Numerous features useful only for I6 projects are now
    invisible for I7 projects, which makes the system much easier to learn.
    (But it won't take experienced users long to find everything again.)

    A new setting, for Randomness, makes it possible to fix the random numbers
    generated within Inform so that repeat runs produce the same "random" outcomes,
    which sometimes makes testing easier. (This only applies within the application,
    and it's switched off by default; it never affects a Released story file.)

    2. INFORM FOR WINDOWS

    The code for the source tabs has been rewritten to make use of the open
    source text editing component "Scintilla". This allows a number of missing
    features to be implemented, and will allow further changes to support all
    of the features available in the OS X version of the application.

    Making a selection in the contents pane now causes the source pane to show
    that selection only. The old behaviour, of showing the whole source but
    going to the selection, can be obtained by holding down the shift key when
    selecting.

    Wrapped lines are now slightly indented by default, and new lines start
    auto-indented to the same extent as the line above: both these options can
    be disabled from the preferences dialog.

    The new Format menu allows lines to be indented left and right.

    Editing the skein now marks the project as being changed.

    The background colours in the transcript now follow the same logic as
    for the OS X application. The left hand column, showing the output
    from the game, is coloured light blue if the output is the same as the
    previous run-through of the game, and light red if the output now differs.
    The right hand column, showing the "blessed" transcript, is coloured blue
    if the transcript matches the game's output, red if it differs, and
    yellow if it differs but only due to trivial whitespace changes.

    The "Replay Commands Blessed in Transcript" option, which is on the new
    Replay menu, now plays all skein threads that contain at least one blessed
    knot. After playing, if any blessed knots fail to match, the skein shows
    the first such knot.

    On the new Replay menu are commands to show the last played command in
    the skein and the transcript, and to change the selected knot in the
    transcript to step through changed commands and commands for which the
    transcript does not match the blessed text.

    The new Release menu has commands to open the Materials folder in a new
    Explorer window, and to export the game's iFiction record to a new file.

    The Window menu has been re-arranged so that access to all tabs, and all
    the Index sub-tabs, is available from sub-menus and shortcut keys.

    Pressing F4 now shows the whole of the source text in the Source tab. This
    is equivalent to bringing up the Contents view and clicking on the very
    top heading.

    3. INFORM FOR GNOME ON LINUX

    The menus and dialogs have undergone various rearrangements similar to
    those of the OS X version.

    The Glulxe and Git interpreters that run in the Game tab have been updated
    to version 0.4.5 and 1.2.6 respectively. Likewise, the Gargoyle system that
    runs them has been updated to a more recent revision, which supports
    hyperlinks, and copying and pasting from the Game tab.

    The Documentation tabs now always show scrollbars, to prevent the "next"
    arrow from changing places when you are paging through the documentation
    quickly and land on a section that is short enough to fit on one page.

    If an error message references an extension, then clicking on the arrow
    next to it will now open the extension and highlight the offending line.

    Various minor bugs and memory leaks have been fixed.

    4. RELEASING

    Feedback after clicking the "Release" button has been much improved, with
    Inform either producing a report on what has happened or a legible list of
    problems. Inform has always been able to release a project with supplementary
    material added, right up to a mini-website for housing it, and in this build
    we add the ability to create a web page making the project playable
    in-browser. The new syntax:

    	Release along with an interpreter.

    causes Inform to bundle up a customised copy of a Javascript interpreter,
    along with a suitably encoded story file, so that the eventual player can
    just visit the page in any modern browser and begin playing. We believe that
    giving Inform a one-click way to make such web pages will help IF authors
    to reach out to casual gamers on the web.

    There has been great interest in browser-based story file interpretation
    recently; as recently as a few years ago this would have been prohibitively
    slow, but continuing increases in processor speed - and intensive work by
    browser manufacturers in optimising Javascript performance - have made this
    a genuinely workable option today. Projects such as "Silverglulxe", "Leaflet"
    and "Parchment" have made considerable progress, and we would like Inform to
    help this development.

    Inform ships with "Parchment" built in. At present this supports only
    projects using the Z-machine story file format, but we have made every effort
    to help Inform to accommodate future developments, and to enable it to be
    used with other interpreters, too:

    (a) Interpreters are stored by Inform in almost exactly the same way as
    website templates are. Each must have a name; the default is "Parchment",
    just as the default website template is called "Standard", but it's easy
    to specify something different:

    	Release along with the "Urbzig" interpreter.

    (b) Exactly as with website templates, Inform looks for these first in the
    "Templates" subfolder of the current project's "Materials" folder; then in
    the "Templates" subfolder of the Inform folder on the user's computer (the
    details vary with platform, but for instance on Mac OS X this is the folder
    "~/Library/Inform", where "~" is the user's home folder); and lastly in its
    own built-in stock, hidden away inside the Inform application. "Parchment"
    is undergoing rapid development; placing any new copy of it in one of the
    two locations above enables the user to get its benefits straight away,
    without having to wait for some future build of Inform to incorporate the
    update.

    (c) An interpreter is stored as a folder of Javascript and/or CSS files
    and/or images, together with a file called "(manifest).txt" which describes
    it and how Inform should put together a story file for it to play. The
    manifest for "Parchment" is heavily commented, and should help provide a
    model for other interpreter-writers to use. We very much hope that authors
    of other Javascript-based interpreters will find it straightforward to use
    this system, and we will be very happy to look at any problems they have.

    Another notable change is that "Release" now always releases the story
    file into the "Release" subfolder of the project's "Materials" folder -
    creating these if they do not already exist. In previous builds, it almost
    always did so; but would put up a Save... dialogue box if the release
    contained only the story file and nothing else. In practice, most
    serious releases are going to involve at least some material beyond the
    story file, and for consistency's sake we've got rid of the Save...
    dialogue box and gone for the "Release" folder in all cases.

    Miscellaneous small changes have been made to the "Release" mechanism
    throughout; for example, a problem to do with Skein files which have lines
    over 10K in length has been removed (the threshold was raised to 50K and
    warnings about trimming have replaced errors), and a more serious bug to
    do with projects containing around 500 or more images (which affected
    Windows users but not OS X or Linux) has been fixed.

    5. RELATIONS

    Relations are central to Inform. Every verb's meaning is a relation, and
    Inform's model of the world is based on relationships holding between objects
    and/or other values.

    This build makes it possible to define relations on any kinds of value (not,
    as before, only on finite kinds and even then with petty restrictions); to
    use relations as first-class values in their own right; and to create
    relations on a temporary basis.

    (a) Relations on any kinds of value:

    We can now define relations between more or less anything:

    	Partnership relates various texts to various texts.

    	The verb to belong with (he belongs with, they belong with) implies the
    	partnership relation.

    	"cheese" belongs with "crackers".
    	"clam" belongs with "chowder".

    And this allows us to create large and varied data structures. A relation is a
    natural generalisation of an associative array (an "associative hash" in Perl,
    a "dictionary" in Python, a "table" in Lua, and so on - the idea goes back
    at least to Smalltalk and the mid-1970s). In fact, an associative array is
    exactly a various-to-one relation in Inform terms.

    There are two caveats:

    	(i) Previous builds would have rejected this because the domain
    	(texts) is simply too big. The new build makes use of hash tables
    	dynamically built in allocated memory to cope with this (using
    	run-time code generously contributed by Jesse McGrew) - as such it
    	really only works efficiently when the Settings for the project
    	are set to the Glulx virtual machine.

    	(ii) Inform isn't good at reasoning with relations when the domains
    	are too big to make search loops practicable, so some constructions
    	like "if 5 tallies with an even number" - where "tallies with" means
    	a various-to-various relation of numbers to numbers - aren't allowed.
    	But see below.

    (b) Extracting values from relations:

    Suppose we've defined the example partnership relation above. How could we
    find out what, if anything, "caviar" belongs with? It would be impractical
    to keep trying

    	if "caviar" belongs with "aardvarks", ...
    	if "caviar" belongs with "abacuses", ...
    	...

    Instead:

    	if "caviar" relates to a text by the partnership relation, ...

    tests whether or not it relates to anything; and if it does,

    	a text which "caviar" relates to by the partnership relation

    will produce one such text. Of course, there might be many: so

    	list of texts which "caviar" relates to by the partnership relation

    will produce them all. And we can also look at this the other way round:

    	if a text relates to "caviar" by the partnership relation, ...
    	a text which relates to "caviar" by the partnership relation
    	list of texts which relate to "caviar" by the partnership relation

    Still more interesting are the slightly tongue-twister-like:

    	list of texts which the partnership relation relates
    	list of texts which the partnership relation relates to

    If we had written:

    	"cheese" belongs with "crackers".
    	"clam" belongs with "chowder".

    then these lists might be { "cheese", "clam" } and { "crackers", "chowder" }
    respectively. (For efficiency reasons, there are no guarantees about what
    order the lists have - but they can of course always be sorted when found.)

    (c) Relations as themselves values:

    Relations have always been values, but in past builds their kind was simply
    "relation", which made it impossible to distinguish, say, the visibility
    relation (can one person see another?) from, say, these:

    	Parity relates a number (called N) to a number (called M) when N minus M
    	is even.

    	Joint magnitude relates a number (called N) to a number (called M) when
    	N plus M is greater than 7.

    In any case, little could usefully be done with relations as values, because
    there was no good way to test or assert them other than explicitly.

    In this build, a relation has the kind "relation of K to L", where K and L are
    the kinds of the two things it relates. For instance, "joint magnitude relation"
    has the kind "relation of numbers to numbers"; though it's also allowed to
    write just "relation of numbers", because Inform assumes both kinds are the
    same if only one is given. We can now write, say:

    	To chart (R - a relation of numbers):
    		repeat with N running from 1 to 5:
    			repeat with M running from 1 to 5:
    				if R relates N to M, say "[N] <=> [M]   ";
    			say "[line break]";

    and now "chart parity relation" will work nicely, but "chart visibility
    relation" will be rejected (as it should be). More ambitiously:

    	When play begins:
    		let L be { parity relation, joint magnitude relation };
    		repeat with R running through L:
    			chart R;

    Here the kind of L is "list of relations of numbers to numbers".

    In general, we can write

    	if R relates X to Y, ...
    	now R relates X to Y;
    	now R does not relate X to Y;

    to test, set and unset a relation R between two values, though of course
    Inform checks that the values have the right kind and produces a problem
    message if not.

    (d) Adjectives applying to relations:

    The following are now defined:

    	"empty" - nothing relates to anything else
    	"symmetric" - by definition X relates to Y if and only if Y relates to X
    	"equivalence" - this is a relation "in groups", or an "equivalence relation"
    	"one-to-one" - it relates one K to one L
    	"one-to-various" - similarly
    	"various-to-one" - similarly
    	"various-to-various" - similarly

    So for example it's possible to ask

    	if R is a symmetric one-to-one relation of texts, ...

    With some relations, it's possible to clear them out by writing:

    	now R is empty;

    and with temporary relations (see below), it's even possible to change their
    valencies (one-to-one vs. one-to-various, etc.) using "now", but only when
    they are empty. The exceptions where "empty" can't be used are those which
    can't be changed at all, and a few built-in cases such as "support",
    "containment" and "incorporation", where emptying would dissolve the model
    world in a disastrous way.

    (e) Making temporary relations:

    In past builds of Inform, the relations were all created explicitly by the
    source text. The stock of relations which exist at the start of play could
    not be changed; the relationships might change - sometimes Red Riding Hood
    would be in the Woodcutter's Cottage, sometimes not - but the relations
    themselves (in this case, containment) were eternal.

    This is no longer true, and it's now easy to create relations as dynamic
    data structures, like lists or indexed texts. For example:

    	let the password dictionary be a relation of texts;

    This makes a purely temporary various-to-various relation between texts,
    which lasts as long as the temporary value "password dictionary" lasts.
    By default, relations are various-to-various, but we could instead write,
    say:

    	let the nicknames catalogue be a various-to-one relation of texts;

    Such a relation exists only in the current phrase, and is destroyed when
    the phrase finishes, like any other "let". Of course there's no verb whose
    meaning in this relation, but that's no obstacle, because we can manipulate
    it using "relates":

    	now the nicknames catalogue relates "Trudy" to "Snake-eyes";

    (At present such a relation cannot be used outside its own phrase, but we
    hope to enable this in future builds by means of closures.)

    6. ASSEMBLIES

    Up to now, assemblies like this:

    	A signpost is a kind of thing. Every room contains a signpost.

    have been deprecated as not always reliable - it was a bad idea to make
    constructions on the basic kinds "room", "container", "supporter", "door"
    or "thing", the above being an example of an assembly on "room". That
    restriction is now lifted, and the above works as it looks as if it should.

    Assemblies can now involve values as well as objects. For example, if we
    start from:

    	A colour is a kind of value. The colours are red, green and blue.
    	Liking relates various people to various colours.
    	The verb to like (he likes, they like, it is liked) implies the liking relation.

    then the assembly:

    	Every person likes a colour.

    will produce an initial situation like so:

    	>relations
    	Liking relates various people to various colours:
    	  You  >=>  your colour
    	  Daphne  >=>  Daphne's colour

    Here the assembly process has created two new colour values. Had the assembly
    instead been written:

    	A person likes every colour.

    then the result would be:

    	Liking relates various people to various colours:
    	  The person  >=>  red
    	  The person  >=>  green
    	  The person  >=>  blue

    where this time three new people have been created. Note that these people have
    no fancy names. But we can arrange for that with another new feature:

    	A person (called its fan) likes every colour.

    Which would instead produce:

    	Liking relates various people to various colours:
    	  Red's fan  >=>  red
    	  Green's fan  >=>  green
    	  Blue's fan  >=>  blue

    Similarly,

    	Every person likes a colour (called his favourite colour).

    produces:

    	Liking relates various people to various colours:
    	  You  >=>  your favourite colour
    	  Daphne  >=>  Daphne's favourite colour

    Just as "its" (or "his" or "her" or "their") expands out to a possessive form
    of the name of the owner, so to speak, so "it" (or "he" or "she" or "they" or
    "him" or "them") expands out to the name itself. Thus:

    	A person (called the world's leading fan of it) likes every colour.

    produces:

    	Liking relates various people to various colours:
    	  World's leading fan of red  >=>  red
    	  World's leading fan of green  >=>  green
    	  World's leading fan of blue  >=>  blue

    All of these callings can of course be made for standard assemblies of
    objects too; for example,

    	Every room contains a vehicle (called its buggy).

    would make a whole lot of suitably named buggies.

    The rule on what happens if there's no "(called ...)" text might be worth
    spelling out exactly:

    	(1) If we are assembling a value of kind K, then the calling text is
    		taken as if it were "(called its K)" - for instance, "(called its
    		colour)" in the first example above, which resulted in names like
    		"your colour" and "Daphne's colour".

    		However, if that results in a name which already exists, a number
    		is suffixed to make it a unique name; for instance, if there were
    		six anonymous people, then "Every person likes a colour" would
    		result in names like "person's colour 2", "person's colour 3", and
    		so forth. (It's a bad idea to write assemblies where this could
    		ever matter.)

    	(2) If we are assembling an object of kind K, then no name is attached
    		unless the relationship is incorporation - i.e., being a part of
    		something - and the object being attached to already has a name;
    		in that case, the calling text is again "(called its K)".

    The reason that the convention differs between objects and values is that
    objects are allowed to have names clashing with other objects, or no name at
    all, whereas values have to have names belonging to themselves alone.

    7. KINDS

    As a convenience for debugging awkward phrases, the following:

    	showme V;

    works for any value V, and prints out V, its kind, and then (unless it is a
    constant) its current value. For example:

    	When play begins:
    		showme indigo;
    		showme location;
    		showme the list of vivid colours;

    might open play by printing up:

    	colour: indigo
    	"location" = object: Lille Conservatoire
    	"list of vivid colours" = list of colours: {red, indigo, chartreuse}

    This is intended purely for testing. In a Release version, "showme" is always
    silent, so that if any "showme" phrases are left in by accident, they'll never
    be seen by anyone else.

    Almost every kind has a "default value", that is, a value used when Inform
    knows that a variable or table entry should contain something of this kind,
    but doesn't know what it is. The phrase

    	default value of K

    evaluates to this value, for any named kind K. For example,

    	showme default value of time;

    produces the output:

    	"default value of time" = time: 9:00 am

    This can be useful when the default value is needed, but has no convenient
    natural-language name; for example, "default value of table name", or
    "default value of sound name".

    Enumerated kinds have always had phrases to make it easier to trawl through
    their values: for instance,

    	the colour after C
    	the colour before C
    	a random colour
    	a random colour between orange and blue
    	a random colour from orange to blue

    (The last two are synonymous.) To these, we now add:

    	the first value of colour
    	the last value of colour

    If, for example:

    	Colour is a kind of value. The colours are red, orange, yellow, green,
    	blue, indigo and violet.

    then "the first value of colour" produces "red", and "the last value of colour"
    produces "violet".

    It is now possible to change how kinds relate to each other, but only if no
    previous statements are contradicted by doing so. For example, the Standard
    Rules say that "container" and "supporter" are kinds of "thing"; now supposing
    we type:

    	An enclosure is a kind of thing.
    	A container is a kind of enclosure. A supporter is a kind of enclosure.

    This is now allowed. Containers and supporters are still things; they have
    merely become more specialised, and there is no contradiction. On the other
    hand, this is incorrect:

    	An enclosure is a kind of region.
    	A container is a kind of enclosure. A supporter is a kind of enclosure.

    This is a contradiction, since regions are not things, and Inform rejects
    it with a problem message.

    The "description" kind has been removed. In its place is a more expressive
    one: "description of K" for any kind K - for example, "description of numbers",
    which would be matched by "even numbers".

    This may mean changing a small amount of existing source text; the change
    should be as simple as replacing "description" by "description of objects".
    (We apologise for the nuisance, but "description" was always a poor choice
    of name, clashing with the property called "description", for instance.)

    Given any two kinds K and L, the kind "relation of K to L" is now a kind.
    More concisely, "relation of K" means the same as "relation of K to K".

    Given any two kinds K and L, the kind "phrase K -> L" is now a kind. (This
    is meant to look like a mathematical function arrow.) For example, the
    phrase defined by

    	To decide which number is the square of (N - a number): ...

    has the kind "phrase number -> number". Brackets and commas are used if the
    phrase combines several values: thus

    	To decide which indexed text is (T - text) repeated (N - a number) times: ...

    would have kind "phrase (text, number) -> indexed text". The word "nothing"
    is used if there are no values in, or no value out - thus

    	To decide which number is the magic target: ...

    has kind "phrase nothing -> number", and

    	To dig (eastward - length) by (northward - length): ...

    has the kind "phrase (length, length) -> nothing".

    Thus phrases can be stored in variables, properties and so on. We can give
    any phrase a name like so:

    	To decide what number is double (N - a number) (this is doubling):
    		decide on N plus N.

    This is the same syntax used to name rules, and the idea is the same. If we
    try "showme doubling", the result is

    	phrase number -> number: doubling

    But there's no advantage to storing a phrase if it can't be used, so:

    	showme doubling applied to 2;

    produces

    	"doubling applied to 2" = number: 4

    There are versions of "applied to" for phrases applied to 0 to 3 arguments:

    	F applied
    	F applied to V
    	F applied to V and W
    	F applied to V and W and X

    For phrases which do not produce a value, we use "apply":

    	apply F;
    	apply F to V;
    	apply F to V and W;
    	apply F to V and W and X;

    The default value for "phrase K -> L" is a phrase which, no matter what value
    of K it applies to, always produces the default value of L. It's a sort of
    equivalent of the zero function in mathematics - indeed that's exactly what
    it is, if L is "number". These trivial phrases have no names, but can be
    referred to using "default value of...". Thus:

    	let Q be a phrase numbers -> times;
    	showme Q;
    	showme Q applied to 4;
    	showme Q applied to -7;

    might produce:

    	"q" = phrase number -> time: default value of phrase number -> time
    	"q applied to 4" = time: 9:00 am
    	"q applied to -7" = time: 9:00 am

    Here Q is set to the default phrase because we didn't give it any other
    value; it has the name we might expect ("default value of phrase number -> time")
    and it works as advertised, producing 9:00 am no matter what number is fed in.

    More ambitiously:

    	let R be a phrase numbers -> (phrase numbers -> colours);
    	showme R;
    	showme R applied to 3;
    	showme (R applied to 3) applied to 2;

    might produce:

    	"r" = phrase number -> (phrase number -> colour): default value of phrase
    	number -> (phrase number -> colour)
    	"r applied to 3" = phrase number -> colour: default value of phrase number
    	-> colour
    	"( r applied to 3 ) applied to 2" = colour: red

    In the case where L is "nothing", we get a phrase which does nothing and
    produces no value. For example, if we write:

    	let S be a phrase numbers -> nothing;

    then

    	apply S to 17;

    does nothing at all, but it's perfectly legal.

    Just as phrases now have kinds, the same is true of the other "active" gadgets
    within Inform: activities, rules and rulebooks.

    For any kind K, "activity on K" is a kind. If we write:

    	Tweaking the nose of something is an activity.
    	Refreshing the screen is an activity.

    then the first is an "activity on objects", and the second an "activity on
    nothing". That was true in previous builds of Inform, too, though there was
    no way to express the difference, and so Inform didn't typecheck it. (Indeed,
    it turned out that a minor error in the Standard Rules was going uncaught as a
    result.) But we can now write, say:

    	Announcing something is an activity on numbers.
    	Rule for announcing a number (called N): say "Ladies and gentlemen, [N]."

    and then

    	carry out the announcing activity with 12.

    This won't be useful for many people, but it's more flexible and consistent,
    and activities on pictures and sound effects may be a nice interface for
    multimedia extensions to provide.

    (The word "activity" is now an abbreviation for "activity on value", that is,
    any kind of activity. It's unlikely that anyone will need to change existing
    source text.)

    Rules and rulebooks now have kinds which can be written as follows:

    	rulebook
    	K based rulebook
    	rulebook producing L
    	K based rulebook producing L

    (and similarly for "rule"). See the RULEBOOKS section below for more; if you
    have source text which makes use of values produced by rulebooks, you will need
    to modify it, as those are now typechecked for the first time, and some syntax
    changes have been necessary to make this reliable.

    Finally, two of Inform's ways to store values are similarly extended, though
    in practice it's rare to mention kinds of either sort explicitly in source
    text, so people will mainly not notice.

    	K valued property
    	K valued table column

    As a piece of syntactic sugar, writing "either/or property" is equivalent to
    writing "truth state valued property".

    Given that Inform now has seven constructions on kinds - lists, descriptions,
    relations, activities, rules, rulebooks and phrases - some interesting
    combinations are now open:

    	phrase (relation of numbers to colours, number) -> list of colours

    Brackets can be used to clarify matters:

    	phrase (phrase number -> (phrase number -> number)) -> nothing

    Nothing will make that a simple idea, but it's unambiguous and can be puzzled
    out with practice.

    The following sentences now have identical effect:

    	Concept is a kind.
    	Concept is a kind of object.

    Previously Inform rejected the second form, but it's now being allowed for the
    sake of consistency of syntax. Similarly:

    	The green leather sofa is an object.

    is now allowed; previously Inform would have demanded that it be said to be
    a thing, a door, etc. (In the absence of other information, it will come out
    as a thing, in fact.)

    The kind "table name" can now be the kind of a variable whose value is not
    explicitly declared.

    The kind "action name" can now be repeated through, which means it's now
    legal to form, say, "the list of action names".

    The kind "use option" can similarly now be repeated through, and can be said,
    for the first time. Two new adjectives have been defined for use options:
    "active" and "inactive", with the obvious meanings. This means it's possible
    to describe the current options with something like:

    	say "We're currently using: [list of active use options].";

    The result might be, say,

    	We're currently using: dynamic memory allocation option [8192], maximum
    	indexed text length option [1024], maximum things understood at once
    	option [100], American dialect option and fast route-finding option.

    This may be useful for testing purposes.

    The former condition "using O", true if the option O is active, false
    if not, has not yet been withdrawn but is now deprecated, and may be
    removed in future builds, since it is redundant and less flexible; please
    write "if O is active" instead of "if using O".

    In the early days of Inform, built-in kinds of value had to have single word
    names. That has long ceased to be true, but some of those awkward names
    remained - for example, we had "indexed text" (two words) but "table-name"
    (hyphenated to make it one word). All of those hyphenated kinds of value
    are now written out in words, with the hyphens removed: thus

    	table name    figure name    sound name    action name    equation name
    	external file    Unicode character    use option    table column

    The traditional hyphenated names are still recognised (table-name, figure-name
    and so on), except for the hardly ever used "table-column", but the documentation
    and Index pages always prefer the new unhyphenated forms.

    The following kinds, always intended for internal use only, have been withdrawn:

    	domain-description    miscellaneous-value    text-routine    boxed-quotation
    	rule-outcome    abstract-relation

    8. MAP, FILTER AND REDUCE

    When a mass of computations has to be done, the traditional approach is to work
    through them in a "repeat" loop. One modern alternative, growing in popularity,
    is to form a list of inputs; then apply the same computation to each input in
    turn to form a list of results (this is called "mapping"); throw out any
    bad or unwanted results ("filtering"); and then combine the surviving results
    into a single composite answer ("reducing", though some programming languages
    call this "folding" or "accumulation"; it's a much-reinvented idea).

    Inform provides all three of these fundamental list-processing operations. There
    is no special term for a "map", because Inform treats it as another case of
    "applied to". Thus:

    	doubling applied to {2, 3, 4};

    produces the list {4, 6, 8}. More divertingly, suppose we define:

    	To decide what indexed text is the longhand form of (N - a number)
    		(this is spelling out):
    		decide on "[N in words]".

    	To decide what indexed text is the consonant form of (T - indexed text)
    		(this is txtng):
    		replace the regular expression "<aeiou>" in T with "";
    		decide on T.

    Then we can write a chain:

    	txtng applied to spelling out applied to doubling applied to {3, 8, 4, 19, 7}

    to produce the value {"sx", "sxtn", "ght", "thrty-ght", "frtn"}.

    Next, filtering. Here we make use of descriptions, in order to say what values
    will be allowed through the filter. Thus:

    	filter to even numbers of {3, 8, 4, 19, 7}

    produces {8, 4}, with the values 3, 19, and 7 failing to make it through. (A
    sufficiently fine filter may well thin out a list to a single entry, or even
    no entries at all, but the result is always a list.) To get the full effect of
    filtering, we probably need to define an adjective or two:

    	Definition: an indexed text (called T) is lengthy if the number of
    		characters in it is greater than 6.

    so that we can then write, say:

    	filter to lengthy indexed texts of spelling out applied to {15, 2, 20, 29, -4}

    which produces {"fifteen", "twenty-nine", "minus four"}.

    Lastly, reduction. In order to combine a whole list of values, we need a phrase
    to combine any two. Here are some samples:

    	To decide what number is the larger of (N - number) and (M - number)
    		(this is maximizing):
    		if N > M, decide on N;
    		decide on M.

    	To decide what number is the sum of (N - number) and (M - number)
    		(this is summing):
    		decide on N + M.

    	To decide what indexed text is the concatenation of (X - indexed text) and
    		(Y - indexed text) (this is concatenation):
    		decide on "[X][Y]".

    And here are some sample reductions:

    	let X be the maximization reduction of {3, 8, 4, 19, 7};
    	let Y be the summing reduction of {3, 8, 4, 19, 7};
    	let Z be the concatenation reduction of txtng applied to spelling out
    		applied to doubling applied to {3, 8, 4, 19, 7};

    sets X to 19, the highest of the values, Y to 41, their sum, and Z to the
    indexed text "sxsxtnghtthrty-ghtfrtn". In each case a list has been reduced
    to a single value which somehow combines the contents.

    Is map/filter/reduce always a good idea? Devotees point out that almost any
    computation can be thought of in this way, and in systems where the work has
    to be distributed around multiple processors it can be a very powerful tool.
    (There are programming languages without loops where it's essentially the only
    tool.) At its best, it reads very elegantly: one assembles all of the tools
    needed - definitions of doubling, lengthy, spelling out, concatenation and
    so on - and then each actual task is expressed in a single line at the end.

    On the other hand, there are also times when this is a needlessly complicated
    disguise for what could more easily be done with a "repeat" loop, and also
    more efficiently since assembling and dismantling lists in memory does take
    some overhead time. So these list operations are not a panacea, but it's good
    to have them available.

    9. GENERIC PHRASES

    The following looks quite innocent:

    	To say (V - value) twice: say "[V]. [V], I say!";

    It's clear what we intend it to do, but previous builds of Inform would have
    rejected it. "Value" is not itself a kind - it's too big and unspecific. For
    instance, if we were to allow a variable to be just "a value", we could freely
    set it to 12 one minute and to "dahlias" the next, and such a variable would
    be dangerously useless since we would never know what could safely be done
    with it.

    So "value" is not a kind, but a kind of kind. Inform has quite a few of these:

    	value, pointer value, word value, arithmetic value, enumerated value,
    	sayable value

    Most Inform users never notice these, since they belong to the eight-tenths
    of the iceberg which is underwater, but they act as ways to say "a value of
    any kind matching this can go here". For example, "value" is a way to say
    "any kind at all"; "arithmetic value" is any kind which arithmetic can be
    performed on (any kind with the little calculator icon in the Kinds index);
    and so on. If we write:

    	To double (V - arithmetic value): say "[V times 2].";

    the restriction to "arithmetic value" means that although "double 3", "double
    6 kg", etc., would be matched, "double the Entire Game" would not - you can't
    perform arithmetic on scenes. Similarly, it would have been tidier to write:

    	To say (V - sayable value) twice: say "[V]. [V], I say!";

    because then Inform will make it clearer why "say X twice" won't work if X
    is one of those rare values which it can't say (an activity, for instance).

    Inform has always used generic definitions like these to set up the built-in
    stock of phrases (though only with so-called inline bodies, that is, with
    direct translations to Inform 6 code). In this build, it's now possible to
    write generic definitions using proper Inform source text - so that both of
    the above definitions are accepted, and they work just as they look as if
    they should.

    But those are toy examples. Notice the way "double" just said the answer,
    instead of returning it - the trouble was that, not knowing the kind of V,
    we couldn't say what the kind of its double would be. We needed a way of
    saying "the same kind comes out as went in". This is how Inform expresses that:

    	To decide which K is triple (original - arithmetic value of kind K):
    		decide on 3 times the original.

    Here, K stands for any kind which matches "arithmetic value". Inform supports
    exactly 26 of these symbols, which are written A to Z, but it's customary to
    use K and L. (They can be written in the plural if we like: e.g., "list of
    Ks". But they must always use a capital letter: "list of k" is not allowed.)

    Each symbol we use has to be declared in exactly one of the bracketed
    ingredients for the phrase - here, the declaration is "arithmetic value of
    kind K". That creates K and says that it has to be arithmetic; if we'd just
    said "value of kind K", it could have been anything.

    For a more ambitious example, here is the definition in the Standard Rules
    of the mapping operation described above:

    	To decide what list of L is (function - phrase K -> value of kind L)
    		applied to (original list - list of values of kind K):
    		let the result be a list of Ls;
    		repeat with item running through the original list:
    			let the mapped item be the function applied to the item;
    			add the mapped item to the result;
    		decide on the result.

    Here we needed two symbols to explain the complicated way that the values
    going in and out have to match up to each other. Note also the way that the
    temporary variable "result" is created:

    	let the result be a list of Ls;

    Ordinarily, of course, "L" is not a kind. But within the body of a phrase
    definition, it means the kind which L matched. For instance, if we try

    	showme spelling out applied to {3, 7, 11};

    then in this usage "L" becomes "indexed text", because spelling out is a
    phrase whose kind is "phrase number -> indexed text".

    Sometimes a phrase needs to know what kind it's to work on, but isn't going
    to be given any particular value of it. For example:

    	To assay (name of kind of value K):
    		repeat with item running through Ks:
    			say "There's [item]."

    Note that there's no hyphen, and no name for the bracketed token - it only
    sets K. We can then have, say:

    	assay colours;
    	assay vehicles;

    (But "assay texts;" would throw a problem message, because we can't repeat
    through all possible texts.)

    When a symbol occurs several times in the same definition, subtle differences
    can arise according to which appearance is the declaration. These are not
    quite the same:

    	To hunt for (V - value of kind K) in (L - list of Ks): ...
    	To hunt for (V - K) in (L - list of values of kind K): ...

    Consider:

    	let T be "[location]" in title case;
    	hunt for T in {"Greater London", "Greater Basildon"};

    Here T is an indexed text, but the list is of texts; and a text can be used in
    place of an indexed text, but not vice versa. This will match the first
    definition, because K is set to "indexed text", but it won't match the second,
    where K is set to "text".

    10. PROPERTIES

    The handling of properties has been simplified and made more systematic in
    this build, removing a number of tiresome exceptions. In particular, eight
    ways in which "object" differed from other kinds have been removed:

    (a) It's possible to give properties to "object", and indeed the Standard
    Rules now include:

    	An object has a text called printed name.
    	An object can be plural-named or singular-named. An object is usually
    	singular-named.

    Previously one had to specify them each time for each of the fundamental kinds
    in turn (thing, room, direction, region), which was tiresome. The problem
    was essentially that "object" did not behave as if it were a property-owning
    kind; now it does.

    (b) Relations in groups, one to various relations, various to one relations,
    and one to one relations are no longer restricted to objects - they can be
    defined over all kinds. Again, objects are no longer a special case.

    (c) Properties have always been able to be held by several kinds of object
    independently - for example "matching key" is held by both doors and
    containers - but in previous builds that wasn't true for more general kinds.
    A property of a scene couldn't be a property of anything else. This is no
    longer true. (Indeed, scenes now have the "description" property, just as
    objects do.)

    (d) Any value which can have properties at all can now have a condition
    property, e.g., thus:

    	Colour is a kind of value. The colours are red, green and white.
    	A colour can be bright, neutral or flat. Green is neutral.

    Condition properties were previously restricted to objects only.

    (e) Implications can now be written for any values capable of holding
    properties, not only for objects. Thus:

    	Colour is a kind of value. The colours are red, green and blue.
    	A colour can be zesty or flat. A colour can be bright or dull.
    	Red and blue are bright. Blue is flat.

    	A bright colour is usually zesty.

    results in red being zesty, but blue and green being flat; blue because the
    source text explicitly says so (which trumps the "usually"), and green because
    this isn't a bright colour, so the implication doesn't arise. Again, all of
    this works exactly as it does already for objects.

    (f) Inform has always allowed a piece of double-quoted text, as a complete
    sentence all by itself, to set a description for the object currently being
    talked about. This now works for a named value, too, provided that the
    value is of a kind which has the "description" property. For example,
    the Standard Rules now include the following:

    	A scene has a text called description.
    	When a scene (called the event) begins:
    		if the description of the event is not "",
    			say "[the description of the event][paragraph break]".

    which enables any scene to have a description text, which is printed when it
    begins. For example, we could write:

    	Arrival is a scene. "There's a flourish of trumpets."

    (g) Adjectives can now be given specific definitions for named values.
    (Previously they could be defined for any kind and for any specific object,
    but not for specific values in general.) This allows, e.g.:

    	A colour is a kind of value. The colours are red, green and blue.
    	Definition: red is subtle if the player is a woman.
    	Definition: a colour is subtle if it is blue.

    The first definition here takes precedence, of course, since it has the
    more specific domain. If the player's a woman, the subtle colours are red
    and blue; if not, just blue.

    (h) The pronoun "it" can now mean either an object or a named value, whereas
    previously it could only be an object. Thus:

    	Colour is a kind of value. A colour can be zesty or flat.
    	Mauve is a colour. It is zesty.

    makes mauve a zesty colour. (The restriction to named values is because we
    really don't want "it" to mean 63, or the text "frog", etc., just because
    such a value has been mentioned in a previous sentence.)

    It's now possible to have a topic valued property, that is, a property whose
    content is a topic. (This is possibly useful when defining things or values
    using a table, one of whose columns holds topics.)

    The kinds "figure name", "sound name" and "external file" can all now have
    properties. For example:

    	File format is a kind of value. The file formats are plain
    	text, HTML and CSS. An external-file has a file format.

    	The File of Ghosts is HTML.

    Similarly, all three can be understood in commands. This is likely to be
    useful only for testing purposes, but that's a good enough reason to
    provide it.

    The either/or property "initially carried" is withdrawn, though sentences
    such as:

    	The umbrella is initially carried.

    continue to work, so it's likely that nobody will notice any difference. (The
    word "initially" is redundant here; this property goes back to the early
    days of Inform, when sentences mentioning the player were more restricted.)

    Previously, certain core Inform properties had the anomalous behaviour that
    if they were not explicitly defined then they could be read but not written,
    and would show up as not provided - for instance, the "description" of a
    thing, or the "carrying capacity" of a container. The same wasn't true for
    new properties created within the source text. This anomaly, which came out
    of Inform 6 memory economies now of very little purpose, is revoked. For
    example, a thing with nothing special about it now has the description ""
    (an empty text) rather than not providing a description at all; this means
    that, for example, the test

    	if the description of R is "", ...

    will now work correctly in the case where R is a room whose description has
    never been specified.

    It used to be legal, but deprecated, to create a property like so:

    	An elevator has a number that varies called maximum capacity.

    The "that varies" is redundant here, and confusingly similar to the syntax
    for creating variables. None of the Examples has ever used this syntax, and
    most users probably weren't aware it was allowed. Well, it isn't any more.

    Inconsistencies to do with inherited properties of values are now more
    consistently checked: e.g.,

    	Colour is a kind of value. The colours are red, blue and green. A colour
    	can be vivid or drab. A colour is always vivid. Green is drab.

    now produces a problem message, as it clearly should.

    11. SCENES

    Up to now, every scene has had a "when S begins" and "when S ends" rulebook,
    but there has been no way to express rules generalising about scenes. We
    can now write, e.g.:

    	A scene can be bright or dim. A scene is usually dim. Dawn is a bright scene.

    	When a scene which is bright ends: say "So passes the bright [scene being changed]."

    	When a recurring scene begins: say "Groundhog Day!"

    Scenes can now be understood in commands, which may be useful for testing.

    The built-in Entire Game is not supposed to be modifiable - that is, it can't
    be made to begin or end when other scenes do. This is now enforced with a
    problem message.

    The Scenes index is now more helpful in explaining Entire Game, and also marks
    which scenes are recurring (and this now includes Entire Game).

    12. RULEBOOKS

    "When... begins" and "when... ends" are scene based rulebooks, meaning that they
    take a parameter which is a scene. Inform has always had object based rulebooks,
    but in the past that's been the only kind allowed here; Inform now allows, e.g.:

    	Grading is a number based rulebook.

    	Grading 5: say "It's five. What can I say?" instead.
    	Grading an odd number (called N): say "There's something odd about [N]." instead.
    	Grading a number (called N): say "Just [N]." instead.

    	When play begins:
    	repeat with N running from 1 to 10:
    		say "Grading [N]: ";
    		consider the grading rulebook for N.

    which produces:

    	Grading 1: There's something odd about 1.
    	Grading 2: Just 2.
    	Grading 3: There's something odd about 3.
    	Grading 4: Just 4.
    	Grading 5: It's five. What can I say?
    	Grading 6: Just 6.
    	Grading 7: There's something odd about 7.
    	Grading 8: Just 8.
    	Grading 9: There's something odd about 9.
    	Grading 10: Just 10.

    (A technicality: The familiar IF rulebooks like "instead" are all based on
    actions, not values, so it looks as if they can't fit into this system; but
    they can, because the Inform kinds system treats that as being based on
    the kind "action name".)

    There used to be three ways to describe rulebooks:

    	rulebook    object-based rulebook   action-based rulebook

    (though the last two could only be used at the moment of creation). But now
    we ought to use one of these forms:

    	rulebook
    	K based rulebook
    	rulebook producing L
    	K based rulebook producing L

    Here K is the kind of value we're basing the rulebook on. If this is omitted,
    a test like "(R - rulebook)" will match any basis; and a creation like
    "Drum summons rules is a rulebook." will use the basis "action name" - in other
    words, will make an action-based rulebook. L is the kind of value produced
    (see below) - again if this is unspecified in matching, it can be anything;
    if it's unspecified at creation time, it will be "nothing". Thus

    	Drum summons rules is a rulebook.

    is equivalent to

    	Drum summons rules is an action name based rulebook producing nothing.

    The old syntaxes "object-based rulebook" and "action-based rulebook", with
    hyphens, are still allowed, to avoid breaking existing source text. But
    "object based rulebook" and simply "rulebook" are now preferred.

    The other kind associated with a rulebook is the kind of value it produces,
    though for the great majority of rulebooks this is "nothing" - they don't
    produce values. (None of the rulebooks created by the Standard Rules do, and
    there's only one such across the whole of the Examples.) In past builds, this
    produced value has to be an object, but that wasn't checked, making this
    little-used feature decidedly rickety.

    Making it safe has meant changing the syntax, and that will mean altering
    any existing source text which uses such rulebooks. The one Example we had
    to change ("Feline Behavior") read, in part:

    	The cat behavior rules is a rulebook.
    	[...]

    	Every turn:
    		consider the cat behavior rules;
    		if rule succeeded:
    			let the destroyed object be the result of the rule;
    			[...]

    It now reads:

    	The cat behavior rules is a rulebook producing an object.
    	[...]

    	Every turn:
    		let the destroyed object be the object produced by the cat behavior rules;
    		if the destroyed object is not nothing:
    			[...]

    Put more formally, the following phrases have been withdrawn:

    	rule fails with result (O - an object)
    	rule succeeded with result (O - an object)
    	rule failed with result (O - an object)
    	result of the rule

    A rulebook can now only produce a value if it succeeds; and only if it was
    declared as producing a value; that value can have any kind, and this is
    enforced by Inform; and it can only be obtained if the rulebook is considered
    using the new phrases

    	the K produced by RB
    	the K produced by RB for V

    (the second being used if the rulebook RB is based on some value, and V is
    the one being supplied here).

    It used to be the case that a rule was not allowed to use a named rulebook
    outcome unless it was filed in a rulebook which recognised this. What's now
    true is that it's not allowed to use a named outcome if it's filed in a
    rulebook which doesn't recognise this. The difference is subtle, but it
    means that this combination:

    	Does the player mean removing something not worn by the player from
    		(this is the unlikely to mean removing unworn things rule):
    		it is unlikely.

    	The unlikely to mean removing unworn things rule is not listed in any rulebook.

    ...is now legal, whereas previously it would have thrown problem messages.

    Finally, and unrelatedly, the logic Inform uses to decide what order to place
    rules into rulebooks has been slightly improved. This is something we're
    always wary of tinkering with, but the change means that a domain consisting
    of a kind K together with one or more adjectives will now be considered
    more specific than a kind L together with the same adjectives, if K is itself
    a kind of L. For example, suppose we write:

    	An envelope is a kind of container.

    We then write:

    	[R1] Before printing the name of a closed envelope while listing contents:
    		do nothing instead.

    	[R2] Before printing the name of a closed container while listing contents:
    		say "closed ".

    In previous builds of Inform, [R1] and [R2] were considered to have equal
    specificity, so that the order of their effect would be the order in which
    they were defined; in other words, they will only have the effect intended
    by the writer of the above (Kathleen Fischer, as it happens) one way around.
    In this build, [R1] is considered more specific than [R2], and always takes
    precedence over it, regardless of definition order in the source text.

    13. INFLECTIONS

    (a) Previous builds generated plurals with a very crude algorithm (for instance,
    "day" pluralised as "daies"); this sloppiness was mitigated by the face that
    the user can specify plurals explicitly:

    	The plural of ox is oxen.

    Inform's default pluralisation method is now a form of Conway's algorithm,
    and this should make most uses of "The plural of..." redundant now. For
    example, the following now work:

    	A wolf is a kind of animal. Two wolves are in the Stable.

    and similarly for oxen, geese (but mongooses), sheep, wildebeest, bream and so
    forth among animals alone; Inform constructs plurals such as vertebrae, quartos,
    wharves, phenomena, jackanapes and smallpox correctly. In cases where a noun has
    both a modern and classical plural, Inform prefers the modern form, so brothers,
    not brethren, and cows, not kine. In the spirit of old-school interactive
    fiction, Inform uses Tolkien's invention dwarves, not dwarfs, as plural of dwarf.

    "The plural of..." continues to work, of course, and is still useful for
    cases such as:

    	The plural of brother in law is brothers in law.

    Another improvement is that the new pluralizer respects capitalization, which
    the old one did not:

    	A Rolex is a kind of thing. The player carries two Rolexes.

    would be understood, but an inventory listing would print as "two rolexes".
    It now prints as "two Rolexes".

    (b) In similar vein, a more careful algorithm derived from a pronunciation
    dictionary is now used for choosing between "a" and "an" when Inform has to
    make a guess; thus an honorary doctorate, an FBI windcheater, a U-boat,
    a ouija board, a ukiyo-e print, among many others. But this change will be
    less visible since Inform doesn't often have to guess; it will mainly show
    in problem messages (where Inform will no longer complain that a value
    should have been "an use option" or "an Unicode character", for example).

    (c) Finally, the method used to guess past participles from present participles
    has been improved by the inclusion of some 460 irregular verbs; for example,
    catching to caught, fleeing to fled, crossbreeding to crossbred. This means
    that the "with past participle..." syntax in action definitions now won't
    be needed anywhere near so often, though of course it still works. For
    example,

    	Weaving is an action with past participle woven, applying to one thing.

    can now simply be

    	Weaving is an action applying to one thing.

    A few cases are ambiguous; Inform prefers "got" to "gotten", but it's unlikely
    to arise since in most IF situations "getting" is not an action - instead
    "get" is synonymous with "take" and "taking" is the action.

    14. MINOR NEW FEATURES

    The interpretation of conditions which combine Inform's two past-tense syntaxes
    has been changed. Thus,

    	Every turn when we have waved the candle at least twice: ...

    is legal, but - reading strictly by the specification, as previous builds did -
    "we have waved the candle at least twice" could never be true; it implied
    two or more distinct periods in which it was true that "we have waved the
    candle" was true, with at least one intervening period in which it was false.
    Such a situation can never come about. In this build of Inform, we read the
    condition "we have waved the candle at least twice" to be counting actions,
    not counting periods, which is far, far more likely to be what was meant.

    It has always been possible to indicate map connections using the direction
    alone (the origin being understood as the room being discussed), but up to
    now, only in the form "Direction is Target", like the second sentence here:

    	The Temple is a room. North is the Approach. The Sphinx is east.

    The third sentence now works as expected: the Sphinx being east of the Temple.

    The serial comma is now allowed in sentences like:

    	A room can be lofty, regular, or poky.

    Inform provides two ways to make headings hold source text whose use relates
    to an extension. One is to say something like

    	Part 1a - Alternative Leaps (in place of Part 1 - Leaps in Jumping by Eric Eve)

    which says that what follows should be used instead of what's in the extension;
    the other is

    	Chapter 1P - Sidling (for use with Plurality by Emily Short)
    	...
    	Chapter 1NP - Sidling (for use without Plurality by Emily Short)
    	...

    giving source text to be used depending on whether the extension is being
    included or not. In past builds, these two features were forbidden to "nest";
    in this build, it's only the first kind which can't "nest". (That is, once
    a chunk of text has been used in place of an extension's text, it can still
    contain subheadings "for use with" or "for use without"; but it can't contain
    subheadings "in place of".)

    In previous builds, the "Options.txt" file (if present) was allowed only to
    contain use options - that is, sentences such as "Use American dialect."
    It is now allowed also to contain "Test ..."s and release instructions, so
    for example the following is now a valid "Options.txt":

    	Use American dialect.
    	Test fish with "fish/fish with pole/angle".
    	Release along with source text.

    To recap, "Options.txt" is intended mainly for classroom use, in setting
    up a standard configuration on multiple machines. Here the instructor can
    make sure the Release button will do what she would like, and can arrange
    for each student's copy of Inform to respond to given Test commands: for
    instance, if the class has an assignment to create a simulation of a camera,
    the instructor could set up "Options.txt" so that TEST CAMERA would run
    through some commands the camera ought to respond to.

    (The bug causing "Options.txt" to obstruct the bibliographic titling sentence
    at the top of the visible source text has also been fixed; and a problem
    message has been added for trying to do forbidden things with "Options.txt".)

    The participles "worn", "carried" and "held" are now given additional
    definitions in the Standard Rules as adjectives applying to things:

    	Definition: a thing is worn if the player is wearing it.
    	Definition: a thing is carried if the player is carrying it.
    	Definition: a thing is held if the player is holding it.

    Previous builds allowed some adjectival uses but not others, a little
    inconsistently; for example, the following now works, but previously did not:

    	A diamond bracelet is here. It is wearable. The description is
    	"It sparkles [if worn]on your wrist[otherwise if carried]in your
    	hand[end if]."

    The adjectives "on-stage" and "off-stage" can now be made true using "now",
    so, for instance, "now the diamonds are off-stage" is equivalent to "remove
    the diamonds". (If we say "now the diamonds are on-stage" and they already
    were, nothing happens; if they weren't, they are moved to the current
    location.)

    There are three new forms of "[one of]":

    	"Maybe the victim is [one of]Adam[or]Bertrand[or]Carlos[then purely at
    		random]."
    	"Maybe the murderer is [one of]Colonel Mustard[or]Professor Plum[or]Cardinal
    		Cerise[then at random]."

    The first means that the alternatives are chosen in sequence until all have
    been seen, but that after that they are chosen uniformly randomly. The
    second is similar, except that once randomness is reached, care is taken to
    avoid the same choice coming up twice running.

    The third is really a shorthand form:

    	"The screen door squeaks loudly as when you open it. [first time]Well,
    	you'll get used to it eventually. [only]"

    This is exactly equivalent to

    	"The screen door squeaks loudly as when you open it. [one of]Well,
    	you'll get used to it eventually. [or][stopping]";

    but easier to read.

    Inform, like Python and some other languages, uses indentation from the left
    margin to show how phrases are grouped. In past builds, the practical limit
    was 9 tab stops in, though this wasn't very clearly explained and the problem
    message if exceeded was cryptic. The limit is now raised to 25 and a better
    problem message has been created.

    The phrase "repeat with V running from X to Y" previously worked only when X
    and Y were numbers; it's now allowed for any arithmetic or enumerated values,
    so

    	repeat with counter running from 1 to 10:
    		...
    	repeat with counter running from 4 PM to 4:07 PM:
    		...
    	repeat with counter running from orange to indigo:
    		...

    are all allowed (supposing that we have a colour kind whose values are, say,
    red, orange, yellow, green, blue, indigo and violet).

    The phrases for making entries in a table blank have been made more consistent:

    	blank out (table entry)
    	blank out the whole row
    	blank out the whole (column) of (table)
    	blank out the whole of (table)

    (The last two abilities are new.)

    The phrases for altering the length of a list are worded using "entries";
    for example, "truncate L to 10 entries". It's now legal to use the singular,
    "truncate L to 1 entry", too.

    Previous builds allowed rules in the "printing a parser error" activity to
    test which error had occurred using rather clumsy fixed-wording phrases:

    	if parser error is can only do that to something animate: ...

    These have been withdrawn. For this build, the following should be used
    instead:

    	if the latest parser error is the can only do that to something animate
    		error: ...

    This is tidier since it is a standard comparison. A new kind of value,
    "command parser error", exists to hold the possibilities; "can only do that to
    something animate error" is one of these. (The others are listed on the Kinds
    index page. They are all worded exactly as before, with the addition of the
    word "error" at the end, as in this case.) The advantage of the new system,
    aside from getting rid of 19 clumsy phrases, is that "latest parser error"
    is now a variable; the value can be said, or stored, and so on. This is all
    much more flexible.

    In the startup rulebook, the first two rules - in fact, the first two rules
    every Inform story file runs - have been transposed. So the initialise memory
    rule now happens before the virtual machine startup rule, not vice versa.
    Because the latter rule runs the "starting the virtual machine" activity, the
    effect is that we sacrifice a little bit of that activity's ability to be
    the very first thing run; but we gain the ability for this activity to use
    indexed text, stored actions, and similarly complex data, since those depend
    on memory having been initialised.

    There is now a way to define an adjective in terms of an Inform 6 routine
    which is more capable, since it can not only be tested, but also made true
    or false using "now". For example:

    	Definition: a scene is crucial if I6 routine "SceneCrucial" makes it so
    		(it is essential to winning).

    This is very similar to the existing syntax:

    	Definition: a scene is vital if I6 routine "SceneVital" says so
    		(it is essential to winning).

    (a) Whereas "SceneVital" is just a test, "SceneCrucial" is called with two
    arguments: SceneCrucial(S, -1) tests whether the scene is crucial or not and
    returns true or false; SceneCrucial(S, true) must make it true; and
    SceneCrucial(S, false) must make it false.

    (b) If the adjective is defined over a kind of values stored in block form
    on the heap, S is passed as a pointer to the block, not as a fresh copy.

    Inform's automatically generated documentation on included extensions has
    always listed names of kinds, objects, variables and so on; it now also lists
    names of use options.

    The maximum complexity of a single "say" - basically, the maximum number of
    chunks it can contain, some being fixed text, others being substitutions -
    has been increased from about 400 to about 4000. (In practice this removes the
    limit altogether, since the maximum length of a single quoted text gets in
    the way first. Having any maxima at all is unfortunate, of course, but it
    enables the compiler to run faster, and makes it easier to catch punctuation
    mistakes in the source.)

    When Problem messages are reported inside an extension, Inform typically says
    under what headings they occur, but doesn't make clear which extension is
    involved, which can be a nuisance if many extensions are in use. In this build,
    Inform explicitly names the extension.

    A new use option, "Use no deprecated features", puts Inform into a mode where
    it issues problem messages for syntaxes which are currently allowed but which
    we expect to withdraw in future. At present this is used only with phrases;
    see the Phrasebook index, where deprecated usages are marked with a red
    warning triangle.

    15. WORD LIMITS ON RELATIONS, VERBS, PREPOSITIONS AND DIRECTIONS

    Most constructions in Inform can have quite long names. But in previous
    builds, much tighter limits were placed on relation names, parts of verbs,
    the wording of prepositions, and the names of directions.

    					Example         Old maximum     New maximum
    Relation name       containment     1               X - 1
    Part of verb        wears           1               X - 4
    Preposition         across from     3               X - 2
    Direction           northwest       3               X - 2

    The intention is that there should be no practical limit in any of these
    cases; the current value of X is 32, which it's very difficult to see any
    plausible source text ever needing to exceed.

    For example, this is now allowed:

    	The verb to cover oneself with (he covers himself with, they cover themselves
    	with, he covered himself with, he is covering himself with) implies the
    	wearing relation.

    	Peter is covering himself with a tent-like raincoat.

    Here each part of the verb is three words long; the maximum is now 28.
    Similarly:

    	The verb to be very far away from implies...

    is a preposition four words long, which previous builds would have rejected.
    The limit is now 30.

    	Adept sensitivity relates one person to one vehicle.
    	The verb to imagine (he imagines, they imagine) implies the adept sensitivity
    	relation.
    	Peter imagines the Astral Chariot.

    Here we have a relation, "adept sensitivity", which is two words long; the
    limit is now 31.

    And if you should want:

    	Just the tiniest smidge off magnetic north is a direction. The opposite of
    	just the tiniest smidge off magnetic north is just the tiniest smidge
    	off magnetic south.
    	Just the tiniest smidge off magnetic south is a direction. The opposite of
    	just the tiniest smidge off magnetic south is just the tiniest smidge
    	off magnetic north.

    then knock yourself out.

    >--> Note that when a direction is created, a relation is automatically created
    to represent being in that direction; for instance, "north" creates what is
    now called the "mapping north relation". It used to be called the "mapping-north
    relation", with a hyphen, to squeeze into the former requirement that relations
    have one-word names. It's unlikely that much source text makes direct use of
    these relations by name, so the change will probably not be noticed.

    16. ACTIONS IN THE STANDARD RULES

    Some of the small design decisions about actions in the Standard Rules go back
    to accidents of implementation in the early 1990s (if not earlier still), and
    have no rationale except custom and practice. We are very conservative about
    changing them, all the same, since anything done here will affect essentially
    every source text compiled with Inform. But for this build we have made a
    systematic search for small changes, unlikely to cause much disruption, but
    which will improve the playing experience.

    (a) In its earliest works, Infocom introduced the now-traditional commands
    VERBOSE, BRIEF and SUPERBRIEF for the player to choose how much detail to
    see in room descriptions: the whole thing, even for a room revisited; the
    whole thing the first time, but an abbreviated form after that; or always
    only the abbreviated form. The default mode was BRIEF, the middle of these
    positions.

    In 1993, when Inform made its debut, this was still conventional, but since
    then authors and players have increasingly found VERBOSE mode more natural.
    Even a tiny iPhone screen shows more text that a 1980s micro did, and printing
    time is now essentially zero, whereas a long description could take five to
    ten seconds to print back then. Inform's fellow IF development system TADS
    has long since used VERBOSE as the default; from this build, Inform is finally
    following suit. So, farewell to default BRIEF mode (1981-2010).

    Three new use options exist to set the default behaviour:

    	Use VERBOSE room descriptions.
    	Use BRIEF room descriptions.
    	Use SUPERBRIEF room descriptions.

    So if this change causes problems, simply add "Use BRIEF room descriptions."
    to restore the old behaviour. For us, it changed the blessed transcripts of
    45 out of about 440 examples, but never such that we minded the change.

    (b) Inform has always been liberal in how it reads the word ALL in commands
    typed by players - TAKE ALL really does mean all - but has given authors
    the option to change this by writing rules for the "deciding whether all
    includes" activity. As from this build, the Standard Rules include three
    such rules to strike out people, scenery and things fixed in place. Thus:

    	Studio is a room. Jenna is a woman in the Studio. Kenneth is a man in the
    	Studio. The peacock, the script and the stage set are in the Studio.
    	The stage set is fixed in place. The curtains are scenery in Studio.

    the traditional reply to TAKE ALL would be:

    	Jenna: I don't suppose Jenna would care for that.
    	Kenneth: I don't suppose Kenneth would care for that.
    	peacock: Taken.
    	script: Taken.
    	stage set: That's fixed in place.
    	curtains: That's hardly portable.

    With the new default conventions, it's just:

    	peacock: Taken.
    	script: Taken.

    The new rules are named, of course, and can be cancelled if unwanted (see the
    Rules index):

    	exclude scenery from take all rule
    	exclude people from take all rule
    	exclude fixed in place things from take all rule

    (c) In this release, the Inform parser changes the default way in which it
    asks what is meant by an ambiguous noun such as FROST. It can ask the
    question in two different forms:

    	(1) Who do you mean, Jack Frost or Jill Frost?
    	(2) Which do you mean, Jack Frost or Jill Frost?

    In the past it has used form (1) if the token being parsed was "[someone]",
    and (2) otherwise. This wasn't very accurate, as plenty of other tokens might
    expect a person rather than a thing to be typed; but in English, it didn't
    matter very much, because "which" wasn't too bad for people. In German, it
    made a bigger difference, and at Christian Blümke's suggestion we are
    incorporating a change worked out by German Inform users: message (1) is used
    if all of the possible meanings refer to people, and message (2) otherwise.

    (d) We have withdrawn the:

    	examine undescribed containers rule

    and replaced it with two new rules:

    	examine containers rule
    	examine supporters rule

    The original rule converted the action of examining a container which had
    no description text into a searching action instead. Sometimes this was a
    sensible idea, but not always. Examining and searching are different actions,
    and why should it make a difference whether there's any description or not?
    (The original idea was to avoid a misleading "You see nothing special about..."
    reply about a container which, in fact, contained interesting items. But
    however pragmatic that is, it's not very convincing as a reason.) Moreover,
    examining something requires only a line of sight to it, whereas searching
    requires that the actor can touch the item in question; so converting one
    into the other violates the spatial world model in some cases.

    The new rules are (equivalent to) this:

    	Carry out examining (this is the examine containers rule):
    		if the noun is a container:
    			if the noun is open or the noun is transparent:
    				if something is in the noun:
    					if the description of the noun is not "":
    						say "[the description of the noun][paragraph break]";
    					say "In [the noun] [is-are a list of things in the noun].";
    					stop the action.

    and similarly for supporters, but without transparency being an issue.

    (e) We have withdrawn the:

    	examine described devices rule
    	examine undescribed devices rule

    and replaced them with the:

    	examine devices rule

    which works much as the rules for containers and supporters do: the
    description paragraph first, if there is one, then the status of the device
    ("The hot tap is switched on.").

    (f) The command "switch [something]" is now understood as switching off if the
    item in question is currently a device switched on, and vice versa. (Previously
    it would always be understood as switching on.)

    (g) The command "fix" is no longer a synonym for "tie". (There is too much
    confusion of the two senses - "fix" in the sense of affix may mean "tie", but
    "fix" in the sense of repair does not.)

    (h) The command "get down" is now understood as exiting. (A natural thing to
    type when, say, at the top of a library stepladder.)

    (i) The command "get in" is now understood as equivalent to typing just
    "enter". In general "enter" requires a noun - there could well be a choice
    of enterable things available - but a rule new in this build, the

    	find what to enter rule

    automatically infers an enterable noun in the current location, if one is
    available. (It has no effect if the player has typed something explicit, such
    as "enter cage".)

    (j) The command "look [something]" is understood as examining, as if it had
    read "look at [something]". (This is not so much aimed at retro gaming fans
    who want to recreate the full 1982 experience, but at novices, who often seem
    to type commands like this.)

    (k) In previous builds, the going action would be stopped by the

    	can't go through closed doors rule

    if the actor would need to pass through a closed door. That remains true, but
    if the door is openable then the rule now tries opening the door first - thus
    allowing players to walk through ordinary doors without having to type
    explicit "open door" commands. (The popular "Locksmith" extension has always
    provided this; anyone using that extension will see no change.)

    (l) A new rule for the going action, the

    	stand up before going rule

    causes an actor to try getting off a supporter before going in a given
    direction. (A rule which was previously an optional extra, demonstrated by the
    "Hagia Sophia" Example. Use of the "Rideable Vehicles" extension unlists this
    rule, i.e., abolishes it, since this extension makes supporters into mobile
    things which can indeed be used to go from place to place.)

    (m) The "putting it on" and "inserting it into" actions require the item
    being put or inserted to be held by the actor; if it isn't, one of the rules:

    	can't put what's not held rule
    	can't insert what's not held rule

    will stop the action. In this build, they first try to take the item, and
    only stop the action if that fails.

    (n) A quaint convention going back to the mid-1980s is that an inventory
    listing changes the meaning of pronouns like "it". Thus

    	> INV
    	You are carrying a pineapple.
    	> EAT IT

    ...would result in "it" meaning the pineapple. We think it's time to give up
    on this convention, which causes nothing but confusion. Accordingly, we have
    deleted the rule responsible:

    	use inventory to set pronouns rule

    (o) The run-time parser's handling of commands with commas in has been
    changed; previously, a command such as

    	> FRED, GO NORTH

    would be parsed as an instruction for Fred to do something only because
    FRED was not recognisable as a verb. This turned out to be unfortunate for
    story files with Japanese characters called Takemoto ("Take" for short), or
    for anyone called Don (a verb for putting on clothes), and so on. The
    parser now considers the command to be an instruction provided that the
    text up to the comma matches the name of a possible actor; this avoids
    (most) false positives such as

    	> TAKE BELL, BOOK AND CANDLE

    (p) The "exiting" action has long had a variable called the "container
    exited from", so that it's possible to write rules depending on what is
    being got out of. This can now be referred to using "from", as in the
    following example:

    	After exiting from the Mini Cooper:
    		say "You painstakingly unpack your limbs from the tiny car."

    (q) The "giving" action has a new rule, imitating a similar one for dropping:

    	can't give clothes being worn rule

    (r) The "removing it from" action has an exemption in the "can't remove from
    people rule", so that in the event that the actor is trying to remove something
    from himself, this is converted to a taking off action. (For instance, if the
    player is involuntarily wearing a monkey on his back, and types REMOVE
    MONKEY FROM ME.)

    (s) The commands TAKE ... OFF and PUT ... ON are now understood as taking off
    and wearing, respectively, just as the commands TAKE OFF ... and PUT ON ...
    always have been.

    (Translators may need to note that as a result of these changes three library
    messages, going action number 3, 4 and 5, have been removed; but there are
    also three new ones, going action number 27 and 28, and Miscellany 75, which
    is " The End " in English, and is used to provide a generic ending message.)

    17. DOCUMENTATION, PROBLEMS AND INDEX

    Problem messages reformatted to give more information in case of complicated
    ambiguities to do with phrases; and problems suppressed when they are
    follow-on problems arising only because variables weren't created properly.
    For example, this source text:

    	Every turn:
    		repeat with X running from 1 to "fish":
    			say "Hello! [X].";
    			let Y be X plus X;
    			increase score by Y;

    would throw four problem messages in previous builds, but now it throws only
    one. Inform realises that the author intends to create X, and even though he
    botched it, Inform suppresses what would otherwise be problem messages in the
    next two lines; it further realises that the idea is to create Y as well, and
    suppresses the problem message that the last line would otherwise lead to.

    The Phrasebook index has been redesigned. Each phrase is now provided with
    a "plus" icon which, when clicked, reveals full documentation of what that
    phrase does, along with a link to the relevant page in the manual; and the
    manual has similarly been redesigned to match the Phrasebook.

    The Kinds index has been reorganised to reflect the new structure of the
    kinds system in Inform.

    The Contents index now includes links to the documentation for any extensions
    included in the project being indexed.

    Timed events have moved from the obscure sub-panel of the Rules index, where
    they had previously languished unnoticed, to the Scenes index. They now
    include cross-references for each event to the points in the source text
    which trigger them.

    The Scenes index now marks which scenes are recurring, and clarifies the role
    of the special Entire Game scene.

    18. DEPRECATED PHRASES

    With this build, we take a first step towards removing a few features of the
    Inform language which, in the light of experience, we regret having introduced.
    A few syntaxes change with every major release, of course, but we plan a
    bigger change next time, and are now preparing the way for this.

    There are some 367 built-in phrase definitions in the Standard Rules. The
    great majority will stay, of course, but we intend to remove 34 of these
    phrases in the next big release of Inform. This will inevitably cause a
    little disruption, so we've done three things to ease the way:

    (a) Each phrase due to be removed is now officially "deprecated", and marked
    with a red warning triangle in the Phrasebook and in the documentation.
    The documentation explains what to use instead.

    (b) Deprecated phrases are not used in the Examples, except for a very few
    cases where the only purpose of the Example is to show how to use the phrase
    in question. They are similarly avoided by built-in Extensions, including the
    Standard Rules.

    (c) A new use option has been added:

    	Use no deprecated features.

    With this set, Inform will reject any of the deprecated phrases; so setting
    this is a good way to see whether any existing source text is likely to give
    trouble after the next release.

    The deprecated phrases are a mixed bunch:

    	say "[contents of object]"
    	say "[the contents of object]"
    	change (a stored value) to (value)
    	change (object) to (property)
    	change (object) to (enumerated value)
    	delete (a table entry)
    	if using the/-- (use option):
    	if (a condition) then (a phrase)
    	while (a condition) repeatedly (a phrase)
    	while (a condition), (a phrase)
    	ignore (rule)
    	reinstate (rule)
    	reject the result of (rule)
    	accept the result of (rule)
    	substitute (rule) for (rule)
    	restore the original (rule)
    	move (rule) to before (rule)
    	move (rule) to after (rule)
    	end the game in death
    	end the game in victory
    	end the game saying (text)
    	resume the game
    	if game is in progress:
    	if game is over:
    	if game ended in death:
    	if game ended in victory:
    	if it is before (time):
    	if it is after (time):
    	change the/-- player to (object)
    	if in (object):
    	award (number) point/points
    	set pronouns from possessions of the player

    Some of these are very familiar-looking, but almost all simply duplicate more
    general constructions. "award 5 points", for instance, is exactly the same as
    "increase the score by 5"; "change the time of day to 10 PM" is the same as
    "now the time of day is 10 PM". Exotic forms of "if" and "while" are being
    removed for simplicity's sake: people didn't use them much in practice.
    That leaves two clusters of phrases - those for ending the game, and those
    for procedural rules. With ending the game, we have adopted a more uniform
    style of wording, and abolished the idea of "death" and "victory":

    	end the story
    	end the story finally
    	end the story saying (text)
    	end the story finally saying (text)
    	if story has ended:
    	if story has ended finally:
    	if story has not ended:
    	if story has not ended finally:
    	resume the story

    The difference between ending and ending finally is that a final ending is
    one where we don't expect the reader to play again, and can safely show him
    menu options such as Infocom's traditional AMUSING (which suggests alternative
    unlikely possible plays). Thus "game" becomes "story", "death" becomes merely
    the "end" and victory the "final end". In the process, we gain the ability to
    have a final ending with wording other than "You have won"; and the default
    ending text is now "The End", not "You have died". Sic transit gloria mundi.

    Procedural rules, on the other hand, definitely do provide functionality
    which is not available otherwise by a simple rewording. When they go, they
    will be a small loss. But after four years of Inform 7's public use, we
    find that very few people use them, and then almost always in situations
    where it would be just as good to use "not listed in" sentences instead -
    the main use of procedural rules is to abolish some built-in rule, but
    that can be done just as well by unlisting it.

    The reason for removing procedural rules is that it will enable optimisations
    of the code generated by Inform to get faster run-time performance, which we
    expect to become a more significant issue in future - the time may come when
    the majority of IF players are running the story file in a browser; perhaps
    even a browser on a relatively slow-CPU mobile device, such as an iPad. We
    also hope to bring down the writeable memory usage at run-time, which is an
    issue for story files running on the Z-machine (though not for Glulx, where
    memory is essentially unlimited). Besides this, procedural rules often
    confused authors (hardly anybody knows the difference between "follow" and
    "consider" - a difference which will be abolished), and they made the Index
    a little misleading, since it displayed the structure as it was before
    being manipulated.

    So we have swallowed our medicine, and deprecated procedural rules. They
    were cool, but not worth the cost.

    19. MAINTENANCE

    There are so many bug fixes that a miscellaneous list has become unwieldy,
    so here they are categorised under the headings used by our new bug-tracker.
    Note that the following list excludes fixes to built-in extensions such
    as Locksmith or Metric Units: for those, see below.

    19.1. Source text and punctuation

    (*) Bogus times of day such as "minus 6:23 PM" are no longer recognised; "minus"
    can only be used with relative times, as in "minus six minutes".

    (*) The I6 template reader has been made more forgiving of what it considers
    malformed headings - marked by the use of an "@" character in the leftmost
    column; some users ran into this by accidentally placing Z-machine or Glulx
    assembly language, also marked by an "@" in I6, unindented on the left
    margin of material included using "(-" and "-)". The template reader will
    now handle any such material correctly, and a more helpful problem message
    is produced if it nevertheless runs into trouble because of a stray "@".

    19.2. Headings

    (*) Bug fixed whereby it's impossible to use a heading to replace an existing
    heading in an extension if that existing heading contains the words "in"
    or "by" in its name; and problem messages related to heading tricks made
    more explanatory.

    (*) Part 3 of the Standard Rules now has slightly better section divisions,
    making it easier to replace smaller chunks.

    19.3. Extensions

    -- -- --

    19.4. Assertions and creations

    (*) Bug fixed whereby "There are ..." sentences might fail if a number of things
    were created with some modifying adjective, e.g. "There are four closed doors."

    (*) Bug fixed whereby a player declared to be a particular person would not
    always be placed into relationships asserted for "the player". For example,

    	The player is a woman called Edna Marsh. The player holds a wrench.

    ...not resulting in Edna carrying the wrench.

    (*) Problem message added to explain oddball mistakes like "A thing is a waiting
    receptacle if it is an open container.", which in previous builds were met
    with a rather vague and unhelpful complaint.

    19.5. Model world

    (*) Bug fixed whereby generalising about the "map region" property could cause
    an internal error; for instance,

    	The map region of a room is usually Jaguar Creek Valley.

    Setting "map region" is not the preferred way to put rooms into regions,
    but the above did work in past builds (and the "Permission to Visit" extension
    apparently made use of that); the practice is hereby legalised, and the World
    index now properly maps the result.

    (*) Bug fixed whereby the fast route-finding algorithm for finding routes through
    the map (the default route-finder in Glulx, but only used if the "Use fast
    route-finding" option is chosen in the Z-machine) would always use doors,
    even when not allowed to, and would return 0 rather than -1 for a count of
    the number of steps of an impossible route.

    (*) Bug fixed whereby the fast route-finding algorithm for finding routes through
    the map would sometimes return "north" as the "best route from X to Y" in cases
    where no route exists, rather than returning "nothing".

    (*) Bug fixed whereby sudden movements of the player from a dark room into a
    lighted one, which happen other than by the usual actions, could result in
    the new room's description being shown twice over.

    (*) Bug fixed (if it was really a bug) whereby the "maximum score" could not be
    changed during play.

    (*) Bug fixed whereby UNDO would be disallowed in a story where the "advance
    time rule" had been unlisted, with Inform thinking that (since no time had
    passed) there was nothing to UNDO back to.

    (*) Problem message added to catch unused timed events. This is an arguable case,
    because perhaps it could be said that it's legal to create timed events which
    are never used. But it's a better idea to catch mistakes like this:

    	At the time when supply of the air tank is -4:
    		end the game saying "You have suffocated."

    where the author believes incorrectly that the rule will fire when the
    condition is true, whereas actually he has created a timed event with the
    exotic name of "supply of the air tank is -4".

    (*) Problem message added (in place of internal error) when a door is said to
    be "south of nowhere", or for other such formulations involving "nowhere" as
    the source of a map connection.

    (*) Problem message added for non-thing objects being created inside or on top
    of other objects. (The world model requires that the contents of a room must
    be things, but earlier builds didn't check this; at run-time, strange things
    could then occur.)

    (*) Problem message added (in place of internal error) for making a direction
    whose opposite does exist, but isn't a direction.

    (*) Problem message added for misunderstandings like "When the play begins..."
    instead of "When play begins...".

    19.6. Properties

    (*) Bug fixed whereby Inform confuses a property of an object with a use of a
    value phrase containing the word "of" - for example, misreading "room
    illustration of the location" as an attempt to use the phrase "room D of R"
    (for looking up the map) rather than an attempt to access a property called
    "room illustration".

    (*) Bug fixed whereby property declarations such as "A room that is dark can be
    dangerous." would wrongly be accepted, but would have adjectives or qualifiers
    such as "that is dark" ignored. (It's incorrect to make a declaration like
    this because the owner of a property has to own it all of the time, no
    matter what; it can't have it only when it's dark.)

    (*) Bug fixed whereby adjectives declared in the form "...if its P is V" (which
    check that a property P has value V) would always be false for text properties;
    thus, "Definition: a childhood memory is forgotten if its recollection is ""."
    would fail to work.

    (*) Bug fixed whereby antonyms of adjectives declared in a way which laid them
    out as phrases, like so...

    	Definition: A thing (called the item) is handy rather than useless:
    		if the item is openable, decide yes;
    		decide no.

    ...would fail to work: "handy" would work perfectly, but not "useless", which
    would in some circumstances produce I6 errors.

    (*) Bug fixed whereby descriptions implicitly given to kinds are now taken as
    being likely but not certain; as a result, the following is now possible,
    whereas previously it was reported as a contradiction:

    	A folding metal chair is a kind of supporter.
    	"The chair looks only moderately uncomfortable."
    	The small chair is a folding metal chair in test room.
    	"The chair looks painful to sit in."

    (*) Problem message added for definitions which try to use "or more" or "or less"
    with non-arithmetic values, e.g.,

    	Definition: a person is cool if his callsign is "dude" or more.

    (*) Problem message added to catch attempts to give properties to a set of owners
    which changes during play, e.g.,

    	Colour is a kind of value. The colours are red and green.
    	A thing has a colour.
    	Taste is a kind of value. The tastes are sweet and sour.
    	A thing has a taste.
    	The taste of a red thing is usually sweet.

    (*) Problem message added (in place of internal error) for understanding a
    property in the description of something, when the property is one whose
    value is an object of a kind outside the usual spatial model (i.e., neither
    room, thing, region nor direction).

    (*) Problem message added (in place of what was in some circumstances an internal
    error) when an either/or property is assigned using "has" instead of "is",
    e.g., "The teddy bear has fuzzy."

    19.7. Relations

    -- -- --

    19.8. Actions

    (*) Bug fixed whereby variable declarations for actions whose names include the
    words "with" or "having" (either not at the end, or not after "it") would
    produce spurious problem messages.

    (*) Bug fixed whereby an action in which the player asks someone else to do
    something, which then fails because the persuasion rules halt the process,
    would result in "reason the action failed" not properly being set. (It's now
    set to the identity of the persuasion rule which stopped the action.)

    (*) Bug fixed whereby Inform would fail to recognise actions involving actors
    whose names include words with an "-ing" suffix, and where the longhand
    "trying" syntax isn't being used. Thus if somebody's full name is "Regional
    Training Officer Tina", Inform was failing to recognise "Tina examining the
    clipboard" as an action, simply because of the word "Training" in her full
    name. Inform now allows such readings in any case except where the action
    verb is itself part of the actor's full name; thus, if there were an action
    called "training", Inform wouldn't like "Tina training Kevin", which would
    look to Inform like a row of names of people; and the author would have
    to rephrase in the longhand form, "Tina trying training Kevin".

    (*) Bug fixed whereby actions out of world applying to a topic would have the
    topic noun empty, rather than containing the text of the topic as they
    should; for instance, in this combination:

    	Helping is an action out of world applying to one topic.
    	Understand "help [text]" as helping.

    the command HELP RICHARD STRAUSS would fail to have the noun set to the
    snippet RICHARD STRAUSS of the command, as would happen for an action
    in world. This wasn't a deliberate restriction - it was a bug.

    (*) Bug fixed whereby out of world actions in one pass of the turn sequence
    rules could sometimes cause the next pass of the turn sequence to begin
    as if we were still out of world, making it difficult to try in-world
    actions before a command had been typed; this caused the following not
    to work -

    	This is the Luciano's actions rule: try Luciano singing.
    	The Luciano's actions rule is listed before the parse command rule
    	in the turn sequence rules.

    - in the turn after a command like VERSION or VERBOSE.

    (*) Bug fixed (or perhaps it's really that Inform's specification has been
    clarified) so that a rule like this:

    	Every turn jumping for three turns: say "A demon appears!"

    does take effect if the player jumps twice, types SAVE, and then jumps a
    third time; that is, the saving the game action does not interrupt the
    count up to three. (Because saving the game is out-of-world, and so doesn't
    take up a turn.) On the other hand, a rule like this is fine:

    	Check requesting the pronoun meanings for the first time:
    		say "The PRONOUNS command is very useful. To explain: ...";
    		continue the action.

    since although "requesting the pronoun meanings" happens out-of-world and
    can't take place for a number of turns, it does take place for a number
    of times.

    (*) Bug fixed whereby references to things having happened "for exactly 0 turns"
    would fail to work, e.g.:

    	if the rose has been visible for exactly 0 turns

    (*) Bug fixed whereby "try", when used to cause an out-of-world action by the
    player during an existing action by somebody else, could sometimes cause a
    consecutive in-world action by that other person to be misconstrued as
    being out-of-world. For example:

    	Instead of an actor waiting:
    		try requesting the pronoun meanings;
    		try the actor saying yes.

    might result in the "saying yes" action being rejected as out-of-world and
    thus unavailable to an actor other than the player.

    (*) Bug fixed whereby before, instead or after rules would sometimes be included
    on the Index pages for out-of-world actions, despite the fact that they
    cannot affect these.

    (*) Bug fixed whereby lists of actions would sometimes be misread if entries
    were ambiguous as to which action was meant, e.g.,

    	Instead of doing something other than waiting or examining or taking
    	inventory or looking: ...

    was misread as if "taking inventory" were simply "taking".

    (*) Problem message added to catch attempts to file rules about out-of-world
    actions into the before, instead or after rulebooks (where they can have no
    effect under any circumstances, since these aren't consulted for OOW actions).

    (*) Problem message added to catch mixtures of in-world and out-of-world actions:

    	Instead of requesting the pronoun meanings or taking inventory: ...

    (*) Bug fixed whereby a stored action which involved a value would sometimes be
    said incorrectly (though in other ways it was okay): for example,

    	Factoring is an action applying to one number.
    	...
    		let the best idea be the action of factoring 15;
    		say "You consider [the best idea].";

    would say the action as "factoring -23145", or some other mysterious number.

    19.9. Activities

    (*) Bug fixed whereby global variables could not appear in "... while ..."
    clauses to do with activities, so that this for instance would not work:

    	For printing the name of the banana while listing contents of the player:
    		say "yummy banana".

    ...whereas the same thing with "yourself" instead of "the player" would work.
    They now both do.

    19.10. Rules and rulebooks

    (*) A minor change which looks like a bug fix, but isn't, strictly speaking:
    when a bare adjective is used as a condition attached to an action, as here -

    	Instead of doing something when off-stage:
    		say "After the thrill of the spotlight, life seems not to exist."

    - the adjective is now assumed to apply to the person performing the action.
    (In this case that's the player, who can never be off-stage, so that the
    message can't be said. But the principle is the important thing.)

    (*) Bug fixed whereby compound conditions which included spurious additional
    "when" or "while" words could cause Inform to hang, or crash; for example,

    	Test Scene begins when the player is in the First Room or when the
    	player is in the Second Room.

    (It should be just "or the player...", not "or when the player...". Inform
    now catches this with a more on-point problem message.)

    (*) Bug fixed whereby rules using "going nowhere in R" for some room R, or
    "going somewhere in R", would fail to be matched correctly; so that this, for
    example, wouldn't work:

    	Instead of going nowhere in the Home: say "You'd just get homesick."

    (*) For clarity's sake: rules written thus...

    	Instead of yourself going: ...

    where the actor is explicitly named as "yourself" (or "the player"), now work
    as the writer might expect (i.e., as if it just read "Instead of going: ...").
    Hard to know whether this is a bug fix or not - arguably it's less consistent
    this way, because the convention is that an action is by the player unless
    a specific actor is named. But what matters is that the sense should
    be right for the reader.

    (*) Bug fixed whereby rules depending on something in the past tense being true
    over a period which is itself in the past would sometimes not fire. For
    example,

    	Before doing something when the hat has been worn for three turns: ...

    (*) Bug fixed whereby an I7 name given to a rule defined by an I6 routine would
    sometimes be confused with the name of a new object, if used as the value
    of a property, or in some other assertion sentence contexts.

    (*) Problem message added (in place of sometimes mysterious other problem
    message(s)) to catch attempts to use "called" to make a name which already
    has another meaning and where confusion may occur. For example, an attempt
    to write:

    	Instead of giving something (called the number): ...

    cannot possibly end well, but Inform would previously allow the calling, then
    throw problem messages later on when it was used.

    19.11. Lists

    (*) Bug fixed whereby lists of lists of indexed texts (and similar constructions)
    could lose their identities when printed.

    (*) Bug fixed whereby accesses of entries from very long lists, when performed
    repeatedly, could become unacceptably slow.

    (*) Bug fixed whereby sorting a list of objects using "sort L in P order",
    where P is a property whose value is an indexed text, would produce
    incorrect results.

    (*) Bug fixed whereby sorting a list of indexed text initialised from a list
    of literal texts would produce incorrect answers. (Actually it was the list
    which was incorrect, but in a way which only affected sorting.)

    (*) Bug fixed whereby peculiar messages about being unable to cast or copy block
    values would sometimes appear when passing a list of K to a phrase which
    expects its token to have kind "list of objects", but where K is something
    more specific; for example, passing a list of rooms where a list of objects
    was expected.

    (*) Two bugs fixed whereby Inform would be picky about whether or not the contents
    of, say, a constant list of things were valid, in cases where the entries
    were not obviously things but would be proved to be by the end of compilation;
    this affected initial values of properties and of global variables. For
    example, the following threw a spurious problem message in earlier builds:

    	The Place is a room. Hall is south of the Place.
    	The destination wishlist is a list of rooms that varies.
    	The destination wishlist is { the Place, the Hall }.

    The problem here was that the Hall wasn't known to be a room at the time when
    the constant list was read; this has now been resolved.

    19.12. Tables

    (*) The maximum number of columns per table has been raised from 20 to 99.
    (There are run-time implementation reasons why a maximum has to exist, but
    99 ought to be enough.)

    (*) Bug fixed whereby table entries containing literal values would sometimes be
    confused with names of objects, if they could also be read as part of an
    object's name: for example, if an object called False Door existed, then the
    table entry "false" might be misread as this object rather than as the
    truth state for falsity.

    (*) Bug fixed whereby tables used to define things or values could not have
    a column which contained stored actions, e.g., like so:

    	A task is a kind of value. Some tasks are defined by the Table of
    	Unfinished Tasks.

    	Table of Unfinished Tasks
    	task				relevant action
    	boulder-touching	touching the large boulder
    	boulder-recovering	taking the large boulder

    (*) Bug fixed whereby, on Glulx only and then only sometimes, looking up a
    value corresponding to another value would produce spurious "programming
    errors" on screen in cases where the column looked at included blank entries.

    (*) Bug fixed whereby attempts to use "an X listed in table T", in the context
    of a value, would wrongly be allowed even where this doesn't identify which
    value is meant.

    (*) Bug fixed whereby the "number of rows in T" would produce a more or less
    random answer if T were the empty table used as a default value of the
    "table name" kind; and this could cause "number of filled rows in T" to
    hang, in unlucky cases.

    (*) Bug fixed whereby increasing or decreasing a table entry by a given amount
    in fact set it to that amount (but only in cases where the entry was looked
    up with "corresponding to").

    (*) Bug fixed whereby various sorting tricks with tables would fail if the
    column sorted on contained indexed text. Inform now requires such tables
    to be sorted before being iterated through using "repeat through T in
    C order", where C is a column holding indexed text, and issues a helpful
    run-time problem message explaining what to do; previously it simply gave
    incorrect results.

    (*) Bug fixed whereby sorting tables in random order would be slow if they
    contained large numbers of blank rows.

    (*) Bug fixed whereby sorting a table on a column which contained some blank
    entries (other than as part of blank rows) would move these to the top,
    rather than to the bottom, of the table.

    (*) Problem message added for attempts to look up a value corresponding to a
    key in a table when the kind of the column concerned makes that impossible,
    e.g., for "the price corresponding to a shopkeeper of 4 in Table 1" where
    the shopkeeper column doesn't contain numbers, so that 4 can't possibly be
    there.

    19.13. Scenes

    (*) Bug fixed whereby scene endings predicated on the player's command would
    sometimes fail on the initial pre-turn, before anything had been typed, e.g.:

    	Act I ends when the player's command includes "bug/bugs".

    (*) Problem message added to catch mistakes like this:

    	Happiness is a kind of value. Disappointment is a scene.
    	Disappointment begins when happiness ends.

    19.14. Kinds and typechecking

    (*) Bug fixed whereby defining more than 50 new kinds could sometimes cause
    Inform 6 errors or other aberrant behaviour, in a not-very-repeatable way.

    (*) Bug fixed whereby nested bracketed compound phrases failed to be read
    properly. It's often poor prose style to write messy phrases full of brackets
    to disambiguate them, but it ought to work, and it seems that this long-standing
    bug made Inform a little unpredictable here.

    (*) Bug fixed whereby spurious problem messages would sometimes be produced
    when matching adjective-qualified descriptions in the tokens for a phrase;
    for instance, in matching "analyse X" against

    	To analyse (N - even number): ...

    ...in cases where X is clearly a number, but may or may not be even.

    (*) Bug fixed whereby temporary variables made with "let" or "repeat" whose names
    clashed with valid descriptions would be disallowed. This doesn't sound
    problematic, but actually it was: for example, if you write

    	let held item be ...

    in an extension, say, you don't want this to work most of the time, but then
    to fail when somebody uses the extension with a story including an object
    called "item" (because then "held item" is a valid description - it means
    the item when in a state of being held).

    (*) Bug fixed whereby "some" used as an indefinite article inside a condition
    might be confused with "some" as a determiner, e.g., in the "now" here:

    	Some tea is in the kitchen.
    	When play begins: now the player has some tea.

    (*) Bug fixed whereby spurious kind mismatch problems would be produced when
    named objects were used as cases, where a particular kind was needed. For
    instance,

    	To decide if (D - a direction) looks to windward:
    		if D is:
    			-- northeast:
    				decide no;

    (*) Bug fixed whereby an attempt to really violate dimensional rules about the
    way numerical values combine could, in some circumstances, throw an internal
    error; for example, using the Metric Units extension to set up standard SI
    units, but then adding "A force times a mass specifies a force.", thus making
    mass dimensionless. (Newton's Laws become not just invalid but inexpressible
    in such a universe... but that's no reason for Inform to fold up its tent.)

    (*) Problem message added (in place of run-time problem) when a variable is
    created with kind "list of topics", or other such constructions. (Variables
    of kind "topic" are forbidden; it was an oversight that these more complex
    variations weren't rejected at compile-time in earlier builds. They were let
    through, but didn't work at run-time.)

    19.15. Phrases and functional programming

    (*) Perhaps this was a bug fix, perhaps a small new feature, but it likely won't
    be controversial: local variable names (created by "let", and such) now take
    precedence over global names of physical objects even in descriptions of
    essentially physical situations. For example, in the fragment

    	To sweep (staircase - a supporter):
    		let the debris be a random thing that is supported on the staircase;

    ...Inform now reads "staircase" as the supporter appearing as a token in the
    expansion of "sweep", even if there is an object in the world called "the
    staircase".

    (*) Bug fixed whereby implicit attempts to repeat through a domain which can't
    be iterated through would produce incorrect results at run-time. What now
    happens is that a run-time problem message is generated. For example,
    "let L be the list of texts" can't be done because the possible texts
    can't be iterated through. (In general not all descriptions are used for
    iteration, which is why this isn't caught with a problem message in the
    compiler.)

    (*) Bug fixed whereby a small number of obviously true conditions would produce
    Inform 6 errors in compilation: for example,

    	if 1 is a number, say "Hi."

    would fail. (What happens here is that Inform simplifies the proposition
    until it becomes universal truth, then compiles that to an empty string of
    Inform 6 code; which is correct for doing nothing, but not for testing nothing,
    since it isn't a valid I6 condition. It now tests universal truth as "if (true)".)

    (*) Bug fixed whereby spurious problem messages, apparently though not actually
    the result of memory being corrupted, would sometimes appear if there were
    large numbers of very memory-costly definitions such as this one:

    	To dribble/drabble an/-- image-map in (WIN - a number) at (X1 - a
    		number) by/x (Y1 - a number) using (WDT - a number) wide data
    		of/from/-- from (IMG_MAP - a list of figure names) with tile-width
    		(W - a number) by/x tile-height (H - a number) pixel/pixels/px/--:
    		do nothing.

    (It's quite expensive on memory to write definitions like this: it has nearly
    200 possible wordings.)

    (*) Bug fixed whereby using "whether or not..." in a "now" would sometimes
    cause a spurious internal error: e.g., setting a truth state variable "T" with

    	now T is whether or not location is Stage.

    (*) Bug fixed whereby the "Runtime problems" pages displayed in the user interface
    have title numbers which are out by one. Thus the explanation page for
    "P17 - Can't divide by zero" was headed "P18 - Can't divide by zero"; which
    was needlessly confusing, though it did no harm otherwise.

    (*) Bug fixed whereby definitions of phrases given as inline I6 code would not
    properly cast word values to pointer values where necessary. For example...

    	To announce (event - indexed text):
    		(- print "I declare ", (INDEXED_TEXT_TY_Say) {event}, ".^"; -).
    	When play begins, announce "Saturnalia".

    ...would not work because "Saturnalia" would be expanded into {event} as
    text rather than indexed text. This looks like an obscure bug, but in fact
    caused some phrase definitions in the Standard Rules to go wrong, e.g.,

    	let L be a list of indexed text;
    	let L be {"oranges", "apples", "bananas"};
    	add "pears" to L;

    would create L having three indexed texts and then one unindexed one, because
    the inline definition of "add ... to ..." was failing.

    (*) Problem message added (in place of internal error) when a declaration
    contains only variables, e.g., "To (N - a number): ...".

    (*) Problem message added (in place of internal error) for a malformed inline
    Inform 6 phrase definition with redundant text after the "-)" marker.

    (*) The (+ ... +) syntax for embedding I7 source text within I6 code was previously
    not allowed in I6 inline definitions of phrases, which was an odd anomaly,
    because it was allowed in other I6 inclusions. It's allowed now.

    (*) Bug fixed whereby the literal Inform 6-to-7 escape "(+ V +)", where V is a
    value stored on the heap, produced an attempt to block-copy an independent
    instance of V, rather than producing a pointer to the existing instance;
    this, in particular, making it difficult to use the notation for global
    variables holding indexed text, and the like.

    (*) Bug fixed whereby the literal Inform 6-to-7 escape "(+ A +)", where A is an
    adjective, would produce I6 code which failed to compile, rather than the
    name of the routine to test the adjective. Since Inform 6 is typeless,
    there's no good way to choose which sense of the adjective is meant, if
    several exist for different kinds of value (as for instance with the
    adjective "empty"). The convention is: the meaning for objects, if there
    is one; and otherwise the first-declared meaning.

    19.16. Equations, units and arithmetic

    (*) Bug fixed whereby printing units scaled by factors which aren't powers of 10
    tended to produce somewhat wildly approximate results - for example, that
    printing the value "90 min" in the unit "hours" would produce "1.36 hr".
    Integer arithmetic makes this necessarily only an approximation, but the
    new algorithm is better; for example, 90 seconds is rendered as 0.0010418
    days, the true figure being 0.0010416666...

    (*) Bug fixed whereby numerical parts of literals which were both optional and
    had optional preamble would sometimes match if the preamble was there but
    the number wasn't, and would sometimes not respect the optionality: for example,

    	A die roll is a kind of value. 3d20+9 specifies a die roll with
    	parts dice, sides (without leading zeros), adds (without leading zeros,
    	optional, preamble optional).

    ...would allow "2D6+2" and "2D6+" but not "2D6" in typed commands; it now
    allows "2D6+2" and "2D6" but not "2D6+".

    (*) Bug fixed whereby units given in singular and plural forms would sometimes
    have only the singular form used in saying, e.g.,

    	An age is a kind of value. 1 year old (singular) or 2 years old (plural)
    	specifies an age. Every person has an age. Suzie is a woman. Suzie is
    	8 years old.

    would result in "[the age of Suzie]" being "8 year old", not "8 years old".

    (*) Problem message added (in place of internal error) when attempting to solve
    an equation which is given as the result of some further calculation, rather
    than being explicitly named.

    19.17. Understanding

    (*) Bug fixed whereby commands using numbers spelled out in digits as noun
    phrase determiners wouldn't always work: e.g., TAKE FIFTEEN PLANTS would
    be recognised, but not TAKE 15 PLANTS.

    (*) Bug fixed whereby the Understand token "[any ...]" would ignore any
    constraint made about visibility in the "..." part; for example, "[any
    person who is not visible]" would be read as "[any person]".

    (*) Bug fixed whereby the pronoun IT would sometimes wrongly be set during
    play to the identity of a backdrop item which, though present, was not
    explicitly mentioned; for instance, IT might be set to the sun in some
    outdoor room.

    (*) Bug fixed whereby understanding units which contained mixed case lettering
    in their notations didn't always work on the Z-machine; for instance,

    	100kHz specifies a frequency.

    would lead to commands like "tune to 79kHz" not being recognised.

    (*) Bug fixed whereby an empty player's command (resulting from the player simply
    pressing enter instead of typing), which then produces an empty snippet, would
    result in run-time problem messages if this were matched against. That made
    it difficult to write rules like:

    	Rule for printing a parser error when the player's command includes
    	"please": ...

    (*) Problem message added (in place of internal error) when a circularity is
    asked for by using "[something related by equality]", e.g.:

    	Understand "[something related by equality]" as a person.

    19.18. Glulx issues, file I/O, figures, sounds

    (*) Bug fixed whereby handling of external files with the Glulx setting would
    tend not to work after a game had been saved and then restored. (Particular
    thanks to Erik Temple and Andrew Plotkin for helping with this.)

    (*) Formatting improved on the Problems page for the case of running out of
    readable memory in the Z-machine. In 5Z71 the message for this was, due to
    a text editor accident, full of words run together without spaces; which
    "creates the alarming impression of a nervous breakdown" (Eric Eve).

    19.19. Spacing and printing

    (*) Bug fixed whereby a serial comma would wrongly be used when saying a list
    which contained exactly two items, if the "Use the serial comma." option
    is in force - thus "Starsky, and Hutch".

    (*) Bug fixed whereby printing numbers in excess of 1,000,000 "in words" would
    describe them in thousands; Inform now uses the words "million" and "billion"
    as necessary. (This only affects Glulx games, since the Z-machine can't hold
    numbers that high.)

    19.20. Indexing

    (*) Bug fixed whereby links to extension documentation inside the application
    would be broken if the extension's name or author included an apostrophe
    (as in the case of "Poor Man's Mistype by Aaron Reed").

    (*) Bug fixed whereby rules such as "Instead of doing something other than
    singing..." would appear in the Actions Index as if they affected singing but
    not other actions, the exact reverse of the truth.

    (*) Bug fixed whereby certain built-in adjectives would have their indexed
    Phrasebook definitions truncated by one word, though surprisingly often they
    still made sense that way.

    (*) Bug fixed whereby tool-tips displayed when the mouse arrow hovers above a
    map connection in the World index would show garbled names of rooms or
    directions when these included accented characters.

    19.21. Testing commands

    (*) Bug fixed whereby the "Use predictable randomisation." option caused I6
    errors in build 5Z71; it works again now.

    (*) The trace file has been abolished; in trace mode, Inform copies the same
    information to the debugging log instead. (Only affects Inform maintainers.)

    19.22. Releasing, bibliographic data, and cBlorb

    (*) Bug fixed whereby, similarly, pasted code from extension documentation
    examples would come out with accented characters garbled in the paste process.
    Sorry about this: it was particularly bad for examples like "Cursillo Mini
    Juego", supplied with the documentation for Sebastian Arg's Spanish extension.

    (*) Bug fixed whereby releasing with a website would sometimes produce web pages
    with the wrong character encoding; typically with UTF-8 for the source text,
    but with ISO Latin-1 headings.

    (*) Bug fixed whereby releasing with template websites was not working unless
    the template was placed inside the application, which users should never
    have to do.

    (*) Problem message added (in place of Inform 6 errors) to catch attempts to
    change the bibliographic data for a story during play. A shame, this; it
    would be coolly interactive to be able to change the story's title and
    author halfway through, but it would make the Library Card, the IFDB entry,
    and so on, wrong.

    (*) Problem message added (in place of internal error) when the title, author,
    or other bibliographic data for a project contains a text substitution -
    again, these have to be fixed text.

    (*) Problem message added for attempts to release along with an existing story
    file when in Glulx mode: Inform supports this for Z-machine story files, but
    not Glulx, at present. (There are so few Glulx story files not generated by
    I7 that it's never seemed worth it, but get in touch if you do need this.)

    20. EXAMPLES

    "Entrevaux" added to demonstrate a system of scenes where each scene has a
    	list of props, a location, and some starting text, and scenes are set up
    	and struck automatically.
    "Wainwright Acts" added to demonstrate a quirk of using doors with NPCs.
    "Number Study" added to demonstrate conditional relations between numbers.
    "For Demonstration Purposes" added to show the use of relations applying to
    	stored action names.
    "The Undertomb 2" added to demonstrate properties of values.
    "Finality" added to demonstrate how to strip out the offer of UNDO.
    "Pot of Petunias" added to demonstrate "set pronouns from..." and point to
    	the more abstruse methods available in Plurality, if the author needs them.
    "Unblinking" added to demonstrate the use of best route through...
    	described rooms, and to explain a tricky point about determining light
    	levels in a room.
    "Lethal Concentration 2" edited to produce more attractive grids.
    "Bic" modified to reflect the new behavior of description properties.
    "Kiwi" revised to be more accurate about when it prints its parser error.
    "Waterworld" extended to show how to add new accessibility rules. (The old
    	version of this example was simple but not the most trustworthy
    	implementation.)
    "Stately Gardens" revised to handle "look towards [something]" better, and
    	to print a response to looking towards a room that contains nothing notable.
    "Paddington", "Sushi" and "Crusoe" slightly rewritten to account for changes
    	to the carry out examining rulebook (see above).
    "Ferragamo Again": removed bug whereby it was possible to get "You sighs
    	heavily." as output.
    "Bowler Hats and Baby Geese": removed bug that caused the eggs still to be
    	visible after they were made into the omelet.
    "Pine 4": removed bug that made the brothers invisible because they were
    	not starting in the Woodcutter's Shack.
    "Strictly Ballroom": removed bug that made it possible for one of the other
    	characters to dance with "yourself".
    "Entrapment": made a very slight tweak to syntax to clarify what is
    	happening at one point for the reader.
    "Tilt 3": removed a comment that pasted incorrectly into the main window,
    	causing compilation to fail when compiling for Glulx.
    "The Cow Exonerated": removed a bug such that the game text always assumed
    	you'd been burning multiple matches.
    "Further Reasons All Poets Are Liars": added tweaks to prevent moving the
    	box while standing on the bed, and to give a more sensible response to PUSH
    	BOX alone (formerly this gave "It is fixed in place.", which was clearly
    	wrong).
    "Hayes Code": revised to add an indefinite article ("a thong", "a
    	pin-striped suit") rather than the inexplicably bare version given before.
    	Also, it should have been "Hays Code" all along. Oops.
    "Under Contract": revised to include a test for the situation in which the
    	player tries giving her dress to Clark. This actually tests an improvement
    	to the Standard Rules.
    "The Cactus Will Outlive Us All": tweaked to replace the somewhat
    	disappointing message "Nothing obvious happens" after we pull the cactus to
    	kill Luckless Luke.
    "AARP-Gnosis": bug fixed whereby taking all but one of the volumes from the
    	encyclopedia would produce a delay of one turn before proper collection
    	descriptions kicked in.
    "Cloves": modified to automatically list the adverbs that the game knows
    	rather than hard-coding the list, now that this is possible.
    "Bumping Into Walls" very slightly revised because the previous phrasing
    	would create output like "From here, the only way out is to the down"
    	if vertical directions were included.
    "Whence?" and "Whither?" simplified considerably thanks to the use of
    	built-in phrases about door directions.
    "Boston Cream", "Text Foosball", "Patient Zero", "Nickel and Dimed", "Four
    	Stars" tweaked to include the "end the story finally saying..." phrase to
    	mark successful endings apart from unsuccessful ones.
    "Patient Zero" edited to excise an unused phrase definition.
    "The Facts Were These" edited to deal more gracefully with the problem of
    	giving items that are on the ground, if no other items not on the ground match.
    "Cave-Troll", "Kiwi", and "WXPQ" edited to handle new treatment of parser errors.

    Recipe Book:

    Modifications to "Ending the Game" (now called "Ending the Story") to
    reflect new syntax and to explain the Table of Final Question Options more
    fully.

    21. BUILT-IN EXTENSIONS

    The definition of kHz in "Metric Units" was wrong: it thought 1 kHz was a
    	thousandth of a Hz, not a thousand Hz.
    "Locksmith" advanced to version 9:
    	Additional rules so that the player can learn the function of a passkey
    		by using it to lock or observing it being used to lock. (Formerly only
    		unlocking identified the passkey.)
    	Name given to one rule for which a name had been omitted. (Sorry about that.)
    Tweak to "Basic Screen Effects" to get rid of a bug to do with the styles of
    	status text in Glulx when an extended status bar was employed (thanks to
    	Erik Temple for the patch). Version advanced to 6.
    "Plurality" advanced to version 8:
    	A couple of minor bugs expunged.
    	Extension documentation improved to show how to check the plural status of
    	objects.
    	Adjusted to use the phrase "set pronouns from...".
    	Deprecates phrases using "Cap ...", as in "Cap it-they", instead allowing
    	the author to capitalize normally for the same effect ("It-they").
    	Adds a contracted 's-'re form in addition to is-are, and extends the example
    	in the documentation.
    "Glulx Text Effects": minor changes to the documentation to clear up some
    	confusion in the discussion of colors as rendered in hex; and revised to
    	allow the user to modify the built-in styles. Version number advanced to 4.
    "Glulx Entry Points" given a new example and better explanation of what the
    	gestalt checks about multimedia ability will actually do. Version number
    	increased to 8.

    22. A NOTE ABOUT FIGURE AND SOUND NAMES

    Figure names and sound names are the standard Inform kinds for representing
    pictures and sound effects. In this build they gain in functionality (they
    can have properties now, can be repeated through, and so on), but to achieve
    this we needed to change their data representation at the Inform 6 level.

    This only affects I6 code included into I7 source text, but the practical
    side-effects run wider, because many people use Glulx extensions for doing
    ingenious things with (especially) images; and those extensions tend to rely
    on the old representation.

    This means they will need to be updated in order to work with this new build
    of Inform.

    Previously, a figure name and a sound name were each represented in I6 by
    the resource ID number of the picture or sound resource inside the blorbed
    story file. These would usually be small numbers, and would be different from
    each other (i.e. no picture would have the same ID number as a sound).

    From this build, figure name and sound name are enumerated kinds, meaning
    that they are each independently stored as the I6 level as 1, 2, 3, ... in
    order of creation. These are typically off by one, or some other small amount,
    from resource ID numbers, but don't rely on that. To convert to a resource
    ID number, indirect through the word arrays:

    	ResourceIDsOfFigures-->N
    	ResourceIDsOfSounds-->N

    In other words, whereas in an I6 inclusion

    	(+ figure of Space Shuttle +)

    would previously have produced the resource ID number as an I6 value, you
    now need to say

    	ResourceIDsOfFigures-->((+ figure of Space Shuttle +))

    and similarly for sounds. We apologise for the inconvenience of changing
    this, but from the long-term point of view, it's the right thing to do.

    23. A NOTE ABOUT EXTERNAL FILES

    Prior to March of 2010, the Glk reference materials and interpreters
    incorrectly specified the underlying code for appending text to
    external files. This means that, on most interpreters, external file
    handling did not work correctly. The major interpreters, including
    WinGlulxe, WinGit, and Gargoyle, were patched in mid-March. (Zoom was
    not affected.) Authors should be aware of this when testing and
    recommending or packaging interpreters for games that utilize external
    files.

Previous | Contents | Next