<ulclass="crumbs"><li><ahref="../index.html">Home</a></li><li><ahref="../inform7n.html">Inform7</a></li><li><ahref="index.html">values</a></li><li><ahref="index.html#P">Preliminaries</a></li><li><b>What This Module Does</b></li></ul></div>
<ulclass="toc"><li><ahref="P-wtmd.html#SP1">§1. Prerequisites</a></li><li><ahref="P-wtmd.html#SP2">§2. For want of a better word</a></li><li><ahref="P-wtmd.html#SP4">§4. Taxonomy</a></li><li><ahref="P-wtmd.html#SP9">§9. Dash</a></li><li><ahref="P-wtmd.html#SP10">§10. Literals</a></li><li><ahref="P-wtmd.html#SP11">§11. Grammar</a></li></ul><hrclass="tocbar">
<pclass="commentary firstcommentary"><aid="SP1"class="paragraph-anchor"></a><b>§1. Prerequisites. </b>The values module is a part of the Inform compiler toolset. It is
presented as a literate program or "web". Before diving in:
full details, but essentially: it's C without predeclarations or header files,
and where functions have names like <spanclass="extract"><spanclass="extract-syntax">Tags::add_by_name</span></span> rather than just <spanclass="extract"><spanclass="extract-syntax">add_by_name</span></span>.
<pclass="commentary firstcommentary"><aid="SP2"class="paragraph-anchor"></a><b>§2. For want of a better word. </b>What is a value? In the compiler for an orthodox programming language this is
relatively easy to answer,<supid="fnref:1"><ahref="#fn:1"rel="footnote">1</a></sup> but natural language often resists categorisation.
Even basic attempts to divide, say, nouns from verbs sometimes break down.
<pclass="commentary">Until around 2016, the Inform source had a C type called <spanclass="extract"><spanclass="extract-syntax">type_specification</span></span>,
since it had its origins in specifying the "type" of phrase tokens,<supid="fnref:2"><ahref="#fn:2"rel="footnote">2</a></sup> but "type
specification" was never a happy phrase, and coding with <spanclass="extract"><spanclass="extract-syntax">type_specification</span></span>
was never really satisfactory. It has now been removed, and what we now call just
"specifications" are stored directly as fragments of the parse tree: that is,
as <spanclass="extract"><spanclass="extract-syntax">parse_node</span></span> pointers. This new scheme removed complexity,<supid="fnref:3"><ahref="#fn:3"rel="footnote">3</a></sup> and is faster,
while consuming less memory. There are demerits too,<supid="fnref:4"><ahref="#fn:4"rel="footnote">4</a></sup> but the die is cast.
<ulclass="footnotetexts"><liclass="footnote"id="fn:1"><pclass="inwebfootnote"><supid="fnref:1"><ahref="#fn:1"rel="footnote">1</a></sup> Though, for example: are functions values? How about pointers to functions?
Parameters passed by reference, or pass-throughs? Are types also values? How
about type classes? Conditions? Exceptions? And if the answer is no, why can
<ahref="#fnref:1"title="return to text">↩</a></p></li><liclass="footnote"id="fn:2"><pclass="inwebfootnote"><supid="fnref:2"><ahref="#fn:2"rel="footnote">2</a></sup> Inform phrases include even structural language features like "if", and
are not simply function calls: so their tokens can be conditions, lvalues,
or descriptions as well as rvalues. The "type" of such a token must therefore
be broader than simply a kind, because only values have kinds.
<ahref="#fnref:2"title="return to text">↩</a></p></li><liclass="footnote"id="fn:3"><pclass="inwebfootnote"><supid="fnref:3"><ahref="#fn:3"rel="footnote">3</a></sup> A fairly convoluted conversion layer of code once existed in order to
<ahref="#fnref:3"title="return to text">↩</a></p></li><liclass="footnote"id="fn:4"><pclass="inwebfootnote"><supid="fnref:4"><ahref="#fn:4"rel="footnote">4</a></sup> The main demerit is that while all specifications are <spanclass="extract"><spanclass="extract-syntax">parse_node</span></span>s, not
<ahref="#fnref:4"title="return to text">↩</a></p></li></ul>
<pclass="commentary firstcommentary"><aid="SP3"class="paragraph-anchor"></a><b>§3. </b>Given that these disparate ideas are hard to unify, it might seem clearer
not to unify them at all — if they are different concepts, represent that
<pclass="commentary">The reason we need to unify is that Inform's concept of a phrase is much
broader than the concept of a function in a C-like language. Whereas an
argument of a C function must be an rvalue, Inform phrases can take arguments
(they are actually called tokens) which can be lvalues or descriptions. This
allows basic structural features such as "if" to be defined as phrases. But it
also means that we need a single type able to represent phrase token
requirements inside the Inform source code.
</p>
<pclass="commentary firstcommentary"><aid="SP4"class="paragraph-anchor"></a><b>§4. Taxonomy. </b>Specifications fall into four categories: rvalues, lvalues, conditions and
descriptions. Various functions, such as <ahref="2-spc.html#SP1"class="internal">Specifications::is_condition</a>,
exist to determine whether a given <spanclass="extract"><spanclass="extract-syntax">parse_node</span></span> is one of these.
</p>
<pclass="commentary firstcommentary"><aid="SP5"class="paragraph-anchor"></a><b>§5. </b>"Rvalues" specify pieces of data at run-time. Numbers, texts and instances
are all examples of rvalues, but so are usages of phrases to decide
values (i.e., function calls). See <ahref="2-rvl.html"class="internal">Rvalues</a>.
</p>
<pclass="commentary">These mostly come from parsing source text, but we can also manufacture them
directly. If we need the number 17 as a constant, for example, we can call
<ahref="2-rvl.html#SP10"class="internal">Rvalues::from_int</a> to make a suitable <spanclass="extract"><spanclass="extract-syntax">parse_node</span></span>, even if "17" is never
mentioned in the source text read in. And a wide range of other functions
exist to make constant rvalues of all kinds: <ahref="2-rvl.html#SP13"class="internal">Rvalues::from_Unicode</a>,
<pclass="commentary firstcommentary"><aid="SP6"class="paragraph-anchor"></a><b>§6. </b>"Lvalues" specify places to store data, such as variables, or table entries.
See <ahref="2-lvl.html"class="internal">Lvalues</a>.
</p>
<pclass="commentary">Functions such as <ahref="2-lvl.html#SP2"class="internal">Lvalues::new_LOCAL_VARIABLE</a> allow us to take
<pclass="commentary">These traditional computer-science terms, "lvalue" and "rvalue", are based
on L for left, R for right, in an assignment operation like <spanclass="extract"><spanclass="extract-syntax">v = 5</span></span>.
Here <spanclass="extract"><spanclass="extract-syntax">v</span></span> is on the left and is an l-value: it's a variable, that is, a named
place to store data. The <spanclass="extract"><spanclass="extract-syntax">5</span></span> is an r-value, and is the data which will be
stored. Of course, <spanclass="extract"><spanclass="extract-syntax">v</span></span> can also occur on the right, as in the assignment
<spanclass="extract"><spanclass="extract-syntax">w = v</span></span> where one variable is copied into another. But in this source code
we would call <spanclass="extract"><spanclass="extract-syntax">v</span></span> an lvalue wherever it appears — we mean only that it has
the potential to be written to.<supid="fnref:5"><ahref="#fn:5"rel="footnote">5</a></sup>
</p>
<ulclass="footnotetexts"><liclass="footnote"id="fn:5"><pclass="inwebfootnote"><supid="fnref:5"><ahref="#fn:5"rel="footnote">5</a></sup> We have to treat lvalues in this slightly unusual way because, contrary to
C-like languages, we have no syntactic way to mark that the name of a variable
means its value rather than its identity — in C, this would be <spanclass="extract"><spanclass="extract-syntax">name</span></span> versus
<spanclass="extract"><spanclass="extract-syntax">&name</span></span>, with the "pointer to" marker <spanclass="extract"><spanclass="extract-syntax">&</span></span> distinguishing the cases. We must
instead look to the context. Even C sometimes does that — when C writes <spanclass="extract"><spanclass="extract-syntax">v = 5</span></span>,
it would arguably be more consistent to say something like <spanclass="extract"><spanclass="extract-syntax">store(&v, 5)</span></span>.
<ahref="#fnref:5"title="return to text">↩</a></p></li></ul>
<pclass="commentary firstcommentary"><aid="SP7"class="paragraph-anchor"></a><b>§7. </b>"Conditions" express a state of being which might, or might not, be true:
Inform allows these to be tested with "if" and brought about with "now".
</p>
<pclass="commentary">Whereas in C-like languages conditions are rvalues and vice versa —
you can write <spanclass="extract"><spanclass="extract-syntax">a = b == c</span></span>, or <spanclass="extract"><spanclass="extract-syntax">if (7)</span></span>— this often feels a little rum,
and in natural language even more so. In Inform, then, a condition is not an
rvalue, and an rvalue is not a condition.
</p>
<pclass="commentary">Possible states are stored as propositions in predicate calculus with no
free variables: the function <ahref="2-cnd.html#SP8"class="internal">Conditions::new_TEST_PROPOSITION</a> makes
a condition out of a proposition.
</p>
<pclass="commentary firstcommentary"><aid="SP8"class="paragraph-anchor"></a><b>§8. </b>"Descriptions" express a state of something which is not directly specified,
which again might, or might not, be true. For example, "an open door" is
a description: some objects are, and some objects are not, open doors.
</p>
<pclass="commentary">Descriptions are stored as propositions in predicate calculus with one
free variable: the function <ahref="2-dsc.html#SP1"class="internal">Descriptions::from_proposition</a> makes
a description out of a proposition.
</p>
<pclass="commentary">Note that the name of a kind, such as "number", can also be seen as a
description: <ahref="2-dsc.html#SP3"class="internal">Descriptions::from_kind</a> turns \(K\) into the description \(K(x)\).
</p>
<pclass="commentary firstcommentary"><aid="SP9"class="paragraph-anchor"></a><b>§9. Dash. </b>Suppose that a specification has been written in a particular context. Does
<ahref="5-dsh.html#SP8"class="internal">Dash::check_condition</a> and <ahref="5-dsh.html#SP8"class="internal">Dash::check_value</a> determine whether a
specification is indeed a condition or an lvalue/rvalue of a given kind.
</p>
<pclass="commentary">Dash aims to be pragmatic rather than clever<supid="fnref:6"><ahref="#fn:6"rel="footnote">6</a></sup>, and its goal is to issue
good problem messages rather than, say, to have good running time on heroically
large composite expressions — those essentially never arise in natural language.
</p>
<ulclass="footnotetexts"><liclass="footnote"id="fn:6"><pclass="inwebfootnote"><supid="fnref:6"><ahref="#fn:6"rel="footnote">6</a></sup> In particular it does not need a constraint-satisfaction algorithm, as is
needed by the almost-Turing complete type systems in some languages.
<ahref="#fnref:6"title="return to text">↩</a></p></li></ul>
<pclass="commentary firstcommentary"><aid="SP10"class="paragraph-anchor"></a><b>§10. Literals. </b><ahref="3-pl.html"class="internal">Chapter 3: Literals</a> then works through different ways to write constant values in
source text, which we loosely call "literals". What makes them literal is that
they explicitly state values rather than simply naming them. Thus "15" is a
literal but "the score" is not, even if it is a variable which happens to have
the value 15.
</p>
<pclass="commentary">The linguistics module has built-in support for parsing numbers, so we don't
need to do that basic digit-parsing here: see <ahref="../linguistics-module/1-cao.html"class="internal">Cardinals and Ordinals (in linguistics)</a>
for details. But we will also want <ahref="3-ll.html"class="internal">Literal Lists</a> in braces, <ahref="3-ul.html"class="internal">Unicode Literals</a>
for character names, and <ahref="3-tod.html"class="internal">Times of Day</a>; and also user-defined notations
for user-defined kinds. For example:
</p>
<blockquote>
<p>16:9 specifies an aspect ratio.</p>
</blockquote>
<pclass="commentary">would establish a new notation for the kind "aspect ratio", supposing that
had already been created. See <ahref="3-lp.html"class="internal">Literal Patterns</a>.
</p>
<pclass="commentary firstcommentary"><aid="SP11"class="paragraph-anchor"></a><b>§11. Grammar. </b>What remains, then, is the general Preform grammar for Inform's expressions
and conditions — the so-called "S-parser", since it produces specifications.
This is the content of <ahref="4-ets.html"class="internal">Chapter 4: The S-Parser</a>.