An overview of the assertions module's role and abilities.

§1. Prerequisites. The assertions module is a part of the Inform compiler toolset. It is presented as a literate program or "web". Before diving in:

§2. Assertions. This module's task is to read the declarative sentences in the source text, such as "Mrs Jones is wearing a trilby hat" or "Brightness is a kind of value", which assert that something is true. These are converted into propositions in predicate calculus, which are sent in a stream to the knowledge module. Those propositions may be mutually inconsistent, or not even be self-consistent or meaningful: but that is for knowledge to worry about. Our task is just to provide a list of supposedly true statements.

Between the linguistics and calculus modules we have extensive equipment for parsing regular sentences already, so it would seem simple to act on a sentence like "Mr Herries knows Howarth." And so it would be if people called "Mr Herries" and "Howarth" were already known to exist. Unfortunately, this may be the first mention of them, and that makes things much more complicated.

Even if they do exist, they may be referred to ambiguously. If there are two different people both called Kassava, who is meant by "Carter knows Kassava"? This depends on context: see Name Resolution.

Though it is rather under-developed at present, Inform also has minimal support for "anaphora", that is, for cross-references between sentences using pronouns such as "it". See Anaphoric References, but don't expect much.

§3. So, then, top-level declarations are dealt with like so: 

Classification:
SENTENCE_NT'jane is a woman' {classified}
    VERB_NT'is' {verb 'be' 3p s act IS_TENSE +ve}
    UNPARSED_NOUN_NT'jane'
    UNPARSED_NOUN_NT'woman' {indefinite 'a' n/m/f nom/acc s}
Refined:
    CREATED_NT'jane' {refined}
    COMMON_NOUN_NT'woman' {indefinite 'a' n/m/f nom/acc s} {refined} {refers: infs'woman'} {creation: << woman(x) >>} {eval: TEST_VALUE_NT}
After creation:
SENTENCE_NT'jane is a woman' {classified}
    VERB_NT'is' {verb 'be' 3p s act IS_TENSE +ve}
    PROPER_NOUN_NT'jane' {refined} {refers: infs'jane'} {eval: CONSTANT_NT'jane' {kind: object} {instance: 'jane'} {enumeration: 0}} {created here}
    COMMON_NOUN_NT'woman' {indefinite 'a' n/m/f nom/acc s} {refined} {refers: infs'woman'} {creation: << woman(x) >>} {eval: TEST_VALUE_NT}

§4. Special meanings. In the same way that programming languages have a few "reserved words" which cue up built-in language features, even though they may look like user-defined functions or variables, Inform has a few verbs with "special meanings", which make requests directly to the compiler. These occupy Chapter 3: Requests, which is really just a catalogue of ways to ask for things.

All that we do is parse such sentences and then make a call to some appropriate function, usually in one of the other modules. For example, the section New Activity Requests dismantles sentences like "Counting is an activity on numbers", but then just calls //Activities::new// (in the knowledge module) to take action.

§5. Regular meanings. As noted above, Assertions::make_coupling is called on each regular assertion: coupling being a lingistic term for placing subject and object into a relationship with each other. What it does is to split into cases according to the subject and object phrases of a sentence. These can take 12 different forms, so there are \(12\times 12 = 144\) possible combinations of subject with object, and a \(12\times 12\) matrix is used to determine which of 42 cases the sentence falls into.

Each case then leads either to a proposition being formed, or to a problem message being issued. Most of the easier cases are dealt with in the (admittedly quite long) assertions section, but harder ones are delegated to the remaining sections in Chapter 4: Assertions.

The brief story above implied that each sentence is turned into a single proposition, as if this part of Inform can act as a sort of pipeline: text in, proposition out. But it is not quite so simple, and for the hardest sentences we must store notes on what to add later. For example, in Assemblies, a sentence like "In every container is a coin" cannot take immediate effect. It clearly creates a whole lot of coin instances, but we don't yet know what is a container and what is not. That will depend on conclusions to be drawn by the knowledge module later on. Similarly, though a little easier, Implications like "Something worn is usually wearable" do not immediately lead to propositions being drawn up.

§6. Making use of the calculus module. Chapter 5: Predicates simply stocks up our predicate calculus system with some basic unary and binary predicates, and provides a few shorthand functions to make commonly-needed propositions (see Calculus Utilities).

More specialised predicates will also be added by other modules, so the roster here is not complete, but these are the essentials.