mirror of
https://github.com/ganelson/inform.git
synced 2024-07-08 18:14:21 +03:00
212 lines
9.7 KiB
HTML
212 lines
9.7 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>P/ia</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/io' 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>Inform Organisation</b></li></ul><p class="purpose">The standard hierarchy of inter code generated by Inform.</p>
|
|
|
|
<ul class="toc"><li><a href="#SP1">§1. Status</a></li><li><a href="#SP2">§2. Global area and main</a></li><li><a href="#SP3">§3. Compilation modules</a></li><li><a href="#SP5">§5. Function packages</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="inwebparagraph"><a id="SP1"></a><b>§1. Status. </b>The Inter specification allows great flexibility in how packages are used
|
|
to structure a program, and requires very little.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The Inform compiler, however, uses this flexibility in a systematic way,
|
|
as follows.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP2"></a><b>§2. Global area and main. </b>Inform opens with a version number, then declares package types (as needed
|
|
below), issues pragmas for I6 compiler memory settings, then declares
|
|
primitives for the standard Inform set: it always declares the same set
|
|
of primitives on every run.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">As required, the rest of the program is in the <code class="display"><span class="extract">main</span></code> package, which has
|
|
type <code class="display"><span class="extract">_plain</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP3"></a><b>§3. Compilation modules. </b>Inform divides up its material into compilation modules, as follows. Each
|
|
one becomes an inter package of type <code class="display"><span class="extract">_module</span></code>, and is a subpackage of <code class="display"><span class="extract">main</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) The "generic module" contains built-in definitions of kinds, and the like.
|
|
No source text directly leads to this, and indeed, it can entirely be defined
|
|
without having seen any source text: it will be the same on every run. The
|
|
package is <code class="display"><span class="extract">/main/generic</span></code>.
|
|
</li></ul>
|
|
<ul class="items"><li>(b) Material from the Inform 6 template is assimilated into inter code in
|
|
the "template module", which is <code class="display"><span class="extract">/main/template</span></code>.
|
|
</li></ul>
|
|
<ul class="items"><li>(c) Each extension is a compilation module, including of course the Standard
|
|
Rules, which is <code class="display"><span class="extract">/main/standard_rules</span></code>. Subsequent extensions have
|
|
longer names, such as <code class="display"><span class="extract">/main/locksmith_by_emily_short</span></code>.
|
|
</li></ul>
|
|
<ul class="items"><li>(d) Material in the main source text is a single compilation module, and
|
|
goes into <code class="display"><span class="extract">/main/source_text</span></code>.
|
|
</li></ul>
|
|
<ul class="items"><li>(e) The "synoptic module" contains material which was synthesised from all
|
|
of the source material in the other modules, and which can't meaningfully
|
|
be localised. For example, a function at run-time which returns the default
|
|
value for a kind given its weak kind ID has to be synoptic, because its
|
|
definition will include references to every kind defined in the program.
|
|
Such a function doesn't belong to any one block of source text. The
|
|
package is <code class="display"><span class="extract">/main/synoptic</span></code>.
|
|
</li></ul>
|
|
<p class="inwebparagraph"><a id="SP4"></a><b>§4. </b>Except for the template module, which is necessarily more free-form,
|
|
each module package then contains some or all of a standard set of
|
|
subpackages (and nothing else). Suppose the module name is <code class="display"><span class="extract">M</span></code>. The
|
|
range of possible subpackages is:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">/main/M/actions</span>
|
|
<span class="plain">/main/M/activities</span>
|
|
<span class="plain">/main/M/adjectives</span>
|
|
<span class="plain">/main/M/chronology</span>
|
|
<span class="plain">/main/M/conjugations</span>
|
|
<span class="plain">/main/M/equations</span>
|
|
<span class="plain">/main/M/extensions</span>
|
|
<span class="plain">/main/M/functions</span>
|
|
<span class="plain">/main/M/grammar</span>
|
|
<span class="plain">/main/M/instances</span>
|
|
<span class="plain">/main/M/kinds</span>
|
|
<span class="plain">/main/M/listing</span>
|
|
<span class="plain">/main/M/phrases</span>
|
|
<span class="plain">/main/M/properties</span>
|
|
<span class="plain">/main/M/relations</span>
|
|
<span class="plain">/main/M/rulebooks</span>
|
|
<span class="plain">/main/M/rules</span>
|
|
<span class="plain">/main/M/tables</span>
|
|
<span class="plain">/main/M/variables</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP5"></a><b>§5. Function packages. </b>All functions compiled by Inform 7 are expressed in inter code by packages
|
|
of type <code class="display"><span class="extract">_function</span></code>. The only externally visible symbol is <code class="display"><span class="extract">call</span></code>, which is
|
|
what is invoked. For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">symbol X --> /main/kinds/kind_6/gpr_fn/call</span>
|
|
<span class="plain">...</span>
|
|
<span class="plain"> inv X</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">invokes the function defined by the package:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">/main/kinds/kind_6/gpr_fn</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">(Inform conventionally uses names ending in <code class="display"><span class="extract">_fn</span></code> for function packages.)
|
|
Functions assimilated from template files are almost exactly similar,
|
|
except that rather than <code class="display"><span class="extract">call</span></code> the call symbol has the name of the original
|
|
template function. For example, <code class="display"><span class="extract">RELATION_TY_Distinguish</span></code> is assimilated as:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">/template/functions/RELATION_TY_Distinguish_fn/RELATION_TY_Distinguish</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">It is possible for function packages to avoid defining any actual code, by
|
|
defining <code class="display"><span class="extract">call</span></code> as an alias for a routine which we'll simply have to assume
|
|
will be present at eventual compile time. For example:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">package print_fn _function</span>
|
|
<span class="plain"> symbol public misc call `REAL_NUMBER_TY_Say`</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">More often, however, and always for functions derived from Inform 7 source
|
|
text, the package contains a code subpackage, and then defines <code class="display"><span class="extract">call</span></code> to
|
|
be that code package:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">package gpr_fn _function</span>
|
|
<span class="plain"> package code_block_1 _code</span>
|
|
<span class="plain"> ...</span>
|
|
<span class="plain"> constant call K_phrase_nothing____nothing = code_block_1</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">In fact, though, the package can be much more elaborate. If the code needs
|
|
to manipulate or refer to data not expressible in single words, such as
|
|
lists or texts, then it will probably need to create and subsequently destroy
|
|
a stack frame. The mechanism will then be:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">package gpr_fn _function</span>
|
|
<span class="plain"> package code_block_1 _code</span>
|
|
<span class="plain"> ...</span>
|
|
<span class="plain"> constant kernel K_phrase_nothing____nothing = code_block_1</span>
|
|
<span class="plain"> package code_block_2 _code</span>
|
|
<span class="plain"> ...</span>
|
|
<span class="plain"> constant call K_phrase_nothing____nothing = code_block_2</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">The "shell" routine of code, the one receiving the <code class="display"><span class="extract">call</span></code>, creates a stack
|
|
fram and then calls the "kernel" routine, which does the actual work; when
|
|
that returns to the "shell", the stack frame is disposed of again.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Function packages will also contain definitions of any static data they
|
|
need: for example, if an Inform 7 phrase contains a reference to the
|
|
constant <code class="display"><span class="extract">{ 1 , 2 , 3 }</span></code> then a function package for it will define a
|
|
constant with a name such as <code class="display"><span class="extract">block_constant_1</span></code>. In short, as far as
|
|
possible, function packages are self-contained.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<hr class="tocbar">
|
|
<ul class="toc"><li><a href="P-ia.html">Back to 'Inform Annotations'</a></li><li><a href="P-pas.html">Continue with 'Pipelines and Stages'</a></li></ul><hr class="tocbar">
|
|
<!--End of weave-->
|
|
</body>
|
|
</html>
|
|
|