I6 Template Layer

WriteListOfMarkedObjects.

This routine will use the MarkedListIterator. That means it has to create an array containing the object numbers of every object with the workflag2 attribute set, placing the address of this array in MarkedObjectArray and the length in MarkedObjectLength. Note that we preserve any existing marked list on the stack (using the assembly-language instructions @push and @pull) for the duration of our use.

While the final order of this list will depend on what it looks like after coalescing, the initial order is also important. If all of the objects have a common parent in the object tree, then we coalesce those objects and place the list in object tree order. But if not, we place the list in object number order (which is essentially the order of traversal of the initial state of the object tree: thus objects in Room A will all appear before objects in Room B if A was created before B in the source text).

List Number and Gender.

As a brief parenthesis, the same algorithm can be used to work out the prior named list number and gender for everything matching a description.

List Writer Regard Storage.

This is somewhat hacky, but enables "[regarding list writer internals]".

Response Printing.

From which:

About Iterator Functions.

Suppose Iter is an iterator function and that we have a "raw list" x₁, x₂, ..., x_n of objects. Of these, the iterator function will choose a sublist of "qualifying" objects. It is called with arguments

where the obj is required to be x_j for some j and the function is one of the *_ITF constants defined below:

(a) On START_ITF, we return x₁, or nothing if the list is empty.

(b) On SEEK_ITF, we return the smallest k ≥ j such that x_k qualifies, or nothing if none of x_j, x_j+1, ..., x_n qualify.

(c) On ADVANCE_ITF, we return the smallest k > j such that x_k qualifies, or nothing if none of x_j+1, x_j+2 ..., x_n qualify.

(d) On COALESCE_ITF, we coalesce the entire list (not merely the qualifying entries) and return the new x₁, or nothing if the list is empty.

Thus, given any x_i, we can produce the sublist of qualifying entries by performing START_ITF on x_i, then SEEK_ITF, to produce q₁; then ADVANCE_ITF to produce q₂, and so on until nothing is returned, when there are no more qualifying entries. SEEK_ITF and ADVANCE_ITF always return qualifying objects, or nothing; but START_ITF and COALESCE_ITF may return a non-qualifying object, since there's no reason why x₁ should qualify in any ordering.

The iterator can make its own choice of which entries qualify, and of what the raw list is; depth is supplied to help in that decision. But if L is non-zero then the iterator is required to disqualify any entry whose list_together value is not L.

Marked List Iterator.

