The commit and Github issue above did not fix the problem. It was much deeper than suspected. Vince Laviano has painstakingly pored over the library and found what seems to be a solution. It will be detailed in the next note.

Read on for the gory details, some actual bugs, and some thoughts on inform6lib development.

What's the issue?

When we run the test program for issue 1885, we see:

Somewhere
You're not sure where you are.
You can see four rocks, a stone and a girl here.
>girl, drop rock
The girl observes that the rock is already here.
>girl, drop rocks
There is no reply.
>drop rock
The rock is already here.
>drop rocks
There is nothing to drop.

When all of the rocks are on the ground and we try to drop a single rock, parsing succeeds and we receive a response from the Drop action telling us that the rock is already here.

When we try to drop multiple rocks, parsing fails and no action is generated. Instead, we receive an error message from the parser.

When we order the girl to drop the rocks, this error is transformed into a NotUnderstood action, sent to the girl's orders, and redirected to her life, where it ultimately produces the suboptimal default response that we see.

In this post, we'll focus on the simpler DROP ROCKS command with the player as the actor.

There are 3 grammar lines for DROP, and "drop rocks" fails to match any of them. Line 0 (* multiheld -> Drop) is one that we'd expect to match our input and the one that we'll focus on here.

The grammar requires the word 'drop' followed by text matching a multiheld token. The DM4 describes multiheld as "one or more held objects", but, as we can see from our success parsing DROP ROCK, this isn't a hard and fast rule; the reality is a little more nuanced.

If we crank up the trace level to 5, we can see more detail as the parser tries to parse "rocks" as a multiheld token:

The parser calls ParseToken__ to match a multiheld token (with input "rocks"), which calls NounDomain to find the best matching object or objects in the actor's scope.

Notice that, when NounDomain is first called, we're "seeking definite object", but, by the beginning of Adjudicate, we're looking for all of an indefinite group of objects ("indefinite_type: plural, number wanted: all"). This happens because, when NounDomain calls SearchScope to find matching objects in the actor's scope, TryGivenObject finds that a rock matches the plural dictionary word 'rocks//p'. This causes the parser to switch into indefinite plural mode. We look for "all" (represented by 100) because no specific number has been requested (we didn't type DROP TWO ROCKS):

In contrast, DROP ROCK does not trigger this code and remains in definite mode, accounting for the difference in results that we'll see.

After NounDomain finds multiple objects that match "rocks" ("NounDomain made 4 matches"), it calls Adjudicate to score them and disambiguate among them. This process depends on the actor, action_to_be, the token that we're trying to match, whether we're in definite or indefinite mode, and the state of the world model at the time. It's described in some detail in §33 of the DM4 on pages 240-242, about which more below.

During disambiguation, we reach a block of code specific to indefinite plural mode, and (spoiler) it rejects all four of our rocks! (For I7 people: this code is analogous to the deciding whether all includes activity.):

The for loop iterates over all candidate objects and accepts or rejects each one in turn based on a series of tests. For DROP ROCKS, all of the rocks are rejected, resulting in a multiple object of size 0 which percolates up the parser and triggers a parse error.

The specific test that rejects the rocks is " if (context == MULTIHELD_TOKEN or MULTIEXCEPT_TOKEN && parent(j) ~= actor)".

So, that's what's happening.

In indefinite plural mode, for a multiheld token, an object is rejected unless the actor is holding it, even when there are no other candidates.

In definite mode, an object might be disfavored for multiheld because it's not held, but it's not rejected outright when there are no other candidates.

This code raises a couple issues that I'll discuss later in this post.
- Why is MULTIEXCEPT also included in this test when it ostensibly has nothing to do with held objects but simply excludes the indirect object?
- This indef plural code differs from the 6/11 version, with the initial value of flag reversed. The 6/12 version of the test for concealed and worn is incorrect.

Notice also that an author can provide a ChooseObjects function that can override the parser's decision (stored in flag). See DM4 §33 page 239.

