26.10. What was new in build 4U65 (27 April 2007)

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

| 26.10. What was new in build 4U65 (27 April 2007)

As this release was prepared, the US Supreme Court ruled that greenhouse gases were a pollutant; the Paris-Strasbourg TGV set a new world record railway speed of 357 mph, three-quarters the cruising speed of a Boeing 737; Charles Simonyi, author of Microsoft Word, became an astronaut; the genome of the macaque monkey was published; 80,000 people attended Wrestlemania 23 at Ford Field, Detroit; and Kryptonite, Superman's fictional mineral, was unearthed in a Serbian mine.

In the world of Inform, 4U65 saw a reform to the handling of actions, making it easier for actions to handle all actors equally, and the introduction of variables shared in common amongst rules which collaborate to perform a task between them. This allowed almost the entire world model of 70 built-in actions, previously hand-coded in Inform 6, to be moved into much more legible Inform 7 source text. 4U67, a Mac OS X variant, was identical except for user interface improvements.

See Rulebook variables for assigning variables to rulebooks: these are values created when the rulebook begins, which are held in common by all of the rules within that rulebook for as long as it is being worked through, and which disappear afterwards

See Activity variables for assigning variables to activities, which are similar but are held in common by all three rulebooks handling an activity: before, for and after

See Action variables for assigning variables to actions, which are similar but are held in common by all of the rulebooks handling an action

See Extensions in the Index for assigning a specification text to an action, used to make its Index entry more explanatory

See Actions for any actor for a new syntax, "an actor doing something", which can be used to check if any person - player or third party - is currently doing something

See Action variables for the ability to set up actions with optional matching clauses which look at action variables: for instance, tacking an optional "... onto something" clause onto the dropping action

