<ulclass="crumbs"><li><ahref="../webs.html">★</a></li><li><ahref="index.html">if</a></li><li><ahref="index.html#5">Chapter 5: Command Grammar</a></li><li><b>Introduction to Grammar</b></li></ul><pclass="purpose">An exposition of the data structures and basic method used to deal with the command-parsing grammar implied by Understand sentences in the source text.</p>
<pclass="inwebparagraph"><aid="SP1"></a><b>§1. </b>This is grammar in the sense of the parsing structures used at run-time,
and it occupies a chapter of its own in the source code since it is to some
extent detached from the rest of NI: what we create in this chapter is
almost an independent compiler in its own right, but of a much simpler
language. Although we use many higher-level features of NI in the process,
none use this.
</p>
<pclass="inwebparagraph">Grammar is organised in a three-level hierarchy:
</p>
<pclass="inwebparagraph"></p>
<ulclass="items"><li>(a) A grammar verb (GV) is a small independent grammar of alternative
formulations for some concept: for instance, the possible commands beginning
TAKE, or the possible verbal forms of numbers. Each GV is a list of GLs, and
an individual GL must belong to exactly one GV. There are five different
types of GV, differentiated mostly by the purpose to which the GV is put:
<ulclass="items"><li>(1) <codeclass="display"><spanclass="extract">GV_IS_COMMAND</span></code>. An imperative verbal command at run-time.
</li><li>(2) <codeclass="display"><spanclass="extract">GV_IS_TOKEN</span></code>. A square-bracketed token in other grammar.
</li><li>(3) <codeclass="display"><spanclass="extract">GV_IS_OBJECT</span></code>. A noun phrase at run time: a name for an object.
</li><li>(4) <codeclass="display"><spanclass="extract">GV_IS_VALUE</span></code>. A noun phrase at run time: a name for a value.
</li><li>(5) <codeclass="display"><spanclass="extract">GV_IS_CONSULT</span></code>. A pattern to match in part of a command (such as "consult").
</li><li>(6) <codeclass="display"><spanclass="extract">GV_IS_PROPERTY_NAME</span></code>. A noun phrase at run time: a name for one
possibility for an either/or property, say "open" or "fixed in place".
</li></ul>
</li></ul>
<pclass="inwebparagraph"></p>
<ulclass="items"><li>(b) A grammar line (GL) is a single possibility within a GV: for
example, the line matching <codeclass="display"><spanclass="extract">"take [something]"</span></code> in the GV for the TAKE
command. Each GL is a list of tokens, and an individual token must belong
to exactly one GL.
</li></ul>
<ulclass="items"><li>(c) A grammar token (GTOK) is a single particle of a GL: for
example, <codeclass="display"><spanclass="extract">'take'</span></code> and <codeclass="display"><spanclass="extract">something</span></code> are tokens.
</li></ul>
<pclass="inwebparagraph">The picture is not quite so hierarchical as it looks, though, because
a GV naming a token can be used as a token inside other GVs. We need to
be careful that this does not lead to infinite regress: see below.
</p>
<pclass="inwebparagraph">Much of what we do with grammar involves recursing down this hierarchy,
in some cases allowing results to percolate back upwards. What happens
takes place in four chronological phases. (This division into phases is
convenient because Inform 6 requires that all general parsing routines
and noun filter routines already exist when a <codeclass="display"><spanclass="extract">Verb</span></code> directive is reached
which uses them.)
</p>
<pclass="inwebparagraph"><aid="SP2"></a><b>§2. Phase I: Slash Grammar. </b>Slashing is the process of dealing with slashes <codeclass="display"><spanclass="extract">/</span></code> used in grammar
to indicate alternatives.
</p>
<pclass="inwebparagraph"><aid="SP3"></a><b>§3. Phase II: Determining Grammar. </b>We check that the grammar is well-founded and find the types of values
expressed by it, if any.
</p>
<pclass="inwebparagraph">Determining well-foundedness means checking that no two grammar tokens
each require the use of the other, and that when a grammar token takes
several alternative forms, they have compatible results: so, for instance,
you can't have one version resulting in a number and another in a thing.
(This check is only meaningful for grammar verbs of type <codeclass="display"><spanclass="extract">GV_IS_TOKEN</span></code>.)
</p>
<pclass="inwebparagraph">The result of a <codeclass="display"><spanclass="extract">GV_IS_TOKEN</span></code> is a single specification, which is the union of the
kinds resulting from its grammar lines. This is a more sophisticated approach
than we really need here, but might be useful for future expansion.
</p>
<pclass="inwebparagraph">Of the determining traverse the following can be said:
</p>
<pclass="inwebparagraph"></p>
<ulclass="items"><li>(a) either errors are produced, or it is verified that no token's
definition depends directly or indirectly on already knowing itself;
</li></ul>
<ulclass="items"><li>(b) also that no grammar line attached to a <codeclass="display"><spanclass="extract">GV_IS_COMMAND</span></code> produces
more than 2 values, and that no grammar line attached to anything else
produces more than one; and
</li></ul>
<ulclass="items"><li>(c) also that the grammar lines attached to a <codeclass="display"><spanclass="extract">GV_IS_TOKEN</span></code> are
compatible in that there is a type to which they can all always be cast.
</li></ul>
<pclass="inwebparagraph">We note of the determining routines that:
</p>
<pclass="inwebparagraph"></p>
<ulclass="items"><li>(a) <codeclass="display"><spanclass="extract">PL::Parsing::Verbs::determine</span></code> runs at least once for each GV;
</li></ul>
<ulclass="items"><li>(b) <codeclass="display"><spanclass="extract">PL::Parsing::Lines::gl_determine</span></code> runs exactly once on each GL;
</li></ul>
<ulclass="items"><li>(c) <codeclass="display"><spanclass="extract">PL::Parsing::Tokens::determine</span></code> runs exactly once on each token.
</li></ul>
<pclass="inwebparagraph"><aid="SP4"></a><b>§4. Phase III: Sort Grammar. </b>We must ensure that if grammar line L1 is logically impossible once L2
has been parsed, then L1 must be checked before L2, regardless of the
ordering in the source code. Since the data sets are very small and
time is not of the essence, we simply insertion-sort the original
definition-order list into a second linked list.
</p>
<pclass="inwebparagraph"><aid="SP5"></a><b>§5. Phase IV: Compile Grammar. </b>The final run-through, which uses the sorted order and not the original
declaration order, actually compiles the necessary I6 <codeclass="display"><spanclass="extract">Verb</span></code> and