[I7] Inform 7 build 6E36 change log

13 views
Skip to first unread message

vaporware

unread,
Apr 29, 2010, 3:05:04 AM4/29/10
to
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 "<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.)


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

John Dillard

unread,
Apr 29, 2010, 4:57:57 AM4/29/10
to
On Apr 29, 2:05 am, vaporware <jmcg...@gmail.com> wrote:

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

All the new stuff sounds good. But I don't understand how a planned
release of "on or around" the 28th was even considered remotely
possible if now you're saying "it will take another couple of weeks"
for testing. This is the problem with "Big Development" that tries to
cram in a lot of features rather than focus on a more iterative style
of development that focuses on testing along the way, with a
regression cycle near the end.

Why not release a general beta so that everyone can see the product
beyond this select group of testers? Inform is supposedly "perpetually
in beta" anyway for the time being, so what does it matter? Just make
a note to those that what they are using is a "beta build" and they
may encounter problems with it.

S. John Ross

unread,
Apr 29, 2010, 5:34:38 AM4/29/10
to
Sounds groovy; looking forward to it :)

Peter Pears

unread,
Apr 29, 2010, 5:56:29 AM4/29/10
to

Amazing amount of work. Well done to all involved! And it's, as
always, a reminder that Inform 7 is still very much in beta, in
development, not a finished product.

Peter Pears

unread,
Apr 29, 2010, 5:58:44 AM4/29/10
to
Ok, my previous post got screwed up. So again:

Amazing work, congratulations to all involved. And lists like these
are always a reminder that Inform 7 is not, and doesn't claim to be, a
finished product yet. That puts things in perspective, I daresay.

James Jolley

unread,
Apr 29, 2010, 6:27:22 AM4/29/10
to

Your guess is as good as mine. It's Nelson, ego trip 101 folks.

Peter Pears

unread,
Apr 29, 2010, 6:50:48 AM4/29/10
to

I'm not *in* on the development process, and have no insight on any of
it. I also have zero experience. But my common sense, and lots of
observation, prompt me to answer what I *think* would happen in your
scenario.

Consider that every time a new build comes out the crew has an
obligation to its users. It must be as stable as possible, for one.
For other, it must change as little as possible - especially if it is
to go down a more iterative style, as you say. It would annoy people
to no end, and crash lots of projects, if every time a release was
made there were small things to be changed. And then again next time.
And then AGAIN next time. It would also make it really hard to make
the big changes.

I7 is still in the "big changes" department, really. To make the whole
process more open would slow it down indefinitely, with long
discussions of how best to tackle each issue. Such discussions are
good in theory, but in my experience they lead nowhere, because
there's always a hugely vocal minority on any topic, drowning out all
conversation - whether the monirity is *for* or *against* the change.
And when both parties are in the right, what is the crew to do?

Also, the fact that they are trying to make it as stable as possible
in each new build is an amazing thing of itself. If they just labeled
it "beta, watch your steps", I'm sure I7 wouldn't have as many
supporters as it did. Your proposed method elliminates, or at least
violently shakes, this stability.

In the end, we have a bit of a dictatorship, yes. But in development,
democracy is overrated. Dictatorships get things done. It all depends
whether you trust, or you don't the person/people at the helm. Graham
and the rest of the crew have proved to be efficient, hard-working,
always concerned about existing projects and future possibilites both.
So what if they prefer to work in a more closed space. It guarantees
quality.

This keeps coming up: "if you don't like it, switch to another
program". It's not a throw-off. It's not an insult. It is honest
advice. If one really dislikes the way a certain tool is being
developed, one should stop using it. If everyone does that, eventually
the developers will realize their work-method is wrong. Of course, if
only *you* quit and no-one else does, maybe the development is not as
flawed as you'd thought. It's a win-win situation - either one sides
realizes their mistake, or the other one does. And this with zero
unpleasantness.

Again - in my experience, democracy is a godsend in many things. Not
in cooking. Not in arts. Not in programming. People think way too
differently. It's best to stick to what one wants to achieve, and at a
certain point - in I7, the point is when the build gets released -
bring in the crowd, see how they react, and learn from their reactions.

