Change Log for the Next Build

Today is Inform’s 17th birthday. It’s traditional for big new releases of
Inform to come out on its birthday (Inform 6 came out on its 3rd birthday,
Inform 7 on its 13th). Sometimes we’re a little early, as in 2009, and
sometimes a little late. This year we’re running late: a candidate build is
with a group of testers, but it will take another couple of weeks to finish
testing and deal with the issues found. We promised to post the change log
today, though, and here it is. (The long, long itemised list of bug fixes
has been removed, to keep this document to a reasonable size.)

Graham Nelson
28 April 2010

6E35/36 (test builds for April 2010 release of Inform)

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

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.

3. INFORM FOR GNOME ON LINUX

(to follow)

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

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.

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

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.

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

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

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.

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

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.

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

(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 two new ones, going action number 27 and 28.)