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


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

§2. What predicate calculus is. The word "calculus" is often used to mean differentiating and integrating functions, but properly speaking that is "infinitesimal calculus", and there are many others.1 In logic, different sets of rules for making deductions tend to be given such names, and we will use (a form of) one of the most popular simple systems, "predicate calculus".2

Most attempts to codify the meaning of sentences in any systematic way involve predicate calculus, and most people generally seem to agree that linguistic concepts (like verbs, adjectives, and determiners) correspond uncannily well with logical ones (like binary predicates, unary predicates, and quantifiers).3 All the same, it is striking how good the fit is, considering that human language is so haphazard at first sight.

At any rate Inform goes along with this consensus, and converts the difficult passages in its source text into logical "propositions" — lines written in logical notation. This is useful partly as a tidy way to store complicated meanings inside the program, but also because these propositions can then be simplified by logical rules, without changing their meaning. Without such simplifications, Inform would generate much less efficient code.

§3. Notation. This module deals with propositions in predicate calculus, that is, with logical statements which are normally written in mathematical notation. To the end user of Inform, these are invisible: they exist only inside the compiler and are never typed in or printed out. But for the debugging log, for unit testing, and for the literate source, we need to do both of these.

A glimpse of the propositions generated by Inform can be had by running this test, whose output uses our notation:

Laboratory is a room. The box is a container.
Test sentence (internal) with a man can see the box in the Laboratory.
Test description (internal) with animals which are in lighted rooms.

But a much easier way to test the functions in this module is to use the calculus-test tool. As with kinds-test, this is a REPL: that is, a read-evaluate-print-loop tool, which reads in calculations, performs them, and prints the result.

'<< >>': << >>
'<< is-a-kind (x) >>': << is-a-kind(x) >>
'<< is-a-var (x) >>': << is-a-var(x) >>
'<< is-a-const (x) >>': << is-a-const(x) >>
'<< everywhere (x) >>': << everywhere(x) >>
'<< nowhere (x) >>': << nowhere(x) >>
'<< here (x) >>': << here(x) >>
'<< called = magic passcode (x) >>': << called='magic passcode'(x) >>
'<< kind = number (x) >>': << kind=number(x) >>
'new unary blue': ok
'<< blue (x) >>': << blue(x) >>
'<< (x == y) >>': << (x == y) >>
'new binary sees': ok
'<< sees (x, y) >>': << sees(x, y) >>
'<< NOT< ^ blue (x) ^ NOT> >>': << NOT< blue(x) NOT> >>
'<< Forall x IN< kind = number (x) IN>: blue (x) >>': << ForAll x IN< kind=number(x) IN> : blue(x) >>
'<< Exists x >>': << Exists x >>
'<< DoesNotExist x IN< kind = number (x) IN>: blue (x) >>': << DoesNotExist x IN< kind=number(x) IN> : blue(x) >>
'<< Forall x IN< kind = number (x) IN>: blue (x) >>': << ForAll x IN< kind=number(x) IN> : blue(x) >>
'<< Card= 6 x IN< kind = number (x) IN>: blue (x) >>': << Card=6 x IN< kind=number(x) IN> : blue(x) >>

§4. Formal description. 1. A "term" is any of the following:

Note that if we have given values to the necessary variables, then any term can be evaluated to a value, and its kind determined. For example, if x is 7, then the terms 17, x and f(x) evaluate to 17, 7 and \(f(7)\) respectively.

2. An "atomic proposition" is any of the following:

3. A "proposition" is a sequence of 0 or more of the following:

§5. The implementation uses the term "atom" a little more loosely, to include four punctuation marks: NOT<, NOT>, IN<, IN>, which act like opening and closing parentheses. These are considered atoms purely for convenience when building more complicated constructions — they make no sense standing alone. Thus:

Note that the domain \(D\) of a quantifier is itself expressed as a proposition. Thus "for all numbers \(n\)" is implemented as ForAll n IN< kind=number(n) IN>.

In all other cases, adjacent atoms in a sequence are considered to be conjoined: i.e., X Y means \(X\land Y\), the proposition which is true if \(X\) and \(Y\) are both true. To emphasise this, the textual notation uses the ^ sign. For example, odd(n) ^ prime(n) is the notation for two consecutive atoms odd(n) and prime(n).

§6. Unary predicates. We have a mixed bag of unary predicates, as follows.

As is apparent, the is-a-... predicates are a cheat: they exist purely to make it easier to write propositions which change the state of the world, rather than discuss that state. For example, Inform might create the kind "animal" by asserting Exists x : is-a-kind(x) ^ called=animal(x).

Otherwise, while these are all conceptually unary predicates, only the first is a PREDICATE_ATOM in our implementation: the others are KIND_ATOM, CALLED_ATOM,

§7. Binary predicates. By contrast all binary predicate atoms use PREDICATE_ATOM, and there is only one set of them — but with that said,

New BPs can be constructed with BinaryPredicates::make_pair. The term "pair" is used because every \(B\) has a "reversal" \(B^r\), such that \(B^r(s, t)\) is true if and only if \(B(t, s)\). \(B\) and \(B^r\) are created in pairs.7

§8. Making propositions. Propositions are built incrementally, like Lego, with a sequence of function calls.

1. Terms are made using the functions Calculus::Terms::new_constant, Calculus::Terms::new_variable and Calculus::Terms::new_function.

2. Unary predicate atoms are made using:

Binary predicate atoms are made using Calculus::Atoms::binary_PREDICATE_new.

3. Propositions are then built up from atoms or other propositions8 by calling:

§9. There are two senses in which it's possible to make an impossible proposition:

The functions Calculus::Propositions::is_syntactically_valid and Calculus::Variables::is_well_formed test that (1) and (2) have not happened. It's because of (2) that it's important to use Calculus::Propositions::conjoin and not the simpler Calculus::Propositions::concatenate.

To illustrate:

'new unary even': ok
'<< NOT> >> is syntactically valid': false - too many close groups
'<< Exists x >> is syntactically valid': true
'<< ForAll x >> is syntactically valid': false - ends without domain of final quantifier
'<< ForAll x IN< kind = number (x) IN>: even (x) >> is syntactically valid': true
'<< Forall x IN< kind = number (x) IN>: even (x) >> is syntactically valid': true
'set A to << Exists x >>': a set to << Exists x >>
'set B to << Exists x: even (x) >>': b set to << Exists x : even(x) >>
'A concatenate B': << Exists x : Exists x : even(x) >>
'A conjoin B': << Exists x : Exists y : even(y) >>
'A concatenate B is syntactically valid': true
'A conjoin B is syntactically valid': true
'A concatenate B is well-formed': false - x used outside its binding
'A conjoin B is well-formed': true