ifhub/inform7
1
0
Fork 0
mirror of https://github.com/ganelson/inform.git synced 2024-07-05 16:44:21 +03:00
Code Issues Projects Releases Wiki Activity
inform7/docs/bytecode-module/P-wtmd.html
Graham Nelson 3ea9ce725f Second attempt to reconcile links
2022-04-28 17:37:28 +01:00

601 lines
55 KiB
HTML
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>What This Module Does</title>
<link href="../docs-assets/Breadcrumbs.css" rel="stylesheet" rev="stylesheet" type="text/css">
<meta name="viewport" content="width=device-width initial-scale=1">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta http-equiv="Content-Language" content="en-gb">
<link href="../docs-assets/Contents.css" rel="stylesheet" rev="stylesheet" type="text/css">
<link href="../docs-assets/Progress.css" rel="stylesheet" rev="stylesheet" type="text/css">
<link href="../docs-assets/Navigation.css" rel="stylesheet" rev="stylesheet" type="text/css">
<link href="../docs-assets/Fonts.css" rel="stylesheet" rev="stylesheet" type="text/css">
<link href="../docs-assets/Base.css" rel="stylesheet" rev="stylesheet" type="text/css">
<script src="http://code.jquery.com/jquery-1.12.4.min.js"
integrity="sha256-ZosEbRLbNQzLpnKIkEdrPv7lOy9C27hHQ+Xp8a4MxAQ=" crossorigin="anonymous"></script>
<script src="../docs-assets/Bigfoot.js"></script>
<link href="../docs-assets/Bigfoot.css" rel="stylesheet" rev="stylesheet" type="text/css">
<link href="../docs-assets/Colours.css" rel="stylesheet" rev="stylesheet" type="text/css">
</head>
<body class="commentary-font">
<nav role="navigation">
<h1><a href="../index.html">
<img src="../docs-assets/Inform.png" height=72">
</a></h1>
<ul><li><a href="../index.html">home</a></li>
</ul><h2>Compiler</h2><ul>
<li><a href="../structure.html">structure</a></li>
<li><a href="../inbuildn.html">inbuild</a></li>
<li><a href="../inform7n.html">inform7</a></li>
<li><a href="../intern.html">inter</a></li>
<li><a href="../services.html">services</a></li>
<li><a href="../secrets.html">secrets</a></li>
</ul><h2>Other Tools</h2><ul>
<li><a href="../inblorbn.html">inblorb</a></li>
<li><a href="../indocn.html">indoc</a></li>
<li><a href="../inform6.html">inform6</a></li>
<li><a href="../inpolicyn.html">inpolicy</a></li>
<li><a href="../inrtpsn.html">inrtps</a></li>
</ul><h2>Resources</h2><ul>
<li><a href="../extensions.html">extensions</a></li>
<li><a href="../kits.html">kits</a></li>
</ul><h2>Repository</h2><ul>
<li><a href="https://github.com/ganelson/inform"><img src="../docs-assets/github.png" height=18> github</a></li>
</ul><h2>Related Projects</h2><ul>
<li><a href="../../../inweb/index.html">inweb</a></li>
<li><a href="../../../intest/index.html">intest</a></li>
</ul>
</nav>
<main role="main">
<!--Weave of 'What This Module Does' generated by Inweb-->
<div class="breadcrumbs">
<ul class="crumbs"><li><a href="../index.html">Home</a></li><li><a href="../intern.html">Inter Modules</a></li><li><a href="index.html">bytecode</a></li><li><a href="index.html#P">Preliminaries</a></li><li><b>What This Module Does</b></li></ul></div>
<p class="purpose">An overview of the bytecode module's role and abilities.</p>
<ul class="toc"><li><a href="P-wtmd.html#SP1">&#167;1. Prerequisites</a></li><li><a href="P-wtmd.html#SP2">&#167;2. What is intermediate about inter</a></li><li><a href="P-wtmd.html#SP3">&#167;3. Textual, Binary, Memory</a></li><li><a href="P-wtmd.html#SP4">&#167;4. What textual Inter looks like</a></li><li><a href="P-wtmd.html#SP5">&#167;5. What binary Inter looks like</a></li><li><a href="P-wtmd.html#SP6">&#167;6. Data and types stored within bytecode</a></li><li><a href="P-wtmd.html#SP8">&#167;8. Symbols</a></li><li><a href="P-wtmd.html#SP9">&#167;9. What memory Inter looks like</a></li><li><a href="P-wtmd.html#SP10">&#167;10. Nodes and instructions</a></li><li><a href="P-wtmd.html#SP12">&#167;12. Wiring</a></li></ul><hr class="tocbar">
<p class="commentary firstcommentary"><a id="SP1" class="paragraph-anchor"></a><b>&#167;1. Prerequisites. </b>The bytecode module is a part of the Inform compiler toolset. It is
presented as a literate program or "web". Before diving in:
</p>
<ul class="items"><li>(a) It helps to have some experience of reading webs: see <a href="../../../inweb/index.html" class="internal">inweb</a> for more.
</li><li>(b) The module is written in C, in fact ANSI C99, but this is disguised by the
fact that it uses some extension syntaxes provided by the <a href="../../../inweb/index.html" class="internal">inweb</a> literate
programming tool, making it a dialect of C called InC. See <a href="../../../inweb/index.html" class="internal">inweb</a> for
full details, but essentially: it's C without predeclarations or header files,
and where functions have names like <span class="extract"><span class="extract-syntax">Tags::add_by_name</span></span> rather than just <span class="extract"><span class="extract-syntax">add_by_name</span></span>.
</li><li>(c) This module uses other modules drawn from the compiler (see <a href="../structure.html" class="internal">structure</a>), and also
uses a module of utility functions called <a href="../../../inweb/foundation-module/index.html" class="internal">foundation</a>.
For more, see <a href="../../../inweb/foundation-module/P-abgtf.html" class="internal">A Brief Guide to Foundation (in foundation)</a>.
</li></ul>
<p class="commentary firstcommentary"><a id="SP2" class="paragraph-anchor"></a><b>&#167;2. What is intermediate about inter. </b>This module is concerned with managing the <a href="2-it.html#SP1" class="internal">inter_tree</a> data structure in
memory, and with reading and writing it from and to the filing system.
</p>
<p class="commentary">An Inter tree is an expression of a single program. It's an intermediate state
between the source code for that program &mdash; perhaps Inform 7 source text,
perhaps Inform 6-syntax source for a kit &mdash; and the so-called "final" output,
typically a C or I6 program.
</p>
<p class="commentary">In conventional compiler design, a high-level language such as Swift or C# is
parsed first into an abstract syntax tree, or "AST", which is essentially a tree
representation of the syntax but is marked up with semantic information about
what everything in it means. This AST is then compiled down to an intermediate
representation, an "IR", which is a sort of structured list of still-abstract
operations to perform. The IR is then further converted to produce the compiler's
actual output. Thus:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> </span><span class="element-syntax">source</span><span class="plain-syntax"> ----&gt; </span><span class="function-syntax">AST</span><span class="plain-syntax"> ------------&gt; </span><span class="function-syntax">IR</span><span class="plain-syntax"> ----&gt; </span><span class="element-syntax">output</span><span class="plain-syntax"> (</span><span class="element-syntax">e</span><span class="plain-syntax">.</span><span class="element-syntax">g</span><span class="plain-syntax">., </span><span class="element-syntax">assembly</span><span class="plain-syntax"> </span><span class="element-syntax">language</span><span class="plain-syntax">)</span>
</pre>
<p class="commentary">In the Inform family of tools, two languages have to be compiled: natural
language by <a href="../inform7/index.html" class="internal">inform7</a> and more conventional C-like code by <a href="../inter/index.html" class="internal">inter</a>.
Having very different syntaxes, these have different ASTs:
</p>
<ul class="items"><li>&#9679; For I7, a <span class="extract"><span class="extract-syntax">parse_node_tree</span></span>, managed by the <a href="../syntax-module/index.html" class="internal">syntax</a> module.
</li><li>&#9679; For Inter, an <span class="extract"><span class="extract-syntax">inter_schema</span></span>, managed by the <a href="../building-module/index.html" class="internal">building</a> module.
</li></ul>
<p class="commentary">But these two compiler flows share the same IR &mdash; an <a href="2-it.html#SP1" class="internal">inter_tree</a> provides the
intermediate representation for both:<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> "</span><span class="function-syntax">AST</span><span class="plain-syntax">" "</span><span class="function-syntax">IR</span><span class="plain-syntax">"</span>
<span class="plain-syntax"> </span><span class="element-syntax">source</span><span class="plain-syntax"> </span><span class="element-syntax">syntax</span>
<span class="plain-syntax"> </span><span class="element-syntax">text</span><span class="plain-syntax"> ---&gt; </span><span class="element-syntax">tree</span><span class="plain-syntax"> -------+</span>
<span class="plain-syntax"> </span><span class="function-syntax">INFORM7</span><span class="plain-syntax"> \</span>
<span class="plain-syntax"> \</span>
<span class="plain-syntax"> ----&gt; </span><span class="element-syntax">Inter</span><span class="plain-syntax"> ----&gt; </span><span class="element-syntax">output</span><span class="plain-syntax"> (</span><span class="element-syntax">e</span><span class="plain-syntax">.</span><span class="element-syntax">g</span><span class="plain-syntax">., </span><span class="element-syntax">C</span><span class="plain-syntax"> </span><span class="element-syntax">or</span><span class="plain-syntax"> </span><span class="element-syntax">Inform</span><span class="plain-syntax"> </span><span class="constant-syntax">6</span><span class="plain-syntax"> </span><span class="element-syntax">code</span><span class="plain-syntax">)</span>
<span class="plain-syntax"> / </span><span class="element-syntax">tree</span>
<span class="plain-syntax"> </span><span class="element-syntax">kit</span><span class="plain-syntax"> </span><span class="element-syntax">Inter</span><span class="plain-syntax"> /</span>
<span class="plain-syntax"> </span><span class="element-syntax">source</span><span class="plain-syntax"> ---&gt; </span><span class="element-syntax">schemas</span><span class="plain-syntax"> -----+</span>
<span class="plain-syntax"> </span><span class="function-syntax">INTER</span>
</pre>
<p class="commentary">Because we want to work with hybrid programs, part compiled by one flow and
part by the other, Inter is not quite as low-level as most IRs.<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup> It still
contains a great deal of semantic markup, making analysis and optimisation
feasible. (Not very much of this is actually done at present, but see e.g.
<a href="../pipeline-module/6-eros.html" class="internal">Eliminate Redundant Operations Stage (in pipeline)</a>.)
</p>
<ul class="footnotetexts"><li class="footnote" id="fn:1"><p class="inwebfootnote"><sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup> In fact Inter schemas are so useful as a tool for generating short runs of
Inter that the main <a href="../inform7/index.html" class="internal">inform7</a> compiler also uses them from time to time, but
not directly to represent the source text.
<a href="#fnref:1" title="return to text"> &#x21A9;</a></p></li><li class="footnote" id="fn:2"><p class="inwebfootnote"><sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup> Though IRs vary considerably. Microsoft's Common Intermediate Language (CIL),
used as a back-end by C#, has quite low-level bytecode but stores it in a
highly structured object-oriented way.
<a href="#fnref:2" title="return to text"> &#x21A9;</a></p></li></ul>
<p class="commentary firstcommentary"><a id="SP3" class="paragraph-anchor"></a><b>&#167;3. Textual, Binary, Memory. </b>Inter code has three representations: as a binary file, as a textual file,
and in memory &mdash; a sort of cross-referenced form of binary. Binary or
textual inter files can be read in as memory inter, and memory inter can
be written out as either binary or textual files. Any inter program can
faithfully be represented in any of these forms:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> </span><span class="element-syntax">textual</span><span class="plain-syntax"> </span><span class="element-syntax">textual</span>
<span class="plain-syntax"> </span><span class="element-syntax">inter</span><span class="plain-syntax"> ---+ +---&gt; </span><span class="element-syntax">inter</span>
<span class="plain-syntax"> \ /</span>
<span class="plain-syntax"> \ /</span>
<span class="plain-syntax"> ----&gt; </span><span class="element-syntax">memory</span><span class="plain-syntax"> ----</span>
<span class="plain-syntax"> / </span><span class="element-syntax">inter</span><span class="plain-syntax"> \</span>
<span class="plain-syntax"> </span><span class="element-syntax">binary</span><span class="plain-syntax"> / \ </span><span class="element-syntax">binary</span>
<span class="plain-syntax"> </span><span class="element-syntax">inter</span><span class="plain-syntax"> ---+ +---&gt; </span><span class="element-syntax">inter</span>
</pre>
<p class="commentary">Textual Inter is human-readable, but binary Inter loads quickly. Either form,
as stored on an external file whose provenance we do not know, has to be treated
as suspect:
</p>
<ul class="items"><li>&#9679; Textual Inter might have been written by a human who blundered.
</li><li>&#9679; Binary Inter might have been wrongly constructed by some compiler with
a bug in it.
</li><li>&#9679; Binary Inter might have been maliciously constructed to crash us.
</li><li>&#9679; Either form might be left over from a previous version of the Inform tool
chain when the specification of the Inter language was slightly different.
</li></ul>
<p class="commentary">So we go to some trouble to verify the syntactic correctness of what is read
in, and use a shared system of <a href="3-ie.html" class="internal">Inter Errors</a> to report defects. All binary
Inter files are marked with an explicit version number for the version of Inter
they were constructed by. Textual Inter files can also be so marked, but this is
optional, because there is a good chance the textual syntax will not have been
changed. See <a href="1-tiv.html" class="internal">The Inter Version</a>.
</p>
<p class="commentary firstcommentary"><a id="SP4" class="paragraph-anchor"></a><b>&#167;4. What textual Inter looks like. </b>There is a manual for writing <a href="../inter/M-ti.html" class="internal">Textual Inter (in inter)</a>, and this may now be
worth skimming through. But here is a minimal example:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="reserved-syntax">package</span><span class="plain-syntax"> main _plain</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">package</span><span class="plain-syntax"> Main _code</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">code</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">inv</span><span class="plain-syntax"> </span><span class="function-syntax">!enableprinting</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">inv</span><span class="plain-syntax"> </span><span class="function-syntax">!print</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">val</span><span class="plain-syntax"> </span><span class="string-syntax">"Hello, world.\n"</span>
</pre>
<p class="commentary">If we read this in and then write it out again, we find, perhaps surprisingly,
four extra instructions:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="reserved-syntax">packagetype</span><span class="plain-syntax"> _plain</span>
<span class="reserved-syntax">packagetype</span><span class="plain-syntax"> _code</span>
<span class="reserved-syntax">primitive</span><span class="plain-syntax"> </span><span class="function-syntax">!enableprinting</span><span class="plain-syntax"> </span><span class="reserved-syntax">void</span><span class="plain-syntax"> -&gt; </span><span class="reserved-syntax">void</span>
<span class="reserved-syntax">primitive</span><span class="plain-syntax"> </span><span class="function-syntax">!print</span><span class="plain-syntax"> </span><span class="reserved-syntax">val</span><span class="plain-syntax"> -&gt; </span><span class="reserved-syntax">void</span>
<span class="reserved-syntax">package</span><span class="plain-syntax"> main _plain</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">package</span><span class="plain-syntax"> Main _code</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">code</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">inv</span><span class="plain-syntax"> </span><span class="function-syntax">!enableprinting</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">inv</span><span class="plain-syntax"> </span><span class="function-syntax">!print</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">val</span><span class="plain-syntax"> </span><span class="string-syntax">"Hello, world.\n"</span>
</pre>
<p class="commentary">This is because <span class="extract"><span class="extract-syntax">packagetype</span></span> and <span class="extract"><span class="extract-syntax">primitive</span></span> instructions are optional in textual
Inter. When we read <span class="extract"><span class="extract-syntax">package Main _code</span></span>, for example, we deduce that a <span class="extract"><span class="extract-syntax">_code</span></span>
package type is needed, and so we automatically declare it if it is not there
already; and similarly for any primitive like <span class="extract"><span class="extract-syntax">!enableprinting</span></span>, provided that
it is one of those in the standard set. (See <a href="../building-module/1-ip.html" class="internal">Inter Primitives (in building)</a>.)
Nevertheless, those instructions are part of the program, which is why they
are printed out when we write it back as textual Inter.
</p>
<p class="commentary"><span class="extract"><span class="extract-syntax">packagetype</span></span>, <span class="extract"><span class="extract-syntax">primitive</span></span>, <span class="extract"><span class="extract-syntax">package</span></span>, <span class="extract"><span class="extract-syntax">code</span></span>, <span class="extract"><span class="extract-syntax">inv</span></span> and so on are all examples
of <a href="3-ic.html" class="internal">Inter Constructs</a>. Each has its own textual syntax. Most constructs give
rise to instructions &mdash; for example, every line using the <span class="extract"><span class="extract-syntax">val</span></span> construct
results in a single <span class="extract"><span class="extract-syntax">VAL_IST</span></span> instruction in the program &mdash; but just a few
"pseudo-constructs" such as <span class="extract"><span class="extract-syntax">version</span></span> specify something else.
</p>
<p class="commentary">So it is not true that lines in textual Inter correspond exactly to the
instructions in a program, but it's very nearly true.
</p>
<p class="commentary firstcommentary"><a id="SP5" class="paragraph-anchor"></a><b>&#167;5. What binary Inter looks like. </b>The "hello world" program above would occupy a single <a href="2-it.html#SP1" class="internal">inter_tree</a> once loaded
in to memory.
</p>
<p class="commentary">The main organising idea of Inter trees is the <a href="2-pck.html#SP2" class="internal">inter_package</a>. <a href="2-pck.html" class="internal">Packages</a> are
like nested boxes: each one can hold either more packages, or Inter instructions
providing code or data, or both. In the case of "hello world":
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax">....................................................</span>
<span class="plain-syntax">. </span><span class="element-syntax">top</span><span class="plain-syntax">-</span><span class="element-syntax">level</span><span class="plain-syntax"> </span><span class="element-syntax">material</span><span class="plain-syntax"> .</span>
<span class="plain-syntax">. +--------------------------------------------+ .</span>
<span class="plain-syntax">. | /</span><span class="element-syntax">main</span><span class="plain-syntax"> </span><span class="element-syntax">_plain</span><span class="plain-syntax"> | .</span>
<span class="plain-syntax">. | +-------------------------------------+ | .</span>
<span class="plain-syntax">. | | /</span><span class="element-syntax">main</span><span class="plain-syntax">/</span><span class="element-syntax">Main</span><span class="plain-syntax"> </span><span class="element-syntax">_code</span><span class="plain-syntax"> | | .</span>
<span class="plain-syntax">. | | </span><span class="element-syntax">code</span><span class="plain-syntax"> </span><span class="element-syntax">in</span><span class="plain-syntax"> </span><span class="element-syntax">the</span><span class="plain-syntax"> </span><span class="element-syntax">Main</span><span class="plain-syntax"> </span><span class="element-syntax">function</span><span class="plain-syntax"> | | .</span>
<span class="plain-syntax">. | +-------------------------------------+ | .</span>
<span class="plain-syntax">. +--------------------------------------------+ .</span>
<span class="plain-syntax">....................................................</span>
</pre>
<p class="commentary">Each package has a name, and its location can be identified by a "URL". For
example, <span class="extract"><span class="extract-syntax">/main/BasicInformKit/properties</span></span> means "the package <span class="extract"><span class="extract-syntax">properties</span></span>
inside the package <span class="extract"><span class="extract-syntax">BasicInformKit</span></span> inside the package <span class="extract"><span class="extract-syntax">main</span></span>". Every package
also as a "package type". (This is not the same thing as a data type.) <span class="extract"><span class="extract-syntax">main</span></span>
always has type <span class="extract"><span class="extract-syntax">_plain</span></span>; any package holding a function body has type <span class="extract"><span class="extract-syntax">_code</span></span>.
All package types begin with an underscore <span class="extract"><span class="extract-syntax">_</span></span>.
</p>
<p class="commentary">Material at the root level is implemented as if it were in a special package
called the "root package" (the dotted box around everything in the diagram),
which has the empty name and thus the URL <span class="extract"><span class="extract-syntax">/</span></span>. But this is not really a
package, and follows different rules from all others.
</p>
<p class="commentary">For the conventions on how the Inform tool-chain sets up this hierarchy of
packages, see the <a href="../building-module/index.html" class="internal">building</a> module: that's not our concern here. We
simply provide infrastructure allowing pretty general hierarchies to be made.
</p>
<p class="commentary firstcommentary"><a id="SP6" class="paragraph-anchor"></a><b>&#167;6. Data and types stored within bytecode. </b>Each instruction occupies a sequence of words called bytecode,<sup id="fnref:3"><a href="#fn:3" rel="footnote">3</a></sup> called its
"frame": see <a href="2-in.html" class="internal">Inter Nodes</a>. The opening word identifies which construct is
used: for example, if this is <span class="extract"><span class="extract-syntax">PACKAGE_IST</span></span> then the instruction is a <span class="extract"><span class="extract-syntax">package</span></span>.
What the remaining words mean depends on the construct, but here are some
typical ingredients:
</p>
<ul class="items"><li>&#9679; Many constructs &mdash; <span class="extract"><span class="extract-syntax">constant</span></span>, for example &mdash; define a new symbol.
If so, the symbol ID &mdash; or SID &mdash; will be stored in one of the words;
this is the ID of the symbol in the <a href="2-st.html#SP1" class="internal">inter_symbols_table</a> belonging
to the package containing the instruction. Some constructs also contain
SIDs for other reasons: for example, <span class="extract"><span class="extract-syntax">propertyvalue</span></span> needs to store the
SID of the property whose value is being recorded.
</li><li>&#9679; Values in Inter occupy two consecutive words of bytecode, and these
are called "pairs": see <a href="3-ivp.html" class="internal">Inter Value Pairs</a>.
</li><li>&#9679; Some constructs also need to store a type ID, or TID. See <a href="3-idt.html" class="internal">Inter Data Types</a>.
</li></ul>
<p class="commentary">With both values and types, we need to be able to express an enormous range
of possibilities. This seems impossible. For example, how can we fit the list
<span class="extract"><span class="extract-syntax">{2, 3, 5, 7, 11, 13, 17, 19}</span></span> in two words, or the type <span class="extract"><span class="extract-syntax">function int32 int2 -&gt; void</span></span>
in just one?
</p>
<p class="commentary">In both cases the solution is the same: to use <span class="extract"><span class="extract-syntax">constant</span></span> or <span class="extract"><span class="extract-syntax">typename</span></span> to
assign a symbol to anything complicated, and then refer to that symbol. For
example, we can't have this:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> </span><span class="reserved-syntax">val</span><span class="plain-syntax"> (</span><span class="reserved-syntax">list</span><span class="plain-syntax"> </span><span class="reserved-syntax">of</span><span class="plain-syntax"> </span><span class="reserved-syntax">int32</span><span class="plain-syntax">) { </span><span class="constant-syntax">2</span><span class="plain-syntax">, </span><span class="constant-syntax">3</span><span class="plain-syntax">, </span><span class="constant-syntax">5</span><span class="plain-syntax">, </span><span class="constant-syntax">7</span><span class="plain-syntax">, </span><span class="constant-syntax">11</span><span class="plain-syntax">, </span><span class="constant-syntax">13</span><span class="plain-syntax">, </span><span class="constant-syntax">17</span><span class="plain-syntax">, </span><span class="constant-syntax">19</span><span class="plain-syntax"> }</span>
</pre>
<p class="commentary">because both the type and the value are too complicated. But we can have:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> typename list_of_integers = </span><span class="reserved-syntax">list</span><span class="plain-syntax"> </span><span class="reserved-syntax">of</span><span class="plain-syntax"> </span><span class="reserved-syntax">int32</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">constant</span><span class="plain-syntax"> (list_of_integers) primes = { </span><span class="constant-syntax">2</span><span class="plain-syntax">, </span><span class="constant-syntax">3</span><span class="plain-syntax">, </span><span class="constant-syntax">5</span><span class="plain-syntax">, </span><span class="constant-syntax">7</span><span class="plain-syntax">, </span><span class="constant-syntax">11</span><span class="plain-syntax">, </span><span class="constant-syntax">13</span><span class="plain-syntax">, </span><span class="constant-syntax">17</span><span class="plain-syntax">, </span><span class="constant-syntax">19</span><span class="plain-syntax"> }</span>
<span class="plain-syntax"> ...</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">val</span><span class="plain-syntax"> (list_of_integers) primes</span>
</pre>
<ul class="footnotetexts"><li class="footnote" id="fn:3"><p class="inwebfootnote"><sup id="fnref:3"><a href="#fn:3" rel="footnote">3</a></sup> The term "bytecode" is a misnomer, since this is word-based, not byte-based.
But it is traditional and seems to have been used as far back as the mid-1960s.
<a href="#fnref:3" title="return to text"> &#x21A9;</a></p></li></ul>
<p class="commentary firstcommentary"><a id="SP7" class="paragraph-anchor"></a><b>&#167;7. </b>Constants are useful also for providing metadata about the program. This
is not simply commentary: what makes it "meta" is that it does not literally
compile into the final output. For example:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> </span><span class="reserved-syntax">constant</span><span class="plain-syntax"> lucky_number = </span><span class="constant-syntax">7</span>
<span class="plain-syntax"> </span><span class="reserved-syntax">constant</span><span class="plain-syntax"> ^special_constant = lucky_number</span>
</pre>
<p class="commentary">Here <span class="extract"><span class="extract-syntax">lucky_number</span></span> can be used in the program whenever a value is needed. But
<span class="extract"><span class="extract-syntax">^special_constant</span></span>, whose name begins with the magic metadata caret <span class="extract"><span class="extract-syntax">^</span></span>, cannot
be used as a value. Instead, the idea is that it communicates something to the
code-generation code in <a href="../pipeline-module/index.html" class="internal">pipeline</a> and <a href="../final-module/index.html" class="internal">final</a> &mdash; indicating the significance,
purpose or origins of something in the program. (<a href="../inform7/index.html" class="internal">inform7</a> produces a lot
of metadata like this.)
</p>
<p class="commentary">See <a href="3-mtd.html" class="internal">Metadata</a> for functions to access this metadata.
</p>
<p class="commentary firstcommentary"><a id="SP8" class="paragraph-anchor"></a><b>&#167;8. Symbols. </b>Names of constants, packages, primitives and so on are all examples of "symbols".
</p>
<p class="commentary">Packages provide <a href="2-st.html" class="internal">Symbols Tables</a>: in fact, each package has its own symbols
table, recording symbols and their meanings within that package. For example,
if a package <span class="extract"><span class="extract-syntax">X</span></span> contains a definition of a constant called <span class="extract"><span class="extract-syntax">pi</span></span>, then the
definition will occupy an Inter instruction inside the package, and the
identifier name <span class="extract"><span class="extract-syntax">pi</span></span> will be an <a href="2-sym.html#SP1" class="internal">inter_symbol</a> recorded in its <a href="2-st.html#SP1" class="internal">inter_symbols_table</a>.
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> +-----------------+</span>
<span class="plain-syntax"> | </span><span class="element-syntax">Package</span><span class="plain-syntax"> </span><span class="element-syntax">X</span><span class="plain-syntax"> |</span>
<span class="plain-syntax"> | |</span>
<span class="plain-syntax"> | </span><span class="element-syntax">pi</span><span class="plain-syntax"> |</span>
<span class="plain-syntax"> | ..... |</span>
<span class="plain-syntax"> | </span><span class="element-syntax">constant</span><span class="plain-syntax"> </span><span class="element-syntax">pi</span><span class="plain-syntax"> = </span><span class="constant-syntax">3</span><span class="plain-syntax"> |</span>
<span class="plain-syntax"> +-----------------+</span>
</pre>
<p class="commentary">The symbols table for the root package is special, and represents global
meanings accessible everywhere. But they are used only for concepts needed
by Inter itself, such as the identities of primitives like <span class="extract"><span class="extract-syntax">!add</span></span> or
<span class="extract"><span class="extract-syntax">!printnumber</span></span>. In some sense, they specify the kind of Inter tree we have,
rather than anything about the program it represents. Material from that
program &mdash; a variable, say, or a function &mdash; is not allowed at the root level.
</p>
<p class="commentary">Symbols can be annotated in various ways. See <a href="2-ann.html" class="internal">Annotations</a>. They also come
in several types, see <a href="2-sym.html#SP5" class="internal">InterSymbol::get_type</a>, and can have a few flags,
see <a href="2-sym.html#SP6" class="internal">InterSymbol::get_flag</a>.
</p>
<p class="commentary firstcommentary"><a id="SP9" class="paragraph-anchor"></a><b>&#167;9. What memory Inter looks like. </b>Inter code stored in memory is not simply a binary copy of what the same thing
would be if stored in a binary Inter file: it is very heavily cross-referenced
for rapid access, editing and rearrangement.
</p>
<p class="commentary">There is a lot of memory to be managed here: Inter trees can be huge, though
there are never more than one or two in memory at once.
</p>
<p class="commentary">In particular, each <a href="2-it.html#SP1" class="internal">inter_tree</a> structure contains two pools of data
besides the actual tree:<sup id="fnref:4"><a href="#fn:4" rel="footnote">4</a></sup>
</p>
<ul class="items"><li>(a) A "building site", which contains workspace data needed by the <a href="../building-module/index.html" class="internal">building</a>
module. <a href="../building-module/index.html" class="internal">building</a> is essentially a piece of middleware sitting on top of
this one, and making it easier for the compilers to use our facilities. We
will ignore the building site completely here: it's not our problem.
</li><li>(b) A "warehouse", which very much is our problem: see <a href="2-tw.html" class="internal">The Warehouse</a>.
This provides storage for strings, symbols tables and the like, assigning each
one an ID number. Resource number 178, for example, might be a <span class="extract"><span class="extract-syntax">text_stream</span></span>
which is the content of some text literal in a function, while 179 might be
an <a href="2-st.html#SP1" class="internal">inter_symbols_table</a> belonging to some package.
</li></ul>
<ul class="footnotetexts"><li class="footnote" id="fn:4"><p class="inwebfootnote"><sup id="fnref:4"><a href="#fn:4" rel="footnote">4</a></sup> In real-life botany, trees do not have building sites or warehouses, but
mixing some metaphors cannot really be helped. Trees in nature do not grow
the way they do in computer science.
<a href="#fnref:4" title="return to text"> &#x21A9;</a></p></li></ul>
<p class="commentary firstcommentary"><a id="SP10" class="paragraph-anchor"></a><b>&#167;10. Nodes and instructions. </b>Each node in an Inter tree represents a single Inter instruction,<sup id="fnref:5"><a href="#fn:5" rel="footnote">5</a></sup> details of
which are stored as a stretch of bytecode in memory.
</p>
<p class="commentary">This use of both a tree and also a mass of binary bytecode is an attempt to
have our cake and eat it. The tree structure makes it quick and easy to splice,
cut and reorder code; the binary bytecode storage is quick to load from a file.
Still, the result is an unusual hybrid of a data structure.
</p>
<p class="commentary">For example, the tree might start out like this:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> ... </span><span class="constant-syntax">102</span><span class="plain-syntax"> </span><span class="constant-syntax">103</span><span class="plain-syntax"> </span><span class="constant-syntax">104</span><span class="plain-syntax"> </span><span class="constant-syntax">105</span><span class="plain-syntax"> </span><span class="constant-syntax">106</span><span class="plain-syntax"> </span><span class="constant-syntax">107</span><span class="plain-syntax"> </span><span class="constant-syntax">108</span><span class="plain-syntax"> </span><span class="constant-syntax">109</span><span class="plain-syntax"> ...</span>
<span class="plain-syntax"> </span><span class="element-syntax">node1</span><span class="plain-syntax"> -----------------------&gt; [.........]</span>
<span class="plain-syntax"> </span><span class="element-syntax">node2</span><span class="plain-syntax"> -------------------------------&gt; [.....]</span>
<span class="plain-syntax"> </span><span class="element-syntax">node3</span><span class="plain-syntax"> ---------------------------------------&gt; [.........]</span>
</pre>
<p class="commentary">Here <span class="extract"><span class="extract-syntax">node1</span></span> represents an instruction, with the details stored at bytecode
locations 103 to 105; <span class="extract"><span class="extract-syntax">node2</span></span> points to bytecode at 106 to 107, and so on.
But then we could decide, when optimising code, that we want instructions
<span class="extract"><span class="extract-syntax">node2</span></span> and <span class="extract"><span class="extract-syntax">node3</span></span> performed the other way round. Simple amendments to
the tree structure achieve this without needing to edit the bytecode:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> ... </span><span class="constant-syntax">102</span><span class="plain-syntax"> </span><span class="constant-syntax">103</span><span class="plain-syntax"> </span><span class="constant-syntax">104</span><span class="plain-syntax"> </span><span class="constant-syntax">105</span><span class="plain-syntax"> </span><span class="constant-syntax">106</span><span class="plain-syntax"> </span><span class="constant-syntax">107</span><span class="plain-syntax"> </span><span class="constant-syntax">108</span><span class="plain-syntax"> </span><span class="constant-syntax">109</span><span class="plain-syntax"> ...</span>
<span class="plain-syntax"> </span><span class="element-syntax">node1</span><span class="plain-syntax"> -----------------------&gt; [.........]</span>
<span class="plain-syntax"> </span><span class="element-syntax">node3</span><span class="plain-syntax"> ---------------------------------------&gt; [.........]</span>
<span class="plain-syntax"> </span><span class="element-syntax">node2</span><span class="plain-syntax"> -------------------------------&gt; [.....]</span>
</pre>
<p class="commentary">Indeed, we could decide that the instruction at <span class="extract"><span class="extract-syntax">node2</span></span> is redundant and cut it:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> ... 102 103 104 105 106 107 108 109 ...</span>
<span class="plain-syntax"> node1 -----------------------&gt; [.........]</span>
<span class="plain-syntax"> node3 ---------------------------------------&gt; [.........]</span>
</pre>
<p class="commentary">It doesn't matter that the resulting bytecode storage is all mixed up in
sequencing; the tree is what gives us the sequence of instructions, and the
order of words in bytecode memory is only significant within a single
instruction.
</p>
<ul class="footnotetexts"><li class="footnote" id="fn:5"><p class="inwebfootnote"><sup id="fnref:5"><a href="#fn:5" rel="footnote">5</a></sup> Well, except for the root node, which has no real meaning. But there is
only one of those.
<a href="#fnref:5" title="return to text"> &#x21A9;</a></p></li></ul>
<p class="commentary firstcommentary"><a id="SP11" class="paragraph-anchor"></a><b>&#167;11. </b>As these diagrams suggest, we can generate Inter instructions quite flexibly,
and are under no obligation to do so in sequence or all at once. (Indeed, we
can add entirely new instructions in the linking process or when optimising
code.)
</p>
<p class="commentary">So it is very useful to have a way to keep "bookmarks" in the tree, as positions
where we are currently writing code, and might want to return to. For this
purpose, we have the <a href="2-bkm.html#SP1" class="internal">inter_bookmark</a> type, which can represent any feasible
write position in the tree. (This is not the same thing as representing any
existing node in the tree: see <a href="2-bkm.html" class="internal">Bookmarks</a> for more.)
</p>
<p class="commentary">And this in turn allows for a simple API for <a href="2-np.html" class="internal">Node Placement</a>, allowing us
to move or remove nodes in the tree, and to keep track of cursor-like moving
bookmark positions when we generate a stream of new nodes and place them one
after another.
</p>
<p class="commentary firstcommentary"><a id="SP12" class="paragraph-anchor"></a><b>&#167;12. Wiring. </b>The bytecode in a package can only refer to resources using symbols in that
same package. On the face of it, that means packages are so well sealed up
that they might as well all be independent programs, unable to see each other's
variables, constants and functions.
</p>
<p class="commentary">But that is not true because symbols in one package can be "wired" to symbols
in another:<sup id="fnref:6"><a href="#fn:6" rel="footnote">6</a></sup> see <a href="2-tw2.html" class="internal">The Wiring</a>. We write <span class="extract"><span class="extract-syntax">S ~~&gt; T</span></span> if the symbol <span class="extract"><span class="extract-syntax">S</span></span> is "wired to"
<span class="extract"><span class="extract-syntax">T</span></span>, and we understand this as meaning that <span class="extract"><span class="extract-syntax">S</span></span> means whatever <span class="extract"><span class="extract-syntax">T</span></span> does.
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> +-----------------+ +-------------------------------+</span>
<span class="plain-syntax"> | </span><span class="element-syntax">Package</span><span class="plain-syntax"> </span><span class="element-syntax">X</span><span class="plain-syntax"> | | </span><span class="element-syntax">Package</span><span class="plain-syntax"> </span><span class="element-syntax">Y</span><span class="plain-syntax"> |</span>
<span class="plain-syntax"> | | | |</span>
<span class="plain-syntax"> | </span><span class="element-syntax">earth</span><span class="plain-syntax"> ~~~~~~~~~~~~~~~~~~~~&gt; </span><span class="element-syntax">earth</span><span class="plain-syntax"> |</span>
<span class="plain-syntax"> +-----------------+ | ..... |</span>
<span class="plain-syntax"> | </span><span class="element-syntax">variable</span><span class="plain-syntax"> </span><span class="element-syntax">earth</span><span class="plain-syntax"> = </span><span class="constant-syntax">7</span><span class="plain-syntax"> |</span>
<span class="plain-syntax"> +-------------------------------+</span>
</pre>
<p class="commentary">In this example, the symbol <span class="extract"><span class="extract-syntax">earth</span></span> in package <span class="extract"><span class="extract-syntax">X</span></span> is undefined. Instead it is
wired to a different symbol of the same name in package <span class="extract"><span class="extract-syntax">Y</span></span>, which is defined
as the name of a variable declared in that package. (The names do not have to
be the same, but they often are.)
</p>
<p class="commentary">Wiring is directional: <span class="extract"><span class="extract-syntax">S ~~&gt; T</span></span> very definitely does not mean that <span class="extract"><span class="extract-syntax">T ~~&gt; S</span></span>,
and indeed circuits are forbidden, because <span class="extract"><span class="extract-syntax">S1 ~~&gt; S2 ~~&gt; ... ~~&gt; S1</span></span> would
create a circular definition. To change metaphor for a moment, it's as if, on
looking up <span class="extract"><span class="extract-syntax">S</span></span> in the index of a book, we found the entry "<span class="extract"><span class="extract-syntax">S</span></span>, see <span class="extract"><span class="extract-syntax">T</span></span>": we
then have to look up <span class="extract"><span class="extract-syntax">T</span></span> to find, say, "<span class="extract"><span class="extract-syntax">T</span></span>, 125", and turn to page 125. It
would be no good to find instead "<span class="extract"><span class="extract-syntax">T</span></span>, see <span class="extract"><span class="extract-syntax">S</span></span>".
</p>
<ul class="footnotetexts"><li class="footnote" id="fn:6"><p class="inwebfootnote"><sup id="fnref:6"><a href="#fn:6" rel="footnote">6</a></sup> There are fleeting exceptional cases when a symbol can be wired to another
symbol in the same package, but those occur only with sockets and plugs in the
special connectors package, and only temporarily even then.
<a href="#fnref:6" title="return to text"> &#x21A9;</a></p></li></ul>
<p class="commentary firstcommentary"><a id="SP13" class="paragraph-anchor"></a><b>&#167;13. </b>Special symbols called plugs and sockets are used to import or export meanings
from one tree of Inter code to a potential other tree, which will be "linked"
into it later on.
</p>
<p class="commentary">For example, <a href="../inform7/index.html" class="internal">inform7</a> compiles a tree of Inter, but then <a href="../inter/index.html" class="internal">inter</a> links
this with a separately compiled Inter tree from <a href="../BasicInformKit/index.html" class="internal">BasicInformKit</a>. Each both
imports from and exports to the other.
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> ..................... .......................</span>
<span class="plain-syntax"> . </span><span class="element-syntax">Main</span><span class="plain-syntax"> </span><span class="element-syntax">tree</span><span class="plain-syntax"> . ~~~~~~~~&gt; . </span><span class="element-syntax">BasicInformKit</span><span class="plain-syntax"> </span><span class="element-syntax">tree</span><span class="plain-syntax"> .</span>
<span class="plain-syntax"> . . . .</span>
<span class="plain-syntax"> . . &lt;~~~~~~~~ . .</span>
<span class="plain-syntax"> ..................... .......................</span>
</pre>
<p class="commentary">It would be chaotic<sup id="fnref:7"><a href="#fn:7" rel="footnote">7</a></sup> to allow random symbols in packages all over each tree
to be wired directly to symbols in the other. Instead, every tree has a sort
of embassy package <span class="extract"><span class="extract-syntax">/main/connectors</span></span> (a package called <span class="extract"><span class="extract-syntax">connectors</span></span> which is
a subpackage of <span class="extract"><span class="extract-syntax">main</span></span>) which acts as an intermediary.
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> ............................... ..................................</span>
<span class="plain-syntax"> . </span><span class="element-syntax">Main</span><span class="plain-syntax"> </span><span class="element-syntax">tree</span><span class="plain-syntax"> . . </span><span class="element-syntax">BasicInformKit</span><span class="plain-syntax"> </span><span class="element-syntax">tree</span><span class="plain-syntax"> .</span>
<span class="plain-syntax"> . +------------+ . . +------------+ .</span>
<span class="plain-syntax"> . </span><span class="element-syntax">other</span><span class="plain-syntax"> | </span><span class="element-syntax">connectors</span><span class="plain-syntax"> | . . | </span><span class="element-syntax">connectors</span><span class="plain-syntax"> | .</span>
<span class="plain-syntax"> . </span><span class="element-syntax">packages</span><span class="plain-syntax"> ~~~~~~~&gt; </span><span class="element-syntax">plugs</span><span class="plain-syntax"> ~~~~~~~~~~~~~~&gt; </span><span class="element-syntax">sockets</span><span class="plain-syntax"> ~~~~~&gt; </span><span class="element-syntax">other</span><span class="plain-syntax"> .</span>
<span class="plain-syntax"> . &lt;~~~~ </span><span class="element-syntax">sockets</span><span class="plain-syntax"> &lt;~~~~~~~~~~~~~~ </span><span class="element-syntax">plugs</span><span class="plain-syntax"> &lt;~~~~~~~~~ </span><span class="element-syntax">packages</span><span class="plain-syntax"> .</span>
<span class="plain-syntax"> . +------------+ . . +------------+ .</span>
<span class="plain-syntax"> ............................... ..................................</span>
</pre>
<p class="commentary">The connectors package contains only symbols, and they are all either "plugs" or
"sockets". A "plug" is made for every external meaning needed by a tree; a
"socket" is made for each meaning that the tree declares itself but wants to
make available for other trees to access. So if you know the contents of the
connectors package of a tree, you know everything it needs from outside (plugs)
and everything it offers to the outside (sockets).
</p>
<p class="commentary">For further zany ASCII-art like this, see <a href="2-tw2.html" class="internal">The Wiring</a>.
</p>
<ul class="footnotetexts"><li class="footnote" id="fn:7"><p class="inwebfootnote"><sup id="fnref:7"><a href="#fn:7" rel="footnote">7</a></sup> And also slow, and prone to namespace collisions.
<a href="#fnref:7" title="return to text"> &#x21A9;</a></p></li></ul>
<p class="commentary firstcommentary"><a id="SP14" class="paragraph-anchor"></a><b>&#167;14. </b>It is not literally the case that plugs in one tree are wired to sockets in
another, as the diagram above suggests. The actual wiring-together occurs only
when (part of) one tree is merged into another, in what is called <a href="2-trn.html" class="internal">Transmigration</a>.
</p>
<p class="commentary">Transmigration is by definition the process of moving a package from one tree
to another. Almost the whole design of Inter is motivated by the need to make this
fast &mdash; the hierarchies of packages, the use of wiring, and the existence of sockets
and plugs all came about working backwards from the goal of implementing
transmigration efficiently.
</p>
<p class="commentary">Transmigration is how the <a href="../pipeline-module/index.html" class="internal">pipeline</a> for processing Inter links a tree
produced by <a href="../inform7/index.html" class="internal">inform7</a> to trees from kits produced by <a href="../inter/index.html" class="internal">inter</a>. This
diagram is also a little simplified, but the idea is right. We start with:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> ......................... .........................</span>
<span class="plain-syntax"> . </span><span class="element-syntax">Main</span><span class="plain-syntax"> </span><span class="element-syntax">tree</span><span class="plain-syntax"> . . </span><span class="element-syntax">BasicInformKit</span><span class="plain-syntax"> </span><span class="element-syntax">tree</span><span class="plain-syntax"> .</span>
<span class="plain-syntax"> . </span><span class="element-syntax">main</span><span class="plain-syntax"> . . </span><span class="element-syntax">main</span><span class="plain-syntax"> .</span>
<span class="plain-syntax"> . </span><span class="element-syntax">architectural</span><span class="plain-syntax"> . . </span><span class="element-syntax">architectural</span><span class="plain-syntax"> .</span>
<span class="plain-syntax"> . </span><span class="element-syntax">basic_inform</span><span class="plain-syntax"> . . </span><span class="element-syntax">BasicInformKit</span><span class="plain-syntax"> .</span>
<span class="plain-syntax"> . </span><span class="element-syntax">source_text</span><span class="plain-syntax"> . . </span><span class="element-syntax">connectors</span><span class="plain-syntax"> .</span>
<span class="plain-syntax"> . </span><span class="element-syntax">connectors</span><span class="plain-syntax"> . . .</span>
<span class="plain-syntax"> ......................... .........................</span>
</pre>
<p class="commentary">where all of the substantive content of the BasicInformKit tree is in its
package <span class="extract"><span class="extract-syntax">/main/BasicInformKit</span></span>. Transmigration simply moves that package,
the result being:
</p>
<pre class="displayed-code all-displayed-code code-font">
<span class="plain-syntax"> ......................... .........................</span>
<span class="plain-syntax"> . Main tree . . BasicInformKit tree .</span>
<span class="plain-syntax"> . main . . main .</span>
<span class="plain-syntax"> . architectural . . architectural .</span>
<span class="plain-syntax"> . basic_inform . . connectors .</span>
<span class="plain-syntax"> . source_text . . .</span>
<span class="plain-syntax"> . BasicInformKit . . .</span>
<span class="plain-syntax"> . connectors . . .</span>
<span class="plain-syntax"> ......................... .........................</span>
</pre>
<p class="commentary">The original BasicInformKit tree is reduced to a husk and can be discarded.
</p>
<p class="commentary">Plugs and sockets are important here because when BasicInformKit moves to the
main tree, its plugs looking for meanings in that tree can now be connected
to sockets in it; and conversely, plugs in the main tree hoping to connect
to meanings in BasicInformKit can now connect to the relevant sockets.
</p>
<p class="commentary">There are conventions on what goes in the <span class="extract"><span class="extract-syntax">main</span></span> package of each tree: see
<a href="../building-module/1-ls.html" class="internal">Large-Scale Structure (in building)</a> for more on that. (The <span class="extract"><span class="extract-syntax">architectural</span></span>
package in each tree just makes some definitions establishing the size of
integers, and so on, and for these two trees whose definitions will just be
duplicates of each other.)
</p>
<nav role="progress"><div class="progresscontainer">
<ul class="progressbar"><li class="progressprevoff">&#10094;</li><li class="progresscurrentchapter">P</li><li class="progresscurrent">wtmd</li><li class="progresschapter"><a href="1-bm.html">1</a></li><li class="progresschapter"><a href="2-it.html">2</a></li><li class="progresschapter"><a href="3-ic.html">3</a></li><li class="progresschapter"><a href="4-tcc.html">4</a></li><li class="progresschapter"><a href="5-tac.html">5</a></li><li class="progresschapter"><a href="6-tpc.html">6</a></li><li class="progressnext"><a href="1-bm.html">&#10095;</a></li></ul></div>
</nav><!--End of weave-->
</main>
</body>
</html>
Reference in a new issue View git blame Copy permalink