mirror of
https://github.com/ganelson/inform.git
synced 2024-07-17 06:24:24 +03:00
465 lines
26 KiB
HTML
465 lines
26 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>Pipelines and Stages</title>
|
|
<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="../inweb.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
|
|
</head>
|
|
<body>
|
|
<nav role="navigation">
|
|
<h1><a href="../index.html">
|
|
<img src="../docs-src/Figures/Inform.png" height=72">
|
|
</a></h1>
|
|
<ul><li><a href="../compiler.html">compiler tools</a></li>
|
|
<li><a href="../other.html">other tools</a></li>
|
|
<li><a href="../extensions.html">extensions and kits</a></li>
|
|
<li><a href="../units.html">unit test tools</a></li>
|
|
</ul><h2>Compiler Webs</h2><ul>
|
|
<li><a href="../inbuild/index.html">inbuild</a></li>
|
|
<li><a href="../inform7/index.html">inform7</a></li>
|
|
<li><a href="index.html"><span class="selectedlink">inter</span></a></li>
|
|
</ul><h2>Inbuild Modules</h2><ul>
|
|
<li><a href="../supervisor-module/index.html">supervisor</a></li>
|
|
</ul><h2>Inform7 Modules</h2><ul>
|
|
<li><a href="../core-module/index.html">core</a></li>
|
|
<li><a href="../inflections-module/index.html">inflections</a></li>
|
|
<li><a href="../linguistics-module/index.html">linguistics</a></li>
|
|
<li><a href="../kinds-module/index.html">kinds</a></li>
|
|
<li><a href="../if-module/index.html">if</a></li>
|
|
<li><a href="../multimedia-module/index.html">multimedia</a></li>
|
|
<li><a href="../problems-module/index.html">problems</a></li>
|
|
<li><a href="../index-module/index.html">index</a></li>
|
|
</ul><h2>Inter Modules</h2><ul>
|
|
<li><a href="../bytecode-module/index.html">bytecode</a></li>
|
|
<li><a href="../building-module/index.html">building</a></li>
|
|
<li><a href="../codegen-module/index.html">codegen</a></li>
|
|
</ul><h2>Shared Modules</h2><ul>
|
|
<li><a href="../arch-module/index.html">arch</a></li>
|
|
<li><a href="../syntax-module/index.html">syntax</a></li>
|
|
<li><a href="../words-module/index.html">words</a></li>
|
|
<li><a href="../html-module/index.html">html</a></li>
|
|
<li><a href="../../../inweb/docs/foundation-module/index.html">foundation</a></li>
|
|
|
|
</ul>
|
|
</nav>
|
|
<main role="main">
|
|
|
|
<!--Weave of 'Pipelines and Stages' generated by 7-->
|
|
<ul class="crumbs"><li><a href="../index.html">Home</a></li><li><a href="../compiler.html">Compiler Tools</a></li><li><a href="index.html">inter</a></li><li><a href="index.html#M">Manual</a></li><li><b>Pipelines and Stages</b></li></ul><p class="purpose">Sequences of named code-generation stages are called pipelines.</p>
|
|
|
|
<ul class="toc"><li><a href="M-pas.html#SP1">§1. Stages and descriptions</a></li><li><a href="M-pas.html#SP3">§3. Pipelines run by Inform</a></li><li><a href="M-pas.html#SP4">§4. Stage descriptions</a></li><li><a href="M-pas.html#SP5">§5. Reading and generating</a></li><li><a href="M-pas.html#SP6">§6. The code-generation stages</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="inwebparagraph"><a id="SP1"></a><b>§1. Stages and descriptions. </b>A processing stage is a step in code generation which acts on a repository
|
|
of inter in memory. Some stages change, add to or edit down that code, while
|
|
others leave it untouched but output a file based on it.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Each stage can see an entire repository of inter code at a time, and is
|
|
not restricted to working through it in sequence.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Stages are named, which are written without spaces, and conventionally use
|
|
hyphens: for example, <code class="display"><span class="extract">resolve-conditional-compilation</span></code>. Where a filename has
|
|
to be supplied, it appears after a colon. Thus <code class="display"><span class="extract">generate-inter:my.intert</span></code>
|
|
is a valid stage description.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">A "pipeline" is a list of stage descriptions. If the pipeline is spelled
|
|
out textually on the command line, then commas are used to divide the stages:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="element">$</span><span class="plain"> </span><span class="functiontext">inter/Tangled/inter</span><span class="identifier"> -pipeline-text</span><span class="plain"> 'plugh, xyzzy, plover'</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">If the pipeline is in an external file, we would instead write:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="element">$</span><span class="plain"> </span><span class="functiontext">inter/Tangled/inter</span><span class="identifier"> -pipeline-file</span><span class="plain"> mypl.interpipeline</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">and the file <code class="display"><span class="extract">mypl.interpipeline</span></code> would have one stage listed on each line,
|
|
so that the commas are not needed:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">plugh</span>
|
|
<span class="plain">xyzzy</span>
|
|
<span class="plain">plover</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP2"></a><b>§2. </b>A pipeline description can make use of "variables". These hold only text,
|
|
and generally represent filenames. Variable names begin with a star <code class="display"><span class="extract">*</span></code>.
|
|
The pipeline cannot create variables: instead, the user of the pipeline has
|
|
to make them before use. For example,
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="element">$</span><span class="plain"> </span><span class="functiontext">inter/Tangled/inter</span><span class="identifier"> -variable</span><span class="plain"> '*X=ex/why'</span><span class="identifier"> -pipeline-file</span><span class="plain"> mypl.interpipeline</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">creates the variable <code class="display"><span class="extract">*X</span></code> with the textual contents <code class="display"><span class="extract">ex/why</span></code> before running
|
|
the given pipeline. Inside the pipeline, a line such as:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">generate inform6 </span><span class="reserved">-></span><span class="plain"> </span><span class="identifier">*X</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">would then be read as:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">generate inform6 </span><span class="reserved">-></span><span class="plain"> ex/why</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">After variable substitution like this, filenames inside the pipeline
|
|
description are interpreted as follows:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) If a filename contains a slash character, it is considered a literal
|
|
filename.
|
|
</li><li>(b) If not, it is considered to be a leafname inside the "domain" directory.
|
|
By default this is the current working directory, but using <code class="display"><span class="extract">-domain</span></code> at
|
|
the Inter command line changes that.
|
|
</li></ul>
|
|
<p class="inwebparagraph">The special variable <code class="display"><span class="extract">*log</span></code>, which always exists, means the debugging log.
|
|
A command to write a text file to <code class="display"><span class="extract">*log</span></code> is interpreted instead to mean
|
|
"spool the output you would otherwise write to the debugging log instead".
|
|
For example,
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">generate inventory </span><span class="reserved">-></span><span class="plain"> </span><span class="identifier">*log</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP3"></a><b>§3. Pipelines run by Inform. </b>As the above implies, Inter pipelines normally begin with a clean slate:
|
|
no repositories, no variables.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">When a pipeline is being run by the main Inform 7 compiler, however,
|
|
two variables are created in advance. <code class="display"><span class="extract">*in</span></code> is set to the inter code
|
|
which Inform has generated on the current run, and <code class="display"><span class="extract">*out</span></code> is set to the
|
|
filename to which final I6 code needs to be written. The practical
|
|
effect is that any useful pipeline for Inform will begin and end thus:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">read </span><span class="reserved"><-</span><span class="plain"> </span><span class="identifier">*in</span>
|
|
<span class="plain">...</span>
|
|
<span class="plain">generate inform6 </span><span class="reserved">-></span><span class="plain"> </span><span class="identifier">*out</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">In addition, the "domain" is set to the directory containing the <code class="display"><span class="extract">*out</span></code>
|
|
file.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">To Inbuild and Inform, pipelines are resources in their own right, rather
|
|
like extensions or kits. So, for example, the standard distribution includes
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">inform7/Internal/Pipelines/compile.interpipeline</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">which is the one used for standard compilation runs. A projects Materials
|
|
folder is free to provide a replacement:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">Strange.materials/Pipelines/compile.interpipeline</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">...and then this will be used instead when compiling <code class="display"><span class="extract">Strange.inform</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">1. This sentence in Inform source text:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>Use inter pipeline "NAME".</p>
|
|
|
|
</blockquote>
|
|
|
|
<p class="inwebparagraph">replaces the pipeline normally used for code generation with the one supplied.
|
|
(That may very well cause the compiler not to produce viable code, of course.)
|
|
The default Inter pipeline is called <code class="display"><span class="extract">compile</span></code>, and comes built-in. Named
|
|
pipelines are stored alongside named extensions and other resources used by
|
|
Inform; so for example you could write:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>Use inter pipeline "mypipeline".</p>
|
|
|
|
</blockquote>
|
|
|
|
<p class="inwebparagraph">And then store the actual pipeline file as:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">Example Work.materials/Pipelines/mypipeline.interpipeline</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph">2. You don't need the Use... sentence, though, if you're willing to choose
|
|
on the command line instead:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="element">$</span><span class="plain"> </span><span class="functiontext">inform7/Tangled/inform7</span><span class="plain"> ...</span><span class="identifier"> -pipeline</span><span class="plain"> NAME</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">Or, if you want to name a file explicitly, not have it looked for by name:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="element">$</span><span class="plain"> </span><span class="functiontext">inform7/Tangled/inform7</span><span class="plain"> ...</span><span class="identifier"> -pipeline-file</span><span class="plain"> FILE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">3. Finally, you can also give Inform 7 an explicit pipeline in textual form:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="element">$</span><span class="plain"> </span><span class="functiontext">inform7/Tangled/inform7</span><span class="plain"> ...</span><span class="identifier"> -pipeline-text</span><span class="plain"> 'PIPELINE'</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">Note that Inbuild and Inform 7 respond to all three of <code class="display"><span class="extract">-pipeline</span></code>,
|
|
<code class="display"><span class="extract">-pipeline-file</span></code> and <code class="display"><span class="extract">-pipeline-text</span></code>, whereas Inter responds only to the
|
|
last two. (It can't find pipelines by name because it doesn't contain the
|
|
complex code for sorting out resources.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP4"></a><b>§4. Stage descriptions. </b>There are three sorts of stage description: those involving material coming
|
|
in, denoted by a left arrow, those involving some external file being written
|
|
out, denoted by a right arrow, and those which just process what we have.
|
|
These take the following forms:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">STAGENAME [LOCATION] </span><span class="reserved"><-</span><span class="plain"> SOURCE</span>
|
|
<span class="plain">STAGENAME [LOCATION] FORMAT </span><span class="reserved">-></span><span class="plain"> DESTINATION</span>
|
|
<span class="plain">STAGENAME [LOCATION]</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">In each case the <code class="display"><span class="extract">LOCATION</span></code> is optional. For example:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">read </span><span class="constant">2</span><span class="plain"> </span><span class="reserved"><-</span><span class="plain"> </span><span class="identifier">*in</span>
|
|
<span class="plain">generate binary </span><span class="reserved">-></span><span class="plain"> </span><span class="identifier">*out</span>
|
|
<span class="plain">eliminate-redundant-labels /main/template</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">In the first line the location is <code class="display"><span class="extract">2</span></code>. Pipeline descriptios allow us to manage
|
|
up to 10 different repositories, and these are called <code class="display"><span class="extract">0</span></code> to <code class="display"><span class="extract">9</span></code>. These are
|
|
all initially empty. Any stage which doesn't specify a repository is considered
|
|
to apply to <code class="display"><span class="extract">0</span></code>; plenty of pipelines never mention the digits <code class="display"><span class="extract">0</span></code> to <code class="display"><span class="extract">9</span></code> at
|
|
all because they do everything inside <code class="display"><span class="extract">0</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">In the second line, there's no location given, so the location is presumed
|
|
to be <code class="display"><span class="extract">0</span></code>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The third line demonstrates that a location can be more specific than just
|
|
a repository: it can be a specific package in a repository. Here, it's
|
|
<code class="display"><span class="extract">/main/template</span></code> in repository <code class="display"><span class="extract">0</span></code>, but we could also write <code class="display"><span class="extract">7:/main/template</span></code>
|
|
to mean <code class="display"><span class="extract">/main/template</span></code> in <code class="display"><span class="extract">7</span></code>, for example. Not all stages allow the
|
|
location to be narrowed down to a single package (which by definition
|
|
includes all its subpackages): see below.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP5"></a><b>§5. Reading and generating. </b>The <code class="display"><span class="extract">read</span></code> stage reads Inter from a file into a repository in memory.
|
|
(Its previous contents, if any, are discarded.) This then becomes the
|
|
repository to which subsequent stages apply. The format is:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">read REPOSITORY </span><span class="reserved"><-</span><span class="plain"> FILE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">where <code class="display"><span class="extract">REPOSITORY</span></code> is <code class="display"><span class="extract">0</span></code> to <code class="display"><span class="extract">9</span></code>, and is <code class="display"><span class="extract">0</span></code> if not supplied. Note that
|
|
this fills an entire repository: it's not meaningful to specify a
|
|
named package as the location.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The <code class="display"><span class="extract">FILE</span></code> can contain either binary or textual Inter, and this is
|
|
automatically detected.
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="plain">generate FORMAT </span><span class="reserved">-></span><span class="plain"> FILE</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">writes the repository out into the given <code class="display"><span class="extract">FILE</span></code>. There are several possible
|
|
formats: <code class="display"><span class="extract">binary</span></code> and <code class="display"><span class="extract">text</span></code> mean a binary or textual Inter file, <code class="display"><span class="extract">inventory</span></code>
|
|
means a textual summary of the contents, and <code class="display"><span class="extract">inform6</span></code> means an Inform 6
|
|
program. At present, only <code class="display"><span class="extract">inventory</span></code> can be generated on specific
|
|
packages in a repository.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The <code class="display"><span class="extract">generate</span></code> stage leaves the repository unchanged, so it's possible
|
|
to generate multiple representations of the same repository into different
|
|
files.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP6"></a><b>§6. The code-generation stages. </b>The following are all experimental, and have probably not yet reached their
|
|
final form or names.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Although one thinks of code generation as a process of turning inter into
|
|
Inform 6, in fact it goes both ways, because we also have to read in
|
|
the "template" of standing Inform 6 code. The early code generation stages
|
|
convert the template from Inform 6 into inter, merging it with the inter
|
|
already produced by the front end of the compiler. The later stages then
|
|
turn this merged repository into Inform 6 code. (Routines in the template,
|
|
therefore, are converted out of Inform 6 and then back into it again. This
|
|
sounds inefficient but is surprisingly fast, and enables many optimisations.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP7"></a><b>§7. </b><code class="display"><span class="extract">merge-template <- T</span></code> reads in the I6T template file <code class="display"><span class="extract">T</span></code>, converts it to
|
|
inter in a very basic way (creating many splats), and merges it with the
|
|
repository. Splats are the unhappiest of inter statements, simply including
|
|
verbatim snippets of Inform 6 code.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP8"></a><b>§8. </b><code class="display"><span class="extract">parse-linked-matter</span></code> examines the splats produced by merging and annotates
|
|
them by what they seem to want to do. For example,
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="reserved">splat</span><span class="plain"> &</span><span class="string">"Global nitwit = 2;\n"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">is recognised as an Inform 6 variable declaration, and annotated thus:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="reserved">splat</span><span class="plain"> GLOBAL &</span><span class="string">"Global nitwit = 2;\n"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP9"></a><b>§9. </b><code class="display"><span class="extract">resolve-conditional-compilation</span></code> looks for splats arising from Inform 6
|
|
conditional compilation directives such as <code class="display"><span class="extract">#ifdef</span></code>, <code class="display"><span class="extract">#ifndef</span></code>, <code class="display"><span class="extract">#endif</span></code>;
|
|
it then detects whether the relevant symbols are defined, or looks at their
|
|
values, and deletes sections of code not to be compiled. At the end of this
|
|
stage, there are no conditional compilation splats left in the repository.
|
|
For example:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="reserved">constant</span><span class="plain"> MAGIC </span><span class="identifier">K_number</span><span class="plain"> = </span><span class="constant">16339</span>
|
|
<span class="reserved">splat</span><span class="plain"> IFTRUE &</span><span class="string">"#iftrue MAGIC == 16339;\n"</span>
|
|
<span class="reserved">constant</span><span class="plain"> WIZARD </span><span class="identifier">K_number</span><span class="plain"> = </span><span class="constant">5</span>
|
|
<span class="reserved">splat</span><span class="plain"> IFNOT &</span><span class="string">"#ifnot;\n"</span>
|
|
<span class="reserved">constant</span><span class="plain"> MUGGLE </span><span class="identifier">K_number</span><span class="plain"> = </span><span class="constant">0</span>
|
|
<span class="reserved">splat</span><span class="plain"> ENDIF &</span><span class="string">"#endif;\n"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">is resolved to:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="reserved">constant</span><span class="plain"> MAGIC </span><span class="identifier">K_number</span><span class="plain"> = </span><span class="constant">16339</span>
|
|
<span class="reserved">constant</span><span class="plain"> WIZARD </span><span class="identifier">K_number</span><span class="plain"> = </span><span class="constant">5</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP10"></a><b>§10. </b><code class="display"><span class="extract">assimilate</span></code> aims to convert all remaining splats in the repository into
|
|
higher-level inter statements. For example,
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="reserved">splat</span><span class="plain"> STUB &</span><span class="string">"#Stub Peach 0;\n"</span>
|
|
<span class="reserved">splat</span><span class="plain"> ATTRIBUTE &</span><span class="string">"Attribute marmorial;\n"</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">becomes:
|
|
</p>
|
|
|
|
<pre class="display">
|
|
<span class="reserved">constant</span><span class="plain"> Peach </span><span class="identifier">K_unchecked_function</span><span class="plain"> = Peach_B </span><span class="identifier">__assimilated</span><span class="plain">=1</span>
|
|
<span class="reserved">property</span><span class="plain"> marmorial </span><span class="identifier">K_truth_state</span><span class="plain"> </span><span class="identifier">__assimilated</span><span class="plain">=1 </span><span class="identifier">__attribute</span><span class="plain">=1 </span><span class="identifier">__either_or</span><span class="plain">=1</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">At the end of this stage, there should be no splats left in the repository,
|
|
and the linking process is complete.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP11"></a><b>§11. </b><code class="display"><span class="extract">make-identifiers-unique</span></code> looks for symbols marked with the <code class="display"><span class="extract">MAKE_NAME_UNIQUE</span></code>
|
|
flag (represented in textual form by an asterisk after its name), This flag
|
|
means that Inform wants the symbol name to be globally unique in the repository.
|
|
For example, if Inform generates the symbol name <code class="display"><span class="extract">fruit*</span></code>, it's really telling
|
|
the code generator that it eventually wants this to have a name which won't
|
|
collide with anything else.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">What <code class="display"><span class="extract">make-identifiers-unique</span></code> does is to append <code class="display"><span class="extract">_U1</span></code>, <code class="display"><span class="extract">_U2</span></code>, ... to such
|
|
names across the repository. Thus <code class="display"><span class="extract">fruit*</span></code> might become <code class="display"><span class="extract">fruit_U176</span></code>, and it
|
|
is guaranteed that no other symbol has the same name.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">This stage is needed because whereas the inter language has namespces, so
|
|
that the same name can mean different things in different parts of the
|
|
program, Inform 6 (mostly) does not. There cannot be two functions with the
|
|
same name in any I6 program, for example.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">At the end of this stage, no symbol still has the <code class="display"><span class="extract">MAKE_NAME_UNIQUE</span></code> flag.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP12"></a><b>§12. </b><code class="display"><span class="extract">reconcile-verbs</span></code> is a short stage looking for clashes between any verbs (in
|
|
the parser interactive fiction sense) which have been assimilated from the
|
|
template, and verbs which have been defined in the main source text. For
|
|
example, suppose the source creates the command verb "abstract": this would
|
|
collide with the command meta-verb "abstract", intended for debugging, which
|
|
appears in the template. What this stage does is to detect such problems,
|
|
and if it finds one, to prefix the template verb with <code class="display"><span class="extract">!</span></code>. Thus we would end
|
|
up with two command verbs: <code class="display"><span class="extract">abstract</span></code>, with its source text meaning, and
|
|
<code class="display"><span class="extract">!abstract</span></code>, with its template meaning.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">At the end of this stage, all parser verbs have distinct textual forms.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP13"></a><b>§13. </b><code class="display"><span class="extract">eliminate-redundant-code</span></code> deletes all packages which Inter can prove
|
|
will not be used in the final code generated from the repository. For
|
|
example, functions never called, or arrays never referred to, are deleted.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP14"></a><b>§14. </b><code class="display"><span class="extract">eliminate-redundant-labels</span></code> performs peephole optimisation on all of
|
|
the functions in the repository to remove all labels which are declared
|
|
but can never be jumped to.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">At the end of this stage, all labels inside functions are targets of some
|
|
branch, either by <code class="display"><span class="extract">inv !jump</span></code> or in assembly language.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP15"></a><b>§15. </b>The special stage <code class="display"><span class="extract">stop</span></code> halts processing of the pipeline midway. At present
|
|
this is only useful for making experimental edits to pipeline descriptions
|
|
to see what just the first half does, without deleting the second half of
|
|
the description.
|
|
</p>
|
|
|
|
<hr class="tocbar">
|
|
<ul class="toc"><li><a href="M-io.html">Back to 'Inform Organisation'</a></li><li><a href="M-rc.html">Continue with 'Reference Card'</a></li></ul><hr class="tocbar">
|
|
<!--End of weave-->
|
|
</main>
|
|
</body>
|
|
</html>
|
|
|