John Dillard

unread,
Apr 29, 2010, 7:55:26 AM4/29/10
to
On Apr 29, 5:50 am, Peter Pears <peter_pe...@hotmail.com> wrote:

> Consider that every time a new build comes out the crew has an
> obligation to its users. It must be as stable as possible, for one.
> For other, it must change as little as possible - especially if it is
> to go down a more iterative style, as you say. It would annoy people
> to no end, and crash lots of projects, if every time a release was
> made there were small things to be changed. And then again next time.
> And then AGAIN next time. It would also make it really hard to make
> the big changes.

Numerous other development projects out there -- including free ones
-- argue against this. But, I agree, what you say *could* happen. Lots
of things could happen. But if you have two builds: a release build
and a candidate (or beta) build. Then you have no problem. You can
simply make it clear to people which one they are using.

Smaller features give you a better chance to get iterative development
in place and get feedback on those features. It cuts down testing
time, including regression. It allows you to make more fine-grained
course-corrections as well as to keep bigger features on the back-
burner for a longer time, allowing for better integration of features
as you see how smaller elements are embraced or rejected by the user
base.


> Also, the fact that they are trying to make it as stable as possible
> in each new build is an amazing thing of itself.

Not really. That's pretty much expected. You don't try to make things
more *unstable* in each new build, do you? Product maturity is not
amazing. It's what you work for. I don't know why making things more
stable would be seen as an "amazing" thing.


> it "beta, watch your steps", I'm sure I7 wouldn't have as many
> supporters as it did.

I highly doubt that and I don't know upon what evidence you're basing
that.


> Your proposed method elliminates, or at least
> violently shakes, this stability.

Again, I don't see the evidence of this and I'm basing this on
numerous development projects that exist all over the web. I'll grant
you that what you're saying *can* happen. But it can happen even on
big projects that are more closed as well. I'd be curious what
development projects you've been actively involved in where you not
only saw this but where you could draw the direct correlations.


> This keeps coming up: "if you don't like it, switch to another
> program". It's not a throw-off. It's not an insult. It is honest
> advice.

No doubt. I'm probably going to be looking at TADS 3 for now.


> If one really dislikes the way a certain tool is being
> developed, one should stop using it.

Well, there's also the silly notion of maybe introducing change by
suggesting different development styles as well. That doesn't mean
they have to be accepted, but your binary "don't use it or use it and
like it" is a bit simplistic. On the other hand, I agree: if it's
clear a given development team does things their way and that's pretty
much it, well, then, yeah, you might just want to consider not using
that tool. I'm pretty much at that point. I also realize that a lot of
other people aren't or don't even care about the development side of
it, which is also fine.

Peter Pears

unread,
Apr 29, 2010, 8:10:09 AM4/29/10
to
On Apr 29, 12:55 pm, John Dillard <j.dilla...@yahoo.com> wrote:
> On Apr 29, 5:50 am, Peter Pears <peter_pe...@hotmail.com> wrote:
>
> > Consider that every time a new build comes out the crew has an
> > obligation to its users. It must be as stable as possible, for one.
> > For other, it must change as little as possible - especially if it is
> > to go down a more iterative style, as you say. It would annoy people
> > to no end, and crash lots of projects, if every time a release was
> > made there were small things to be changed. And then again next time.
> > And then AGAIN next time. It would also make it really hard to make
> > the big changes.
>
> Numerous other development projects out there -- including free ones
> -- argue against this. But, I agree, what you say *could* happen. Lots
> of things could happen. But if you have two builds: a release build
> and a candidate (or beta) build. Then you have no problem. You can
> simply make it clear to people which one they are using.
>
> Smaller features give you a better chance to get iterative development
> in place and get feedback on those features. It cuts down testing
> time, including regression. It allows you to make more fine-grained
> course-corrections as well as to keep bigger features on the back-
> burner for a longer time, allowing for better integration of features
> as you see how smaller elements are embraced or rejected by the user
> base.

Ah, you seem to know more about it than I do - I was simply guessing,
really, imagining what would happen. Time for me to quietly withdraw
from this side of the conversation. :)