Is this behavior intended?

Yes.

It's mentioned in the DM4's explanation of disambiguation:

(From DM4 Section 33 page 241 rule 7ip (indef plural)

(7ip) The following rule applies only in indefinite mode and provided the player has
typed something definitely implying a plural, such as the words ``all'' or ``three''
or ``coins''. Here the parser already has a target number of objects to choose:
for instance 3 for ``three'', or the special value of 100, meaning ``an unlimited
number'', for ``all'' or ``coins''.
Go through the list of objects in ``best guess'' order (see below). Mark each as
``accept'' unless:
(i) it has worn or concealed;
(ii) or the action is Take or Remove and the object is held by the actor;
(iii) or the token is multiheld or multiexcept and the object isn't held by
the actor;
(iv) or the target number is ``unlimited'' and S=20 (rounded down to the nearest
integer) has fallen below its maximum value, where S is the score of the
object.
The entry point ChooseObjects(object,accept_flag) is now called and can
overrule the ``accept''/``reject'' decision either way. We keep accepting objects like
this until the target is reached, or proves impossible to reach.

Section (iii) makes it clear that this is intended behavior.

For additional evidence, in issue 0001488, filed against I7 about a multiexcept issue, but stemming from the exact same line of code, GN says:

(quote from Graham Nelson:)

I've looked into this, and it's by design - the design of the old I6 parser. What happens is not that "2 mints in bowl" isn't recognised: in fact it is recognised, but the standard rules about what can go into a multiple object apply, and they reject the mints because they're not being held by the current actor. This can be changed by hacking with the "does the player mean" rules.

(The I7 does the player mean rules are roughly analogous to ChooseObjects.)

The idea behind the indef plural disambiguation is that we want to decide what should reasonably be included in "all" or a group of objects based on the context of the actor, the action, and the world.

The particular rule that caused our issue says that, when an actor is performing an action that prefers held objects, those are the objects that the parser should choose preferentially. It only breaks down when there are no candidate objects that meet the criteria, as in DROP ROCKS when all rocks are on the ground.

So what can we do?

If we want the best of both worlds, we can write a ChooseObjects routine for our test program that will allow the parser to reject rocks on the ground when there are better candidates, while forcing it to accept rocks on the ground when there are none. (This also handles Take which suffers from a similar issue.)

Somewhere
You're not sure where you are.
You can see four rocks, a stone and a girl here.
>take two rocks
rock: Taken.
rock: Taken.
>drop rocks
rock: Dropped.
rock: Dropped.
>drop rocks
rock: The rock is already here.
rock: The rock is already here.
rock: The rock is already here.
rock: The rock is already here.
>take two rocks
rock: Taken.
rock: Taken.
>take rocks
rock: Taken.
rock: Taken.
>take rocks
rock: You already have that.
rock: You already have that.
rock: You already have that.
rock: You already have that.

Can we do more?

We could change the parser to relax this rejection filter when there is an undifferentiated set of candidates while still using it to disambiguate among candidates with differing characteristics.

However, it would take a bit of restructuring since the indef plural loop rejects candidates one at a time in decreasing BestGuess order. It's only later in Adjudicate that objects are grouped into equivalence classes.

Also, it's not clear that everyone would agree that the behavior in the transcript above is desirable. To quote the DM4's introduction to ChooseObjects:

(from DM4 Section 33 page 239)

The Inform parser resolves ambiguous object names with a pragmatic algorithm
which has evolved over the years (see below). Experience also shows that no two
people ever quite agree on what the parser should ``naturally'' do. Designers have an
opportunity to influence this by providing an entry point routine called ChooseObjects:

My conclusion: use ChooseObjects.

Here ends the discussion of DROP ROCKS. Next up are a couple of side issues, and then some thoughts about I6 library development moving forward.

Back to David now:

The side issues will be written up separately and the I6 library development concerns will be discussed at intfiction.org until someone decides to file an issue report about it if such a thing is necessary.