mirror of
https://github.com/ganelson/inform.git
synced 2024-07-08 18:14:21 +03:00
515 lines
25 KiB
HTML
515 lines
25 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>P/ti</title>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<meta http-equiv="Content-Language" content="en-gb">
|
|
<link href="inweb.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
</head>
|
|
<body>
|
|
|
|
<!--Weave of 'P/dpiti' generated by 7-->
|
|
<ul class="crumbs"><li><a href="../webs.html">★</a></li><li><a href="index.html">inter 1</a></li><li><a href="index.html#P">Preliminaries</a></li><li><b>Data Packages in Textual Inter</b></li></ul><p class="purpose">How static data, variables and constants are expressed in textual inter programs.</p>
|
|
|
|
<ul class="toc"><li><a href="#SP1">§1. Data packages</a></li><li><a href="#SP2">§2. Kinds and values</a></li><li><a href="#SP5">§5. Enumerations and instances</a></li><li><a href="#SP6">§6. Properties of instances</a></li><li><a href="#SP7">§7. Constants</a></li><li><a href="#SP9">§9. Global variables</a></li><li><a href="#SP10">§10. Responses</a></li><li><a href="#SP11">§11. Metadata</a></li><li><a href="#SP12">§12. Append and Link</a></li><li><a href="#SP13">§13. Nop</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="inwebparagraph"><a id="SP1"></a><b>§1. Data packages. </b>To recap: a file of textual inter has a brief global section at the top, and
|
|
is then a hierarchiy of package definitions. Each package begins with a
|
|
symbols table, but then has contents which depend on its type. This section
|
|
covers the possible contents for a data package, that is, one whose type
|
|
is not <code class="display"><span class="extract">_code</span></code>. Note that, in particular, the <code class="display"><span class="extract">main</span></code> package is always a
|
|
data package, so there must be at least one in the program.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">"Data" is a slightly loose phrase for what data packages contain: it
|
|
includes metadata, and indeed almost anything other than actual executable
|
|
code. Data packages, unlike code packages, can also contain other packages
|
|
(of either sort).
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP2"></a><b>§2. Kinds and values. </b>Inter is a very loosely typed language, in the sense that it is possible
|
|
to require that values conform to particular data types. As in Inform, data
|
|
types are called "kinds" in this context (which usefully distinguishes them
|
|
from "types" of packages, a completely different concept).
|
|
</p>
|
|
|
|
<p class="inwebparagraph">No kinds are built in: all must be declared before use. However, these
|
|
declarations are able to say something about them, so they aren't entirely
|
|
abstract. The syntax is:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">kind NAME CONTENT</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">The <code class="display"><span class="extract">NAME</span></code>, like all names, goes into the owning package's symbol table;
|
|
other packages wanting to use this kind will have to have an <code class="display"><span class="extract">external</span></code>
|
|
symbol pointing to this definition.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><code class="display"><span class="extract">CONTENT</span></code> must be one of the following:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) <code class="display"><span class="extract">unchecked</span></code>, meaning that absolutely any data can be referred to by this type;
|
|
</li><li>(b) <code class="display"><span class="extract">int32</span></code>, <code class="display"><span class="extract">int16</span></code>, <code class="display"><span class="extract">int8</span></code>, <code class="display"><span class="extract">int2</span></code>, for numerical data stored in these numbers
|
|
of bits (which the program may choose to treat as character values, as flags,
|
|
as signed or unsigned integers. and so on, as it pleases);
|
|
</li><li>(c) <code class="display"><span class="extract">text</span></code>, meaning text;
|
|
</li><li>(d) <code class="display"><span class="extract">enum</span></code>, meaning that data of this kind must be equal to one (and only one)
|
|
of the enumerated constants with this kind;
|
|
</li><li>(e) <code class="display"><span class="extract">table</span></code>, a special sort of data referring to tables made up of columns each
|
|
of which has a different kind;
|
|
</li><li>(f) <code class="display"><span class="extract">list of K</span></code>, meaning that data must be a list, each of whose terms is
|
|
data of kind <code class="display"><span class="extract">K</span></code> — which must be a kind name known to the symbols table
|
|
of the package in which this definition occurs;
|
|
</li><li>(g) <code class="display"><span class="extract">column of K</span></code>, similarly, but for a table column;
|
|
</li><li>(h) <code class="display"><span class="extract">relation of K1 to K2</span></code>, meaning that data must be such a relation, in the
|
|
same sort of sense as in Inform;
|
|
</li><li>(i) <code class="display"><span class="extract">description of K</span></code>, meaning that data must be a description which either
|
|
matches or does not match values of kind <code class="display"><span class="extract">K</span></code>;
|
|
</li><li>(j) <code class="display"><span class="extract">struct</span></code>, which is similar to <code class="display"><span class="extract">list of K</span></code>, but which has entries which do
|
|
not all have to have the same kind;
|
|
</li><li>(k) and <code class="display"><span class="extract">routine</span></code>, meaning that data must be references to functions.
|
|
</li></ul>
|
|
<p class="inwebparagraph">For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">kind k_boolean int2</span>
|
|
<span class="plain">kind k_list_of_bool list of k_boolean</span>
|
|
<span class="plain">kind K_grammatical_tense enum</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP3"></a><b>§3. </b>In the remainder of this specification, <code class="display"><span class="extract">VALUE</span></code> means either the name of
|
|
a defined <code class="display"><span class="extract">constant</span></code> (see below), or else a literal.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">A literal <code class="display"><span class="extract">int32</span></code>, <code class="display"><span class="extract">int16</span></code>, <code class="display"><span class="extract">int8</span></code>, or <code class="display"><span class="extract">int2</span></code> can be written as any of the
|
|
following:
|
|
</p>
|
|
|
|
<ul class="items"><li>(a) a decimal integer which may begin with a minus sign (and, if so, will be
|
|
interpreted as twos-complement signed);
|
|
</li><li>(b) a hexadecimal imteger prefixed with <code class="display"><span class="extract">0x</span></code>, which can write the digits
|
|
<code class="display"><span class="extract">A</span></code> to <code class="display"><span class="extract">F</span></code> in either upper or lower case form, but cannot take a minus sign;
|
|
</li><li>(c) a binary integer prefixed with <code class="display"><span class="extract">0b</span></code>, which cannot take a minus sign.
|
|
</li></ul>
|
|
<p class="inwebparagraph">For example, <code class="display"><span class="extract">-231</span></code>, <code class="display"><span class="extract">0x21BC</span></code> and <code class="display"><span class="extract">0b1001001</span></code> are all valid. If the literal
|
|
supplied is too large to fit into the kind, an error is thrown.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">A literal <code class="display"><span class="extract">list</span></code> is writtem in braces: <code class="display"><span class="extract">{ V1, V2, ..., Vn }</span></code>, where <code class="display"><span class="extract">V1</span></code>,
|
|
<code class="display"><span class="extract">V2</span></code> and so on must all be acceptable literals for the entry kind of the
|
|
list. For example, <code class="display"><span class="extract">{ 2, 3, 5, 7, 11, 13, 17, 19 }</span></code>. The same notation is
|
|
also accepted for a <code class="display"><span class="extract">struct</span></code>, a <code class="display"><span class="extract">column</span></code> or a <code class="display"><span class="extract">table</span></code>. For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">constant C_egtable_col1 K_column_of_number = { 1, 4, 9, 16 }</span>
|
|
<span class="plain">constant C_egtable_col2 K_column_of_colour = { I_green, undef, I_red }</span>
|
|
<span class="plain">constant C_egtable K_table = { C_egtable_col1, C_egtable_col2 }</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">A list-like notation can also be used for a "calculated literal". This is
|
|
a single value, but which we may not be able to evaluate at inter generation
|
|
time. For example, if we do not yet know the value of <code class="display"><span class="extract">X</span></code>, we can write
|
|
<code class="display"><span class="extract">sum{ X, 1 }</span></code> to mean <code class="display"><span class="extract">X+1</span></code>. A present, addition is the only operation
|
|
catered for in this way.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">A literal <code class="display"><span class="extract">text</span></code> is written in double quotes, <code class="display"><span class="extract">"like so"</span></code>. All characters
|
|
within such text must have Unicode values of 32 or above, except for tab (9),
|
|
writtem <code class="display"><span class="extract">\t</span></code>, and newline (10), written <code class="display"><span class="extract">\n</span></code>. In addition, <code class="display"><span class="extract">\"</span></code> denotes a
|
|
literal double-quote, and <code class="display"><span class="extract">\\</span></code> a literal backslash, but these are the only
|
|
backslash notations at present allowed.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">There are then a number of notations which look like texts, prefixed by
|
|
indicative characters.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><code class="display"><span class="extract">r"text"</span></code> makes a literal real number: the text is required to take the
|
|
same form as a literal real number in Inform 6. The result is valid
|
|
for use in an <code class="display"><span class="extract">int32</span></code>, where it is interpreted as a float. For example,
|
|
<code class="display"><span class="extract">r"$+1.027E+5"</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><code class="display"><span class="extract">dw"text"</span></code> is meaningful only for interactive fiction, and represents the
|
|
command parser dictionary entry for the word <code class="display"><span class="extract">text</span></code>. This is equivalent
|
|
to the Inform 6 constant <code class="display"><span class="extract">'text//'</span></code>. <code class="display"><span class="extract">dwp"text"</span></code> is the same, but pluralised,
|
|
equivalent to Inform 6 <code class="display"><span class="extract">'text//p'</span></code>. Again, these can be stored in an <code class="display"><span class="extract">int32</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><code class="display"><span class="extract">&"text"</span></code> makes a literal value called a "glob". This is not a respectful
|
|
term, and nor does it deserve one. A glob is a raw Inform 6 expression,
|
|
which can't (easily) be compiled for any other target, but is simply
|
|
copied literally through. Its kind is <code class="display"><span class="extract">unchecked</span></code>, so it can be used
|
|
absolutely anywhere.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><code class="display"><span class="extract">^"text"</span></code> is not really a value at all, and is called a "divider". This
|
|
is really a form of comment used in the middle of long lists. Thus the
|
|
list <code class="display"><span class="extract">{ 1, 2, ^"predictable start", 3721, -11706 }</span></code> is actually a list of four values
|
|
but which should be compiled on two lines with the comment in between:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">1, 2, ! predictable start</span>
|
|
<span class="plain">3721, -11706</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">(As unnecessary as this feature seems, it does make the code produced by
|
|
Inform look a lot more readable when it finally reaches Inform 6.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The literal <code class="display"><span class="extract">undef</span></code> can be used to mean "this is not a value".
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Convention. It is intended that Inform will never make use of globs, but
|
|
at present about 30 globs persist in typical inter produced by Inform.
|
|
None of these are generated by Inform 7 as such: they all arise from the
|
|
oddball expressions in the template code which the code generator can't
|
|
</p>
|
|
|
|
<ul class="items"><li>(yet) assimilate.
|
|
</li></ul>
|
|
<p class="inwebparagraph">Inform generates <code class="display"><span class="extract">undef</span></code> values to represent missing entries in tables,
|
|
but otherwise makes no use of them.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP4"></a><b>§4. </b>Kinds have "default values": if some piece of storage has to hold a value
|
|
of kind <code class="display"><span class="extract">K</span></code>, but that value is not specified, then the default is used.
|
|
For example, the default <code class="display"><span class="extract">int32</span></code> is zero.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">This can be controlled using <code class="display"><span class="extract">defaultvalue KIND = VALUE</span></code>. For example,
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">defaultvalue K_boolean = 0</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP5"></a><b>§5. Enumerations and instances. </b>As noted above, some kinds marked as <code class="display"><span class="extract">enum</span></code> are enumerated. This means
|
|
that they can have only a finite number of possible values, each of which
|
|
is represented in textual inter by a different name.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">These values are called "instances" and must also be declared. For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">kind K_grammatical_tense enum</span>
|
|
<span class="plain">instance I_present_tense K_grammatical_tense</span>
|
|
<span class="plain">instance I_past_tense K_grammatical_tense</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">It is also possible to specify numerical values to be used at run-time:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">instance I_present_tense K_grammatical_tense = 1</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">If so, then such values must all be different (for all instances of that kind).
|
|
Enum values must fit into an <code class="display"><span class="extract">int16</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Enumerations, but no other kinds, may have "subkinds", as in this example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">kind K_object enum</span>
|
|
<span class="plain">kind K1_room <= K_object</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">This creates a new <code class="display"><span class="extract">enum</span></code> kind <code class="display"><span class="extract">K1_room</span></code>. Values of this are a subset of
|
|
the values for its parent, <code class="display"><span class="extract">K_object</span></code>: thus, an instance of <code class="display"><span class="extract">K1_room</span></code> is
|
|
automatically also an instance of <code class="display"><span class="extract">K_object</span></code>. This new subkind can itself
|
|
have subkinds, and so on.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP6"></a><b>§6. Properties of instances. </b>A "property" is a named value attached to all instances of a given kind,
|
|
and must be created before use with:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">property NAME KIND</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">which declares that <code class="display"><span class="extract">NAME</span></code> is a property whose value has the given <code class="display"><span class="extract">KIND</span></code>;
|
|
however, it doesn't say which kind(s) can have this property, so we also
|
|
have to give one or more "permissions", in the form
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">permission NAME KIND</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">And once that is done, actual values can be assigned with:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">propertyvalue NAME OWNER = VALUE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">where <code class="display"><span class="extract">OWNER</span></code> can either be the name of a whole kind, in which case this sets
|
|
the default value of the property for instances of that kind, or else the name
|
|
of a specific instance, in which case this sets just the property of a single
|
|
thing. In either case, it is an error to do this unless the necessary
|
|
permission has been established.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The given value is just the initial state; at run-time, it can be changed to
|
|
another value (of the same kind).
|
|
</p>
|
|
|
|
<p class="inwebparagraph">For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">kind K_object enum</span>
|
|
<span class="plain">kind K_text text</span>
|
|
<span class="plain">property P_printed_name K_text</span>
|
|
<span class="plain">permission P_printed_name K_object</span>
|
|
<span class="plain">propertyvalue P_printed_name K_object = "something"</span>
|
|
<span class="plain">instance I_ball K_object</span>
|
|
<span class="plain">propertyvalue P_printed_name I_ball = "beach ball"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP7"></a><b>§7. Constants. </b>A constant definition assigns a name to a given value: where that name is
|
|
used, it evaluates to this value. The syntax is:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">constant NAME KIND = VALUE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">where the value given must itself be a constant or literal, and must conform
|
|
to the given kind. As always, this is conformance only in the very weak
|
|
system of type checking used by Inter: if either the value or the constant
|
|
has an <code class="display"><span class="extract">unchecked</span></code> kind, then the test is automatically passed.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">For example,
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">kind K_number int32</span>
|
|
<span class="plain">constant favourite_prime K_number = 16339</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">Constants can have any kind, including enumerated ones, but if so then that
|
|
does not make them instances. For example,
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">kind K_colour enum</span>
|
|
<span class="plain">instance C_red K_colour</span>
|
|
<span class="plain">instance C_green K_colour</span>
|
|
<span class="plain">constant C_favourite K_colour = C_green</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">does not make <code class="display"><span class="extract">C_favourite</span></code> a new possible colour: it's only a synonym for
|
|
the existing <code class="display"><span class="extract">C_green</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP8"></a><b>§8. </b>If a constant needs to refer to a function, we seem to run into the limitation
|
|
that there's no notation for literal functions. In fact there is, though:
|
|
that's what code packages are. For example,
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">kind K_number int32</span>
|
|
<span class="plain">kind K_number_to_number K_number -> K_number</span>
|
|
<span class="plain">package R_101_B _code</span>
|
|
<span class="plain"> ...</span>
|
|
<span class="plain">constant R_101 K_number_to_number = R_101_B</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">defines the constant <code class="display"><span class="extract">R_101</span></code>. Note that <code class="display"><span class="extract">R_101_B</span></code> is not a value, because
|
|
package names are not values; but <code class="display"><span class="extract">R_101</span></code> on the other hand is a value, and
|
|
can be stored and used at run-time like any other value.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP9"></a><b>§9. Global variables. </b>Variables are like properties, except that each exists only as a single
|
|
value, not attached to any instance in particular: it makes no sense to ask
|
|
who the owner is. Variables must be declared as:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">variable NAME KIND = VALUE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">The given value is just the initial state; at run-time, it can be changed to
|
|
another value (of the same kind). For example,
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">variable V_score K_number = 10</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP10"></a><b>§10. Responses. </b>A "response" is a special sort of property belonging to a function rather than
|
|
an instance: it's a piece of text. This can be set with:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">response NAME MARKER FUNCTION = VALUE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"><code class="display"><span class="extract">NAME</span></code> provides a unique symbol name identifying this specific response; this
|
|
is needed so that other code elsewhere in the program can alter this response
|
|
at run-time. <code class="display"><span class="extract">MARKER</span></code> indicates which of 26 possible responses is meant: in
|
|
high-level Inform 7 code these are labelled with the letters A to Z, but in
|
|
inter, the numbers 0 to 25 must be used. The <code class="display"><span class="extract">VALUE</span></code> must be textual, that is,
|
|
must be a <code class="display"><span class="extract">text</span></code> literal.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP11"></a><b>§11. Metadata. </b>This has no effect on the code generated, and is simply semantic markup for
|
|
the benefit of onlookers. The scheme here is that any package can have a
|
|
dictionary of textual key-value pairs, specified by:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">metadata KEY: VALUE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">Here <code class="display"><span class="extract">KEY</span></code> must be a (public) symbol whose name begins with a backtick, and
|
|
<code class="display"><span class="extract">VALUE</span></code> must be literal text. For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">metadata `name: "blue book"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP12"></a><b>§12. Append and Link. </b>Two rather ugly constructs are currently needed in order to implement very
|
|
low-level features of Inform 7, at points in I7's design where the normally
|
|
subterranean presence of Inform 6 pokes up above the surface:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><code class="display"><span class="extract">append NAME "RAW I6 CODE"</span></code> tells Inter to add the given raw code to whatever
|
|
it compiles as the definition (in I6) of whatever the symbol <code class="display"><span class="extract">NAME</span></code> refers to.
|
|
For example, the I7 source text:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>Include (- has door, -) when defining a door.</p>
|
|
|
|
</blockquote>
|
|
|
|
<p class="inwebparagraph">results in the following inter being generated:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">append K4_door " has door, \n"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"><code class="display"><span class="extract">link STAGE "SEGMENT" "PART" "CONTENT" "OTHER"</span></code> tells Inter that it needs
|
|
to make an alteration to the Inform 6 code inside the I6T template file
|
|
<code class="display"><span class="extract">SEGMENT</span></code>, at heading <code class="display"><span class="extract">PART</span></code>; the <code class="display"><span class="extract">STAGE</span></code> must be one of <code class="display"><span class="extract">early</span></code>, <code class="display"><span class="extract">before</span></code>,
|
|
<code class="display"><span class="extract">instead</span></code> or <code class="display"><span class="extract">after</span></code>. For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">link after "Output.i6t" "I6 Inclusions" "\n[ LITTLE_USED_DO_NOTHING_R; rfalse; ];\n" ""</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP13"></a><b>§13. Nop. </b>The "nop" statement has no textual representation. It does nothing, and exists
|
|
only as a convenience used by Inform when it needs to write simultaneously to
|
|
multiple positions within the same node's child list — the idea being that
|
|
a nop statement acts as a divider. For example, by placing the A write
|
|
position just before a nop N, and the B write position just after, Inform
|
|
will generate A1, A2, A3, ..., N, B1, B2, ..., rather than (say) A1, B1, A2,
|
|
A3, B2, ... The extra N is simply ignored in code generation, so it causes
|
|
no problems to have it.
|
|
</p>
|
|
|
|
<hr class="tocbar">
|
|
<ul class="toc"><li><a href="P-ti.html">Back to 'Textual Inter'</a></li><li><a href="P-cpiti.html">Continue with 'Code Packages in Textual Inter'</a></li></ul><hr class="tocbar">
|
|
<!--End of weave-->
|
|
</body>
|
|
</html>
|
|
|