> > Also, the fact that they are trying to make it as stable as possible
> > in each new build is an amazing thing of itself.
>
> Not really. That's pretty much expected. You don't try to make things
> more *unstable* in each new build, do you? Product maturity is not
> amazing. It's what you work for. I don't know why making things more
> stable would be seen as an "amazing" thing.

Because it's much too easy not to care about stability and/or backward
compatibility when you have new things in, especially when no-one
expects it to be "finished". There's a lot of changes with each build.
Now, because this is still a WIP, they could go "Beta, watch out, it's
probably a bit unstable but it can do a lot of new cool things".
Instead they go "Ok, it's a beta, but it's as near as great as we
could make it this time. Go wild and tell us what breaks".


> > it "beta, watch your steps", I'm sure I7 wouldn't have as many
> > supporters as it did.
>
> I highly doubt that and I don't know upon what evidence you're basing
> that.

I'm basing it, frankly, on my own experience with unstable projects,
and what I've seen of their users. Also note I mean "beta, watch your
step because we're still patching things up and the last changes may
have brought about problems we haven't found yet" (as opposed to the
current "beta, but go ahead, it's stable enough, enjoy"), which seems
to me to be inevitable in the more iterate process you describe. But
again, I have no real experience in the matter and you seem better
informed.

> > This keeps coming up: "if you don't like it, switch to another
> > program". It's not a throw-off. It's not an insult. It is honest
> > advice.
>
> No doubt. I'm probably going to be looking at TADS 3 for now.

Enjoy. :) It's a great language.

> > If one really dislikes the way a certain tool is being
> > developed, one should stop using it.
>
> Well, there's also the silly notion of maybe introducing change by
> suggesting different development styles as well.

Sure, when its done reasonably. Lately all discussion regarding the
development of I7 has been all but reasonable - you're one of the few
people to post reasonably and coherently *against* it for a long time.
Which is why I'm taking the time to reply to you to the best of my
(granted, limited) abilities. I'm just an IF fan, anyway. :)

That doesn't mean
> they have to be accepted, but your binary "don't use it or use it and
> like it" is a bit simplistic.

Well, it comes to that binary because it's gone completely out of
hand, with people being insulting and unreasonably demanding and
impatient. There comes a point where patience snaps and we just go "Oh
just go elsewhere if you don't like it".

> On the other hand, I agree: if it's
> clear a given development team does things their way and that's pretty
> much it, well, then, yeah, you might just want to consider not using
> that tool. I'm pretty much at that point. I also realize that a lot of
> other people aren't or don't even care about the development side of
> it, which is also fine.

Well good for you. :) I'm of the latter sort - I don't care about the
development as long as things get done, and get done in a way I like.
And that's been happening.

Also, you may not know this, because it hasn't been brought up all
that much lately, but it's been brought up enough times - I7
development is not as closed as it seems. If you (and by you I mean
anyone) want to be a part of the development system, it's as easy as
sending e-mails. There's plenty of things to do, from what I hear, on
many fronts.

James Jolley

unread,
Apr 29, 2010, 8:36:40 AM4/29/10
to

That's fair game. It's true what's being said though.


>
>>> Also, the fact that they are trying to make it as stable as possible
>>> in each new build is an amazing thing of itself.
>>
>> Not really. That's pretty much expected. You don't try to make things
>> more *unstable* in each new build, do you? Product maturity is not
>> amazing. It's what you work for. I don't know why making things more
>> stable would be seen as an "amazing" thing.
>
> Because it's much too easy not to care about stability and/or backward
> compatibility when you have new things in, especially when no-one
> expects it to be "finished". There's a lot of changes with each build.
> Now, because this is still a WIP, they could go "Beta, watch out, it's
> probably a bit unstable but it can do a lot of new cool things".
> Instead they go "Ok, it's a beta, but it's as near as great as we
> could make it this time. Go wild and tell us what breaks".

I think this is a strange way of looking at it. When I used to develop
for the blind, I often had to do much automated type testing, but there
were testers as well to check for the less obvious ones. My software
used low-level hardware type stuff so was specific and I could only
test with those who had enough background to offer input.