202
| Example Croft Adding special reporting and handling for objects dropped when the player is on a supporter, and special entering rules for moving from one supporter to another. |
RB

    4U67 (7 May 2007)

    This build, for Mac OS X only, is identical to 4U65 except for the OS X user
    interface, in which the secondary controls in the various different panels
    have been harmonised into new-style bar icons. (In addition, new forward
    and back arrows provide the long-requested "browser-style history buttons".)
    We are releasing this now rather than waiting because it also fixes the
    minor but annoying bug to do with selecting detail pages in the Actions
    index (see the 4U65 release notes).

    4U65 (27 April 2007)

    This build once again fixes all bugs reported up to 22 April, but in fact
    few were found in 4S08; and it removes a hole in the type-checking system,
    to do with phrases to make decisions, but this will have affected few users.
    The main aim is an across-the-board reform of how actions are handled and
    implemented in Inform. Proposals (6.33), (6.35), (6.37) and (6.39) from the
    January 2007 consultation document are all carried through. It is now much
    easier to create actions which work equally for all actors, and which need
    a complicated interaction of rules to work.

    INFORM 7 FOR MAC OS X

    >--> A minor bug in the OS X application means that viewing the new details
    	pages for actions in the index will cause the application to think we
    	have switched to the Documentation panel, with the effect that the tabs
    	normally present for switching between index pages will disappear:
    	switching panel and going back to the Index will cure this. Apologies
    	for the inconvenience: the bug will be fixed in the next release.
    Fixed bug in 4S08 for OS X only which caused Inform to create spurious empty
    	Materials folders in cases where this was not really necessary (although
    	this did no harm, and could not damage any existing Materials folder).

    INFORM 7 FOR LINUX

    i7 now has the -r story-directory and -c story-directory command-line options.
    	These force it into non-interactive mode, where it compiles or releases
    	the story file and exits. They can be combined with -s (for settings)
    	and -p (for prefix of installed inform7 package); see the man page for
    	details. It is hoped that these options will be useful for IDE authors.

    INFORM 7 FOR WINDOWS

    Skein and Transcript improvements:
    A single click on a red badge in the skein is enough to go to the knot
    	in the transcript, rather than a double click as before.
    Any knot can be shown in the transcript by selecting "Show in
    	transcript" from the context menu or clicking on a red badge, not just
    	knots in the current thread.
    A knot selected in the above way is now indicated in the transcript by
    	having a thin blue border around it.
    The last played knot is now indicated in the transcript by having a
    	yellow border around it.
    The thick line in the skein now always shows the thread that is visible in
    	the transcript.
    The new menu item "Play All Blessed" plays through all threads that end in a
    	knot with an expected transcript.
    If the expected text in the transcript tab is double clicked on, the window
    	goes into edit mode, in which the expected text can be amended.
    When editing the expected text in the transcript tab, holding Ctrl+Enter
    	adds a carriage return to the expected text.

    RULEBOOKS

    Variables can now be given to rulebooks. For instance:
    		The every turn rulebook has a number called accumulated bonus.
    	creates a variable called "accumulated bonus", which holds a number.
    	Such variables are initialised to the default values for the relevant
    	kind when the rulebook starts, and are accessible only within rules
    	belonging to that rulebook (or which have historically belonged to it,
    	but been displaced by a "listed in... instead" sentence). Rulebook
    	variables have a namespace of their own: so their names can freely
    	clash with those of things, rooms, etc.) If the rulebook should
    	recursively start again within itself, each new run-through of the
    	rulebook has its own set of variables. In short, they behave exactly
    	like "let" values except that they last for a whole rulebook, not an
    	individual rule or To phrase. (This was (6.33) in the January document.)
    As we can now add a potentially unlimited number of new clauses to the
    	descriptions of actions to say whether or not rules apply (see below),
    	Inform must refine its method for sorting rules in order of how specific
    	they are. The rules on "going" are unchanged and we believe that no pair
    	of existing rules not using the new features will have their orderings
    	changed in any rulebook. Rules which do use new clauses are now subject
    	to a new sorting principle, "III.2.4 - Action/Where/Other Optional
    	Clauses". This follows the standard conventions.

    ACTIVITIES

    Variables can also now be given to activities. These are created just
    	before the "before" rules for the activity begin, and destroyed when
    	the "after" rules end (or when the activity is abandoned, though this
    	is a rare occurrence). They are visible to the rules for that activity,
    	and nowhere else, and again they have their own namespace; again, if
    	the activity should happen a second time within its first run, that
    	second occurrence gets its own copies of the variables. A simple
    	example of an activity variable:
    		Analysing something is an activity.
    		The analysing activity has a text called first impression.
    		Before analysing: now the first impression is "unremarkable".
    		Rule for analysing someone: now the first impression is "living tissue".
    		After analysing something (called the sample):
    			say "Your professional opinion of [the sample] is that it is
    			[first impression]."
    		Instead of examining something (called the sample):
    			carry out the analysing activity with the sample.
    If an activity is called X, we can now also refer to it as "the X activity"
    	for clarity's sake. (As with rulebooks called Y, which can already be
    	called "the Y rulebook". This has been done in order to make the syntax
    	for creating activity variables more explicit in its intentions.)

    ACTIONS

    Variables can also now be given to actions. These are created just before
    	the "before" rules for the action begin, and destroyed when the action ends
    	(by whatever means that should happen). If one action is interrupted by
    	another, the new action gets its own copies of these variables.
    	The names of action variables are visible only within rules in action-based
    	rulebooks ("before", "carry out", etc.).
    	But note that every action's variables are visible to every such rule -
    	as has to be true, because we can have "before" rules which take effect
    	for many different actions, for instance, and such rules might need
    	access to any of their variables. In consequence, there is only one
    	namespace for all action variables: if two different actions name
    	a variable "item", say, clashes will occur. As a result, action variables
    	should be named in a way marking out to which action they belong, and we
    	recommend including the past participle of the action name - so for
    	instance, "vehicle gone by", "door gone through", "sticky item taken", etc.
    	A simple example of an action variable:
    		The singing action has a text called the lyric sung.
    		Before singing: now the lyric sung is "Destruction of the empty spaces
    			is my one and only crime."
    		The block singing rule is not listed in any rulebook.
    		Carry out singing: say "You cheerfully warble: [quotation mark]
    			[lyric sung][quotation mark][paragraph break]".
    	One more warning: since any action-based rule can see all the action
    	variables, it's possible to refer to the variables for an action which
    	is not actually happening. For instance:
    		Before doing something when the lyric sung is "Yesterday..."
    	would compile without problems, but fail at run-time when any action
    	other than singing was tried.
    In the above example, the variable "lyric sung" was set in a before rule.
    	In practice, though, it might be needed by other before rules, and then
    	the order of operation of before rules would become uncomfortably
    	important. To get around this, a new rulebook has been created: the
    	"setting action variables" rulebook. For instance, we could write:
    		Setting action variables for singing:
    			now the lyric sung is "Mystifying eyes."
    	This rulebook is run through before even the before rules, and could be
    	used to detect the context and set variables accordingly: but it does
    	not have any power to stop or change the action, and its rules should
    	ideally say nothing and do nothing other than set rulebook variables,
    	please. (Such a rulebook must work for any actor, not just the player:
    	so if the idea is to set variables based on the local situation where
    	the action will take place, look to see where the "actor" is, not
    	where the "player" is.)
    There is a new kind of value built into Inform: "action-name". (As its
    	hyphenated name suggests, this is primarily intended for internal use,
    	but there are no restrictions on it.) An action-name identifies the
    	particular action but none of the nouns attached: it corresponds to
    	numerical Inform 6 values such as ##Go. When an action called X is
    	created, the constant value "the X action" is also created: thus
    	"the looking action", "the putting it on action", etc., are all valid
    	constant values of this kind. (For those who wish to make variables
    	properties, table columns, etc., of this kind, the default value is
    	"the waiting action", that being a sort of zero among actions.)
    It is now legal to declare a "specification text" for an action, analogously
    	with kinds, and this is used in the Actions index.

    ACTION-BASED RULES

    Inform source text describes actions with so-called "action patterns", and
    	these specify among other things who the actor must be. Up to now, there
    	have only been two ways to specify the actor, as in these examples:
    		taking a container
    		X trying taking a container
    	The former means the actor must be the player: the latter allows any
    	description X so long as X is not the player. Thus,
    		someone trying taking a container
    	allows the actor to be any person in play except the player. This made
    	it impossible to write a single rule applying to any actor equally.
    	A new third form has been added to allow for this:
    		an actor taking a container
    	For instance, we could write:
    		Instead of an actor jumping: ...
    	This implements proposal (6.35) in the January document.
    The second form of actor description above is often found to be clumsy:
    		Before X trying taking a container...
    		try X trying eating the cake...
    	Here the word "trying" is cumbersome. In a few cases it is needed to
    	make the text unambiguous, and if the description of the actual action
    	is the name of a kind of action, it is positively a good thing:
    		Before X trying risky behaviour...
    	but very often it is a nuisance. The word is now optional provided that:
    	(a) the actor is described using a description ("someone", say, or
    		"Captain Haddock") or a variable name;
    	(b) the eventual action is something explicit (like "taking...") rather
    		than a named kind of action (like "risky behaviour");
    	(c) the action is being used in a "try" (or other phrase with an action
    		as its parameter) or as the premiss for a rule.
    	In other cases, "trying" will remain obligatory, but in practice they will
    	be very few. The Examples for 4S08 contained some 120 uses of "trying"
    	between them: this reform enabled every "trying" to be removed except one,
    		Instead of someone trying disorderly conduct in the presence of
    			the policeman:
    	where it would clearly not be grammatical to remove it anyway.
    As mentioned above, every action variable is visible from every action rule.
    	But so far they have all been specific in nature to particular actions:
    	for instance "lyric sung" makes no sense for non-singing actions. But
    	we can also make general action variables, also visible from all action
    	rules, by creating variables for the "action-processing rulebook".
    	This is really a concept which has always existed - "noun" and "second
    	noun" are exactly such variables. Joining them henceforth is "actor":
    	the person trying the action.
    >--> Thus if existing source text contains references to something called
    	simply "actor", perhaps in a work of IF about the theatre, it may now
    	fail to work. (Something like "stage actor" or indeed "thespian" would
    	of course work instead. When we made this change it affected only one of
    	the Inform examples: Ballroom, which was previously using "actor" as a
    	let value in just such a rule - we changed it to read "dancer" instead.)
    Although the following is a bug fix, it is worth recording as a change in
    	behaviour. The room description at the end of a going action to a new
    	location is not technically the result of a looking action. (It doesn't
    	quite do a LOOK: for instance, it suppresses the body text for a room
    	visited before, and the paragraph spacing is different, etc.) In principle,
    	then, during such a room description the action ought still to be "going",
    	but that means that a rule such as
    		After printing the name of a person while looking: ...
    	would not take effect, which is clearly incorrect. This bug has been
    	fixed and such a rule now takes effect.
    It has always been the case up to now that the "going" action had a special
    	status in Inform: it allowed special clauses such as "... through ..."
    	(for the door gone through) not allowed for any other action, and this
    	behaviour was hard-wired into the syntax of the language. The ability
    	to create such clauses is now available to any action. For instance,
    	the following adds "...into..." and "...onto..." to Inform's syntax
    	for writing rules about dropping:
    		The dropping action has an object called the container dropped into
    			(matched as "into").
    		The dropping action has an object called the supporter dropped onto
    			(matched as "onto").
    		Rule for setting action variables for dropping:
    			if the actor is in a container (called C), now the container dropped
    				into is C;
    			if the actor is on a supporter (called C), now the supporter dropped
    				onto is C.
    	What's new here is the "(matched as...)" clause attached to the action
    	variable. We have declared that "... into X" should test to see if the
    	action variable "container dropped into" matches X, and similarly for "onto".
    	As a result, we can now write:
    		Instead of dropping something onto something, say "Don't drop things
    			onto platforms or ledges."
    		Instead of dropping something into an open container, say "Don't drop
    			things into open containers."
    	(Note that these clauses are only descriptions of the action: it makes no
    	sense to write
    		try dropping A onto B;
    	since the question of whether or not B is dropped onto depends on where the
    	player is, and is not something we can choose. Note that this is exactly
    	the same position as "going" was in before: for instance,
    		try going east from the Ballroom;
    	was and is not allowed, because the question of whether it's from the
    	Ballroom or not depends on where the player happens to be.)
    	This change implements proposal (6.37) in the January document.
    In previous builds, Inform has used a messy compromise in its handling of
    	check, carry out and report rules. These sometimes look to the user as
    	if they are single rulebooks: as if "check", for instance, is on a par
    	with "before" (which is indeed a single rulebook). In fact, for efficiency
    	reasons, there are individual check rulebooks for each action, as shown
    	by the diagram at 12.2 in the documentation.
    	Up to now, it has been legal to write a rule like
    		Check doing something: ...
    	even though this clearly can't belong to any rulebook in the diagram at
    	12.2. What was actually happening was that the checking stage used _both_
    	a single generic "check" rulebook _and_ a family of rulebooks with names
    	like "check taking". Rules defined in the Standard Rules would always go
    	into the individual rulebooks, but most (not quite all) rules created by
    	the user would end up in the generic "check" rulebook. While this gave a
    	pretty convincing illusion that all was well, it led to violations of
    	the rule-sorting principle that specific rules come before generic ones
    	("check doing something" would come before "check taking an open
    	container in the presence of a vehicle when the time of day is 11:13 AM",
    	say), and attempts to explicitly list rules into these rulebooks could
    	have odd consequences because of misunderstandings between "check" and
    	"check taking", say. Moreover, for implementation reasons, the actions
    	in the Standard Rules created check, carry out and report rulebooks
    	with funny properties which no other rulebooks had.
    	All of this has been abolished:
    	- the position is now strictly as shown in the diagram at section 12.2:
    		there are now no generic "check", "carry out" or "report" rules.
    	- all such rules are now placed into rulebooks specific to the actions
    		they belong to. Thus, e.g.,
    			Check an actor going: ...
    		is filed in the "check going" rulebook.
    	- problem messages now result from creating rules such as
    			Carry out doing something: ...
    			Report dropping or taking a container: ...
    		which cannot be filed into single unambiguous rulebooks;
    	- the Standard Rules now use the same action-creating syntax and
    		semantics as anyone else.
    	The one respect in which "check A", "carry out A" and "report A" rulebooks
    	are unlike other rulebooks is that rules in them do not check that the
    	action is indeed A. This is partly because there is no need (if we are
    	looking at the check taking rulebook, the action must be taking) but
    	mostly so that a single rule can be explicitly placed in the check (etc)
    	rules for more than one action at once. For instance, if we write:
    		Check an actor taking (this is the hypothetical rule): ...
    	and then say
    		The hypothetical rule is listed in the check removing it from rulebook.
    	the rule can be effective in both rulebooks: if it tested to see that the
    	action was taking, it would never have any effect in the check removing
    	it from rulebook, and thus it would be impractical to share rules between
    	more than one of these rulebooks - which would be inconvenient to the
    	Standard Rules, and also to extensions wanting to consider or abide by
    	rules from one action while processing another.
    We appreciate that this will cause a small amount of pain (we had to change
    	7 not-specifically-action-worded rules in the Inform examples) but we
    	think the pain is worth it for the simplification resulting, and most
    	such rules are fairly easy to recast. For instance,
    		Carry out doing something: ...
    	can probably become
    		Instead of doing something:
    			...
    			continue the action.
    	without any practical change in the outcome.
    Detailed index pages on individual actions now appear in the Index. We hope
    	these give a truer picture of what happens to any given action, by
    	showing every rule which can affect it, and making the sequence more
    	explicit.
    Problem message added to catch action descriptions which name unknown actors
    	(e.g. "Xerxes the Otherwise Never Mentioned examining the bucket" was
    	being read as simply "examining the bucket").

    THE BUILT-IN ACTIONS

    Inform provides about 70 built-in actions which form part of the model world.
    	(That is, not counting out-of-world actions such as saving the game.)
    	In previous builds these have been implemented using a special action
    	definition syntax reserved for use of the Standard Rules only, and
    	consisting essentially of tables of rule names against I6 identifiers:
    	all the rules involved were implemented by I6 code. This was bad because
    	it meant that the built-in actions were treated as special in all sorts
    	of ways (not a very clean design technique) and because it was quite
    	hard to work out how the built-in actions worked, since one needed to
    	be able to puzzle out the I6 code at the bottom of all this. On the
    	other hand, it had the advantage of speed, since Inform did not have
    	to read and compile the built-in action rules from I7 source text.
    	As discussed in the January document at (6.39), there are trade-offs
    	here, but we have now bitten the bullet and reimplemented all of the
    	(not out of world) actions in I7 source text.

    THE GOING ACTIONS

    The "going" action is the second most complex in Inform ("looking" probably
    	takes the palm) and the re-implementation in I7 has turned up two bugs
    	which have also been fixed. In addition, numerous rules have been
    	renamed or removed:
    	- the can't go through concealed doors rule has been renamed
    		the can't go through undescribed doors rule ("undescribed" being
    		the I7 word for what I6 called "concealed");
    	- the following rules have been abolished:
    			set up going rule
    			check to see if in a vehicle rule
    			determine direction property rule
    			print textual map connections rule
    			consult routine map connections rule
    			determine what's through door rule
    		These all clumsily worked out what we now regard as action variables,
    		except for the textual and routine map connections rules, which were
    		to provide backwards compatibility with traditional I6 use of the map
    		properties, which I7 doesn't recognise or use; however, we retain the
    			determine map connection rule
    		whose purpose now is to recalculate the "room gone to" variable
    		immediately before the "can't go" check. (This is done because people
    		often use before rules to modify the map, in order to make dynamic
    		map structures which respond to movement.)
    	- in the check rules, the can't go that way rule has been moved to after
    		the rules checking on undescribed and closed doors: after all how is
    		one to know that a door leads nowhere if it is closed? But if you do
    		succeed in opening such a door and try going through it, the
    		traditional I6 response "You can't, since the X leads nowhere."
    		has been restored in place of I7's recent practice of simply saying
    		"You can't go that way."
    A bug has been fixed which caused a person other than the player getting
    	off something to be reported as if he were getting out of it.

    THE LOOKING ACTIONS

    The following rules have been abolished:
    		consult LookRoutine entry point rule
    		standard searching rule
    	The former provided vestigial I6 support; the latter in all cases did
    	nothing.

    THE OBJECT MOVEMENT ACTIONS

    Under the taking action, actors other than the player can now also use a
    	"player's holdall" (if carried) to overcome carrying capacity limits.
    The following rules have been abolished:
    		default inventory style rule
    		check let-go-before rule
    		check let-go-after rule
    		check receive-before for supporter rule
    		check receive-after for supporter rule
    		check receive-before for container rule
    		check receive-after for container rule
    	These provided vestigial I6 library support and are irrelevant for I7.
    The following rules for the removing it from action have been abolished:
    		can't remove from closed containers rule
    		check after-rules for taking too rule
    		standard report removing rule
    	They had no effect in 4S08, having been pre-empted for some time by the
    	automatic conversion of removing to taking: they had been left in the
    	Standard Rules by accident but could never have any effect.
    Similarly: the
    		can't insert component parts rule
    	was redundant in 4S08 and has been removed.

    THE ACTIONS WHICH CHANGE THE STATE OF THINGS

    When the opening action by the player is successful, Inform shows the contents
    	of what was opened, provided it was opaque (so that the contents were
    	previously not visible) and provided that the player is not inside it.
    	The rule causing this was called the
    		reveal any newly visible exterior rule
    	which is a misleading - it has been renamed the
    		reveal any newly visible interior rule

    THE ACTIONS INVOLVING OTHER PEOPLE

    The following rules have been abolished:
    	check life property for giving rule
    	check life property for showing rule
    	check life property for waking rule
    	check life property for throwing at rule
    	check life property for attacking rule
    	check life property for kissing rule
    	check life property for answering rule
    	check life property for telling rule
    	check life property for asking rule
    	check thrown-at rule
    	These provided vestigial I6 library support and are irrelevant for I7.
    As for the do-nothing actions (see below), these are now also handled
    	symmetrically for all actors. (Thus, for instance, the block attacking
    	rule now blocks any actor attacking any other.)

    THE DO NOTHING ACTIONS

    The actions indexed as "Actions which always do nothing unless rules
    	intervene", which consist only of a single checking rule to block them,
    	behaved asymmetrically in previous builds since they blocked the
    	action for the player, but allowed it to run through untouched and
    	with no rules applying for any other actor. This could result in odd
    	transcripts such as:
    		> SING
    		Your singing is abominable.
    		> PETER, SING
    		>
    	...because no rules at all fire for Peter trying singing, so the
    	action succeeds by default, and nothing is said or done.
    	In this build, the blocking rules for do-nothing actions now block
    	all actors. Thus:
    		> PETER, SING
    		Peter is unable to do that.
    	or with ACTIONS switched on:
    		> PETER, SING
    		[asking Peter to try singing]
    		[(1) Peter trying singing]
    		[(1) Peter trying singing - failed the block singing rule]
    		Peter is unable to do that.
    		[asking Peter to try singing - succeeded]
    	This affects the actions:
    		Saying yes, Saying no, Burning, Waking up, Thinking, Smelling,
    		Listening to, Tasting, Cutting, Jumping, Tying it to, Drinking,
    		Saying sorry, Swearing obscenely, Swearing mildly, Swinging,
    		Rubbing, Setting it to, Waving hands, Buying, Singing,
    		Climbing, Sleeping
    >--> While this is much more logical, and means that every (non-out-of-world)
    	action in the Standard Rules now works equally for all actors, it does
    	mean that a rule in the form:
    		After Peter trying singing: ...
    	will no longer work, because Peter's singing action will be blocked and
    	never reach the "after" stage. To get around this:
    		Instead of Peter trying singing:
    			...
    			the rule succeeds.
    	Note the last line, forcing the action to be considered a success: actions
    	stopped by instead rules are normally deemed to fail, but making this
    	succeed means that no "Peter is unable to do that." text will be printed.

    PHRASES

    Inform has been made a little stricter in when it allows certain phrases
    	to be used. For instance, the phrase "decide on X", which chooses a
    	value X, is now only allowed in a phrase "To decide which ..." - of
    	course it didn't make sense anywhere else, but this is now policed.
    	Similarly, "decide yes" is now restricted to phrases which need to
    	decide if something is or isn't true, and so on. (We're pretty certain
    	that this new check only rejects uses which do not at all achieve what
    	they look as they ought to do.)
    Similarly, "decide on X" now checks the kind of X to see if it matches the
    	required kind. This may produce problems either at compile time, or
    	at run-time. Note in particular that "nothing" is forbidden as a
    	value to decide on if we are required to produce a particular kind
    	of object such as, say, a "room", but is allowed if we are only required
    	to produce an "object". (This agrees with the conventions used for
    	variables.)
    Finally, phrases to decide a value now return the default value of the
    	appropriate kind if execution runs through to the end of the definition
    	without having reach any "decide on X" phrase.
    Problem message added to explain why two bracketed phrase terms immediately
    	next to each other, with no word in between, is against the rules -
    	e.g. "To combine (X - a number) (Y - a number)". (Previously Inform
    	would allow the definition, but then never recognise it in source text,
    	which was not a very helpful way of rejecting it.)
    Bug fixed whereby setting up a phrase "To decide what X is ..." might
    	read X as a description of a thing rather than a kind of value in
    	cases where X is both the name of such a kind, and also part of the
    	name of a thing. (For instance, if there is an object somewhere called
    	"number puzzle", then a phrase "To decide what number is ..." was
    	being misread as if its type had to be always the number puzzle object,
    	not a number.)

    PROPERTIES

    Two changes have been made to the way that assertions about either/or
    	properties of kinds are read. To demonstrate, consider the sentence in
    	the Standard Rules which reads
    		A thing is usually inedible.
    	What if we want to contradict this? In previous builds, we could write:
    		A thing is never inedible.
    	This worked, but owing to a bug,
    		A thing is always edible.
    	did not work - this bug has now been fixed. In either of these sentences,
    	we undo the sentence in the Standard Rules by writing a sentence which is
    	more definite - certain ("never", "always") rather than merely likely
    	("usually"). But what if we don't want extra certainty? In previous builds,
    	writing
    		A thing is usually edible.
    	would have no effect, because when two inferences are drawn about the
    	same property which contradict but which are each uncertain, the original
    	first-drawn inference is allowed to stand, and the second is ignored.
    	This convention has been reversed in the case of inferences drawn about
    	properties of kinds:
    		A later uncertain assertion about a property of a kind beats
    		an earlier uncertain assertion about the same property.
    Problem message added for saying that a kind has an either/or property
    	without previously having said that it can have that property. This
    	would usually not work anyway, but in previous builds, saying "K is
    	usually openable." would make it so: Inform now insists that we write
    	"K can be openable. K is usually openable.", as the documentation implies.
    	(The examples A Haughty Spirit and Disappointment Bay 12 needed to be
    	corrected in just this way.)
    Problem message added (rather than internal error) to reject implications
    	where the implied outcome is a value property rather than a simple
    	either/or property like open/closed.
    Problem message added to explain why "D can be X or Y" makes no sense if
    	D is something qualified by adjectives - e.g. "An open door can be
    	rickety or sturdy" makes no sense because the door still has to have the
    	property even at times when it is not open. (Previously Inform simply
    	ignored the adjectives, and assigned the property to the underlying kind.)
    Bug fixed whereby saying "now X is P" could be misconstrued if P refers to a
    	property but does so inexplicitly: for instance, "now X is the colour of
    	the button" would try to change X to be equal to this colour whereas
    	"now X is green" would simply change the colour of X. Both forms now
    	change the properties, not the identity, of X.
    Bug fixed whereby large numbers of either/or properties created for things,
    	followed by an either/or property being created for rooms, would sometimes
    	lead to bogus programming errors at run time.
    Bug fixed whereby creating a new either/or property but giving its antonym
    	as an existing one would sometimes wrongly be allowed, leading to
    	peculiar run-time problem messages. (E.g. writing "The Catwalk can be
    	flaming or unlit." causes this, because "unlit" is already the antonym
    	of "lit", a property of things.)
    Bug fixed whereby certain complicated forms of property assignment in
    	assertions could cause an internal error (e.g., "Blinky is an ephemeral
    	ghost with reaction "Boo!".").

    EXAMPLES

    New example "Croft" added to demonstrate action variables.
    The now usually unnecessary word "trying" (see above) has been removed from
    	most of the examples involving actions.

    MISCELLANEOUS

    Problem messages added for creating table columns whose names are articles
    	or existing values such as literal numbers.
    Problem message added (rather than internal error) for initialising a
    	K that varies (where K is a kind) to the value "nothing". This is legal
    	for an object that varies (though in 4S08 a bug blocked this), but not
    	where the variable always has to hold something of a given kind.
    Problem message added (rather than internal error) for an attempt to total
    	the column of a table rather than a property.
    Problem message added (rather than eventual I6 errors) for defining plurals
    	using quotation marks, e.g., writing 'The plural of "coin" is monies.'
    	rather than 'The plural of coin is monies.'
    Better problem message added for close square brackets used wrongly as
    	literals in quoted text.
    Bug fixed whereby continuations of tables would sometimes wrongly be reported
    	as containing columns not found in the original tables, and would
    	sometimes (even when they worked) have their columns incorrectly matched
    	up to the original table, in cases where the columns had been reordered.
    Bug fixed whereby a compound sentence asserting a relationship both with a
    	new specific object and also a new object described only generically by
    	naming its kind, as in:
    		The big box contains a container and Peter.
    	...would fail complaining of an overly complicated relationship.
    Bug fixed whereby the word "visible", redundantly used in a grammar token
    	as in e.g.
    		Understand "inspect [any visible thing]" as examining.
    	would cause a hang because I6 scope loops can't be nested.
    Bug fixed whereby hanging dependent clauses which depended on local variables
    	would sometimes be construed unexpectedly. (This really only affected
    	descriptions which were not very useful anyway, e.g., "the number of
    	things worn by X which fit Y", which is not good style since it in
    	fact evaluates the number of things worn by an X-which-fits-Y - that
    	is, the "which fit Y" clause appends to X and not the things.)
    Bug fixed whereby the "after reading a command" rulebook would sometimes
    	fail to be able to replace matched text in a command in cases where it had
    	been rewritten as a result of a "Which do you mean...?" question.
    Bug fixed whereby the character @ could not be parsed at run-time, and an
    	attempt to write something like 'Understand "@" as the giant at-symbol'
    	would produce I6 errors.
    Bug fixed whereby expressions containing more than one bracketed subexpression
    	would sometimes be misparsed: e.g. "let a be (x + y) / (x - y)" would
    	produce spurious problem messages despite being legal syntax.
    Bug fixed whereby Definitions involving looking up entries in tables would
    	sometimes compile through I7 but cause I6 errors.
    Bug fixed whereby calculations of the other side of a door, or the direction
    	taken by a door, would sometimes be incorrect in darkness.
    Bug fixed whereby problems to do with variable initialisation were
    	reported at the correct sentences but under the wrong headings.

Previous | Contents | Next