Here the raw list is provided by the MarkedObjectArray, which is convenient for coalescing, but not so helpful for translating the obj parameter into the i such that it is x_i. We simply search from the beginning to do this, which combined with other code using the iterator makes for some unnecessary O(n²⁾ calculations. But it saves memory and nuisance, and the iterator is used only with printing to the screen, which never needs to be very rapid anyway (because the player can only read very slowly).

Concealment.

This is the definition of concealment used by the list-writer, and means that, for example, the "deciding the concealed possessions" activity is taken into account.

Coalesce Marked List.

The return value is the new first entry in the raw list.

Object Tree Iterator.

Here the raw list is the list of all children of a given parent: since the argument obj is required to be a member of the raw list, we can use parent to find it. Now seeking and advancing are fast, but coalescing is slower.

Coalesce Object Tree.

Again, the return value is the new first entry in the raw list.

WriteListFrom.

And here we go at last. Or at any rate we initialise the quartet of global variables detailing the current list-writing process, and begin.

Standard Contents Listing Rule.

The default for the listing contents activity is to call this rule in its "for" stage: note that this suppresses the use of the activity, to avoid an infinite regress. The activity is used only for the default ObjectTreeIterator, so there is no need to specify which is used.

Partitioning.

Given qualifying objects x₁, ..., x_j, we partition them into classes of the equivalence relation x_i ~ x_j if and only

(i) they both have a plural property (not necessarily the same), and (ii) neither will cause the list-maker to recurse downwards to show the objects inside or on top of them, and (iii) if they cause the list-maker to add information about whether they are worn, lighted or open, then it will add the same information about both, and (iv) they are considered identical by the parser, in that they respond to the same syntaxes of name: so that it is impossible to find a TAKE X command such that X matches one and not the other.

The equivalence classes are numbered consecutively upwards from 1 to n, in order of first appearance in the list. For each object x_i, partition_classes-> is the number of its equivalence class. For each equivalence class number c, partition_class_sizes->c is the number of objects in this class.

Partition List.

The following creates the partition_classes and partition_class_sizes accordingly. We return n, the number of classes.

Equivalence Relation.

The above algorithm will fail unless ListEqual is indeed reflexive, symmetric and transitive, which ultimately depends on the care with which Identical is implemented, which in turn hangs on the parse_noun properties compiled by NI. But this seems to be sound.

Grouping.

A "group" is a maximally-sized run of one or more adjacent partition classes in the list whose first members have a common value of list_together which is a routine or string, and which is not equal to lt_value, the current grouping value. (As we see below, it's by setting lt_value that we restrict attention to a particular group: if we reacted to that as a list_together value here, then we would simply go around in circles, and never be able to see the individual objects in the group.)

For instance, suppose we have objects with list_together values as follows, where R₁ and R₂ are addresses of routines:

coin (R₁), coin (R₁), box (R₂), statuette (0), coin (R₁), box (R₂)

Then the partition is 1, 1, 2, 3, 1, 2, so that the final output will be something like "three coins, two boxes and a statuette" – with three grouped terms. Here each partition class is the only member in its group, so the number of groups is the same as the number of classes. (The above list is not coalesced, so the R₁ values, for instance, are not contiguous: we need to work in general with non-coalesced lists because not every iterator function will be able to coalesce fully.)

But if we have something like this:

coin (R₁), Q (R₂), W (R₂), coin (R₁), statuette (0), E (R₂), R (R₂)

then the partition is 1, 2, 3, 1, 4, 5, 6 and we have six classes in all. But classes 2 and 3 are grouped together, as are classes 5 and 6, so we end up with a list having just four groups: "two coins, the letters Q and W from a Scrabble set, a statuette and the letters E and R from a Scrabble set". (Again, this list has not been fully coalesced: if it had been, it would be reordered coin, coin, Q, W, E, R, statuette, with partition 1, 1, 2, 3, 4, 5, 6, and three groups: "two coins, the letters Q, W, E and R from a Scrabble set and a statuette".)

The reason we do not group together classes with a common non-zero list_together which is not a routine or string is that low values of list_together are used in coalescing the list into a pleasing order (say, moving all of the key-like items together) but not in grouping: see list_together in the Inform Designer's Manual, 4th edition.

We calculate the number of groups by starting with the number of classes and then subtracting one each time two adjacent classes share list_together in the above sense.

Write List Recursively.

The big one: WriteListR is the heart of the list-writer.

Write Multiple Class Group.

The text of a single group which contains more than one partition class. We carry out the "grouping together" activity, so that the user can add text fore and aft – this is how groups of objects such as "X, Y and Z" can be fluffed up to "the letters X, Y and Z from a Scrabble set" – but the default is simple: we print the grouped items by calling WriteListR once again, but this time starting from X, and where lt_value is set to the common list_together value of X, Y and Z. (That restricts the list to just the objects in this group.) Because lt_value is set to this value, the grouping code won't then group X, Y and Z again, and they will instead be individual classes in the new list – so each will end up being sent, in turn, to WriteSingleClassGroup below, and that is where they are printed.

Write Single Class Group.

The text of a single group which contains exactly one partition class. Because of the way the multiple-class case recurses, every class ends up in this routine sooner or later; this is the place where the actual name of an object is printed, at long last.

Write After Entry.

Each entry can be followed by supplementary, usually parenthetical, information: exactly what, depends on the style. The extreme case is when the style, and the object, call for recursion to list the object-tree contents: this is achieved by calling WriteListR, using the ObjectTreeIterator (whatever the iterator used at the top level) and increasing the depth by 1.

Internal Rule.

This rule does nothing in itself; it exists as a placeholder for the response texts used by the list-writer.