>
>>> it "beta, watch your steps", I'm sure I7 wouldn't have as many
>>> supporters as it did.
>>
>> I highly doubt that and I don't know upon what evidence you're basing
>> that.
>
> I'm basing it, frankly, on my own experience with unstable projects,
> and what I've seen of their users. Also note I mean "beta, watch your
> step because we're still patching things up and the last changes may
> have brought about problems we haven't found yet" (as opposed to the
> current "beta, but go ahead, it's stable enough, enjoy"), which seems
> to me to be inevitable in the more iterate process you describe. But
> again, I have no real experience in the matter and you seem better
> informed.

It depends on the project. I've known some open projects be as you
describe, but to be honest, many of the hobbiest ones tend to really
care about how the users are interacting with the software.


>
>>> This keeps coming up: "if you don't like it, switch to another
>>> program". It's not a throw-off. It's not an insult. It is honest
>>> advice.
>>
>> No doubt. I'm probably going to be looking at TADS 3 for now.
>
> Enjoy. :) It's a great language.

If you have the time to learn it, it's fine. Inform for me is a lot
easier to grasp.


>
>>> If one really dislikes the way a certain tool is being
>>> developed, one should stop using it.
>>
>> Well, there's also the silly notion of maybe introducing change by
>> suggesting different development styles as well.
>
> Sure, when its done reasonably. Lately all discussion regarding the
> development of I7 has been all but reasonable - you're one of the few
> people to post reasonably and coherently *against* it for a long time.
> Which is why I'm taking the time to reply to you to the best of my
> (granted, limited) abilities.

Takes note of dig, has this to say. I don't see anything i've said here
as unreasonable. The fact that the inform team are running this circus,
and others are falling for the cheap tricks is totally beyond me. 2
weeks for a compiler update? It's meant to be an open beta, where do
you draw the line then? It's open when we say, but closed 90 per cent
of the time?

> I'm just an IF fan, anyway. :)

OOH, this just in, Peter's an IF fan, news at 11. We all are!


>
> That doesn't mean
>> they have to be accepted, but your binary "don't use it or use it and
>> like it" is a bit simplistic.
>
> Well, it comes to that binary because it's gone completely out of
> hand, with people being insulting and unreasonably demanding and
> impatient.

This is brought on by the lack of transparency though. The users are
treated like idiots, the developers make things up as they go along,
that's how it seems to me anyway.

> There comes a point where patience snaps and we just go "Oh
> just go elsewhere if you don't like it".

Yes, but there also comes a point where many other people are asking
the exact, same, questions. If we don't question things and people's
inputs aren't being respected, what's the point?

Take Iphone apps. Don't worry, there's a reason for this. I often will
write to devs of Iphone apps regarding accessibility issues right? If
they reply to me, we work on things. If they don't, I ditch the app,
simple as. It's about making your userbase feel like they are worth
something. What's interesting to me is that the iPhone devs who have
replied to me and worked on the accessibility side, far outnumber the
ones who don't.

Basically, everyone contributes something, even something as daft as an
unlabeled image not having alt text is something. It'll never bother
the sighted users, but it's relevant. These little things are not taken
into account at all.


>
>> On the other hand, I agree: if it's
>> clear a given development team does things their way and that's pretty
>> much it, well, then, yeah, you might just want to consider not using
>> that tool. I'm pretty much at that point. I also realize that a lot of
>> other people aren't or don't even care about the development side of
>> it, which is also fine.
>
> Well good for you. :) I'm of the latter sort - I don't care about the
> development as long as things get done, and get done in a way I like.
> And that's been happening.

Has it though? The language side has been perfectly worked with and
refined. I can't say much about anything else.


>
> Also, you may not know this, because it hasn't been brought up all
> that much lately, but it's been brought up enough times - I7
> development is not as closed as it seems. If you (and by you I mean
> anyone) want to be a part of the development system, it's as easy as
> sending e-mails. There's plenty of things to do, from what I hear, on
> many fronts.

Some of us aren't programmers. Some of us don't care about writing
software any longer. I did that when I was 16, wrote in assembly
language using a platform with such limited memory it's silly. I've
done the learning other languages bit. Inform to me is very easy to
learn, no braces, no issues with screen readers not reading tabs
properly - at least on the mac side.

Peter Pears

unread,
Apr 29, 2010, 8:44:43 AM4/29/10
to
>> I'm just an IF fan, anyway. :)
>
>OOH, this just in, Peter's an IF fan, news at 11. We all are!

My point, obviously, being that I'm *just* an IF fan, with no real
experience of programming or development, and only a keen interest in
watching how people behave (and, of course, playing IF), and
everything I say should be treated as such.

James Jolley

unread,
Apr 29, 2010, 8:50:52 AM4/29/10
to

Fuck, touchy. I was actually joking with you. What's it the joker says
in the dark night "Why so Serious!"

John Dillard

unread,
Apr 29, 2010, 9:05:15 AM4/29/10
to
On Apr 29, 7:10 am, Peter Pears <peter_pe...@hotmail.com> wrote:

> Also, you may not know this, because it hasn't been brought up all
> that much lately, but it's been brought up enough times - I7
> development is not as closed as it seems. If you (and by you I mean
> anyone) want to be a part of the development system, it's as easy as
> sending e-mails.

To who, though? This sounds fine to me -- but how do you know who to
send emails to? Is this information listed somewhere on the site? I do
see information about contacting Graham Nelson for some things. But
I'm also seeing "vaporware" posting a lot of stuff about what's going
on. So do I e-mail this person? I'm not so concerned about helping
with the development until I can see what the design methodology is,
what the version control system used is, how changes are incorporated,
what kind of build process occurs, etc. If I see that stuff and can
make an informed decision, then, yeah, maybe I could help.

A good example is the apparent pool of testers for the upcoming build
of Inform. Who do I send an e-mail to in order to be included in this
group?

Peter Pears

unread,
Apr 29, 2010, 9:06:27 AM4/29/10
to

If in doubt, why not any member of the development team? Surely
they'll redirect your e-mail if necessary, or say "Sorry, you need to
speak with So-and-So".

Mick

unread,
Apr 29, 2010, 9:13:06 AM4/29/10
to
On Apr 29, 8:50 am, James Jolley <jrjol...@me.com> wrote:

Your introspective capacity astounds me.

James Jolley

unread,
Apr 29, 2010, 9:13:47 AM4/29/10
to
On 2010-04-29 14:06:27 +0100, Peter Pears <peter...@hotmail.com> said:
>
> If in doubt, why not any member of the development team? Surely
> they'll redirect your e-mail if necessary, or say "Sorry, you need to
> speak with So-and-So".

Like Jesse you mean? Don't see him putting my name forward do you?
Personality aside, i'd be ideal and he knows it, surely.

James Jolley

unread,
Apr 29, 2010, 9:14:36 AM4/29/10
to

That's it, one of the best movies I ever did watch. Love it on blu-ray
for the sound especially.

John Dillard

unread,
Apr 29, 2010, 9:26:13 AM4/29/10
to
On Apr 29, 8:06 am, Peter Pears <peter_pe...@hotmail.com> wrote:

> If in doubt, why not any member of the development team? Surely
> they'll redirect your e-mail if necessary, or say "Sorry, you need to
> speak with So-and-So".

Who is the "development team"? I mostly hear that requests should go
to Graham Nelson. Keep in mind, I'm not as used to the crowd and names
here yet. I'm learning.

Peter Pears

unread,
Apr 29, 2010, 9:31:40 AM4/29/10
to

Well, Graham would be a possible contact, sure. :) You can also ask
vaporware, aka Jesse. David Kinder is working with the IDEs. I believe
Andrew Plotkin and Emily Short are also part of the team, but I never
bothered to make sure, really.

James Jolley

unread,
Apr 29, 2010, 9:34:00 AM4/29/10
to

In other words, swings and round-abouts. Send emails and hope you get
replies? What happened to a real submission process? Proper development
seeding? That sort of thing? This is 2010, not 1984, joke intentially
left to the awareness of the reader.

Peter Pears

unread,
Apr 29, 2010, 9:38:18 AM4/29/10
to
On Apr 29, 2:34 pm, James Jolley <jrjol...@me.com> wrote:

I agree that it would be nice if it were possible to make more direct
contact, but the team is so formed by now that, although outside help
is surely appreciated, it's no longer as important as it once was. So
I understand there's no need for a more formal submission process,
it's more like "Oh, you want to help? No problem, here's what still
needs doing", or "Thanks for the offer, but we've got it covered for
now."

Josh Lawrence

unread,
Apr 29, 2010, 9:40:09 AM4/29/10
to
Very exciting stuff - especially the new flexibility with relations
and kinds and the instant-publishing-with-a-Parchment-embedded-
webpage. These are going to be very interesting things to play with.

Josh

James Jolley

unread,
Apr 29, 2010, 9:42:36 AM4/29/10
to

I see this to a point, but again, notice, no blind people have even
bothered to have been asked? Yes, me specifically because I 1 have the
time and 2 have the skills to offer significant input.

Matt Weiner

unread,
Apr 29, 2010, 11:07:57 AM4/29/10
to
On Apr 29, 9:34 am, James Jolley <jrjol...@me.com> wrote:

James, have you ever actually sent an e-mail and seen whether
you got a reply? If not, isn't a bit premature to complain about
how they won't let you participate? Volunteering on raif doesn't
seem like a good way to get to participate -- when I'm applying
for a job (which this isn't) I send my application to the employer
rather than talking in public about my willingness to do the work
and waiting for them to ask me.

It seems as though you have something to contribute,
but you aren't exactly going about it in a constructive way.
(And honestly, at this point I wouldn't blame the devs if
they decided they didn't want to deal with you.)

Matt

James Jolley

unread,
Apr 29, 2010, 11:46:36 AM4/29/10
to

You've just answered your own question. Grahame doesn't reply half the
time anyway.

You can all think what you want anyway, you've all got me labeled as a
twat so there we go. Whatever.

Erik Max Francis

unread,
Apr 29, 2010, 4:16:33 PM4/29/10
to
James Jolley wrote:
> This is 2010, not 1984, joke intentially
> left to the awareness of the reader.

Not a very relevant or good one, I'm afraid.

--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
What a crime to waste [youth] on children.
-- George Bernard Shaw

James Jolley

unread,
Apr 29, 2010, 4:27:53 PM4/29/10
to
On 2010-04-29 21:16:33 +0100, Erik Max Francis <m...@alcyone.com> said:

> James Jolley wrote:
>> This is 2010, not 1984, joke intentially left to the awareness of the reader.
>
> Not a very relevant or good one, I'm afraid.

True though, Nelson is big brother and Jesse and his crew of fakers are
the thought police.

Matt Weiner

unread,
Apr 29, 2010, 5:12:44 PM4/29/10
to
On Apr 29, 11:46 am, James Jolley <jrjol...@me.com> wrote:

Really, this is not true. I've got you labeled as someone who
reflexively hurls insults whenever someone says something
in defense of the I7 developers. But it's not like I think you're
a bad person or anything -- it's just that I think you aren't
really being constructive here, and that your hostility isn't
even advancing your own goals. (Pun not intended.)

mw

James Jolley

unread,
Apr 29, 2010, 5:25:51 PM4/29/10
to

Fair enough, but the I7 developers don't do people any favours. I've
lost count of the number of people who question things with the same
results, shut up and like it. That's hardly a worthwhile response.

vaporware

unread,
Apr 29, 2010, 7:36:06 PM4/29/10
to

And you're Two Minutes Hate?

vw

James Jolley

unread,
Apr 29, 2010, 7:38:58 PM4/29/10
to

> Good, very good, but naturally wrong. If being a realist means not
> taking people at face value and letting the community spirit here be
> ruled by idiots then so be it. If that's hate, god knows what the
> opposite's like.

Adam Thornton

unread,
Apr 29, 2010, 8:23:08 PM4/29/10
to
In article <83ubqv...@mid.individual.net>,

James Jolley <jrjo...@me.com> wrote:
>Fair enough, but the I7 developers don't do people any favours. I've
>lost count of the number of people who question things with the same
>results, shut up and like it. That's hardly a worthwhile response.

You're free to shut up and dislike it if you prefer.

Adam


James Jolley

unread,
Apr 29, 2010, 8:25:09 PM4/29/10
to

Yeah, what's it you like to say to me, suck my balls. Difference is
you'd never get near them. Fucking arse bandit.

cunningjames

unread,
Apr 29, 2010, 10:49:23 PM4/29/10
to
On Apr 29, 8:25 pm, James Jolley <jrjol...@me.com> wrote:
> On 2010-04-30 01:23:08 +0100, a...@fileserver.fsf.net (Adam Thornton) said:
>
> > In article <83ubqvFs5...@mid.individual.net>,

> > James Jolley  <jrjol...@me.com> wrote:
> >> Fair enough, but the I7 developers don't do people any favours. I've
> >> lost count of the number of people who question things with the same
> >> results, shut up and like it. That's hardly a worthwhile response.
>
> > You're free to shut up and dislike it if you prefer.
>
> > Adam
>
> Yeah, what's it you like to say to me, suck my balls. Difference is
> you'd never get near them. Fucking arse bandit.

Could any man be so clever? Bravo, bravo! You wield a mastery of the
comedic form heretofore unknown---a wit with a bite exceeding 5000
pounds per square inch. What (when written by other men) would seem
like the puerile insults of an emotionally stunted 12 year old boy,
one who savors the use of fine new words like "twat", you make sound
like ... um ... Oscar Wilde.

Please, continue. You'll undoubtedly accomplish all of your goals
here. Er, I'm sure you have any, right?

Best,
James

Andrew Owen

unread,
Apr 30, 2010, 2:26:56 AM4/30/10
to
I'd like to know what the impact of the changes to Inform are. I've
been happily using a release from two years ago without feeling the
need to upgrade, but I'm thinking about upgrading this time.

Note to Google: please remove usenet from Google Groups so people will
be forced to go back to using proper newsreaders and will be able to
use kill-files.

On Apr 30, 1:25 am, James Jolley <jrjol...@me.com> wrote:
> Fucking arse bandit.

Homophobic slurs don't win arguments. Being in a minority group
doesn't give you the right to attack other minority groups.

James Jolley

unread,
Apr 30, 2010, 7:12:10 AM4/30/10
to

And you are? What did he say? Something I am meant to take notice of? Tosser.

cunningjames

unread,
Apr 30, 2010, 9:23:39 AM4/30/10
to

Delightful! First "arse bandit", now this; I cannot stop laughing; you
are far too clever to waste your talents here, James.

Best,
James

Andrew Plotkin

unread,
Apr 30, 2010, 9:32:22 AM4/30/10
to
Here, Andrew Owen <chev...@gmail.com> wrote:
> I'd like to know what the impact of the changes to Inform are. I've
> been happily using a release from two years ago without feeling the
> need to upgrade, but I'm thinking about upgrading this time.

In very short:

The changes this time are mostly better data-handling. You can now
program with kinds of relations, kinds of phrases, kinds of
activities, and even kinds of kinds. If you're not a programmer, this
probably doesn't change your life much. :)

You can do stuff with objects that used to work only on things and
rooms. (A thing is a kind of object; a room is also a kind of object.)

Auto-creating stuff (with declarations like "Every person has a nose")
now works in a more general way. You can auto-create values.

There are a small list of action changes. "Take all" now excludes
people and scenery by default. "get in" works for "enter"; "get down"
works for "get off". "look foo" works for "look at foo" (a sop to
newbie confusion, which I prefer handle differently, but never mind
that).

And finally, you can say "Release along with an interpreter" to write
out a Parchment web page.

-------------

Upgrading from the previous version of Inform will probably make
little difference to an existing project. The same was true of the
version two years ago (5U92).

However, this stuff does add up over time, and it's generally true
that re-testing a completed segment of an IF game is very hard. (The
skein is great, but can you really verify that every failure message
and disambiguation response that you got still works the same way?) My
policy is to not move a completed project from one Inform version to
another.

If you start a *new* project, I strongly recommend that you use the
latest version.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*