mirror of
https://github.com/ganelson/inform.git
synced 2024-07-03 07:24:58 +03:00
360 lines
26 KiB
HTML
360 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>A Brief Guide to Neptune</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 'A Brief Guide to Neptune' generated by Inweb-->
|
|
<div class="breadcrumbs">
|
|
<ul class="crumbs"><li><a href="../index.html">Home</a></li><li><a href="../services.html">Services</a></li><li><a href="index.html">kinds</a></li><li><a href="index.html#4">Chapter 4: Constructors</a></li><li><b>A Brief Guide to Neptune</b></li></ul></div>
|
|
<p class="purpose">A manual for the mini-language used in Neptune files.</p>
|
|
|
|
<ul class="toc"><li><a href="4-abgtn.html#SP1">§1. Purpose</a></li><li><a href="4-abgtn.html#SP2">§2. Comments and white space</a></li><li><a href="4-abgtn.html#SP3">§3. Declarations</a></li><li><a href="4-abgtn.html#SP7">§7. Commands</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="commentary firstcommentary"><a id="SP1" class="paragraph-anchor"></a><b>§1. Purpose. </b>Neptune is a simple mini-language for defining the built-in kinds of Inform.
|
|
Each kit of Inter code can supply one or more Neptune files: for example,
|
|
<span class="extract"><span class="extract-syntax">WorldModelKit</span></span> supplies a file called <span class="extract"><span class="extract-syntax">Scenes.neptune</span></span> which defines the
|
|
built-in base kind "scene".
|
|
</p>
|
|
|
|
<p class="commentary">The name is nothing to do with the planet and derives from the Place Neptune,
|
|
Carcassonne, where these files were first implemented in August 2007. The
|
|
syntax was made more legible in 2020.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP2" class="paragraph-anchor"></a><b>§2. Comments and white space. </b>Lines consisting of white space or whose first non-white space character is
|
|
<span class="extract"><span class="extract-syntax">!</span></span> are ignored as comments, but note that a <span class="extract"><span class="extract-syntax">!</span></span> later in a line which already
|
|
has other content will not be treated as a comment.
|
|
</p>
|
|
|
|
<p class="commentary">All white space at the start or end of a line is similarly ignored. Indentation
|
|
can be used for clarity, but has no significance.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP3" class="paragraph-anchor"></a><b>§3. Declarations. </b>Otherwise, a Neptune file is a series of declarations. Each must begin with
|
|
a header line which ends in an open brace, and must conclude with a line
|
|
consisting only of a close brace.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP4" class="paragraph-anchor"></a><b>§4. </b>A constructor is created with two initial keywords, and then its identifier
|
|
name. The first keyword must be either <span class="extract"><span class="extract-syntax">new</span></span> or <span class="extract"><span class="extract-syntax">builtin</span></span>. The only difference
|
|
here is that <span class="extract"><span class="extract-syntax">builtin</span></span> must be used if the constructor being made is one of
|
|
the <a href="2-fk.html" class="internal">Familiar Kinds</a>, whose identifier has to correspond to one of those
|
|
hardwired into the code of this module. <span class="extract"><span class="extract-syntax">new</span></span> must be used in all other cases.<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>
|
|
</p>
|
|
|
|
<p class="commentary">The second keyword must be one of the following:
|
|
</p>
|
|
|
|
<ul class="items"><li>● <span class="extract"><span class="extract-syntax">base</span></span> for a new base kind, like <span class="extract"><span class="extract-syntax">NUMBER_TY</span></span>.
|
|
</li><li>● <span class="extract"><span class="extract-syntax">constructor</span></span> for a proper constructor, like <span class="extract"><span class="extract-syntax">LIST_OF_TY</span></span>.
|
|
</li><li>● <span class="extract"><span class="extract-syntax">protocol</span></span> for a kind of kind, like <span class="extract"><span class="extract-syntax">SAYABLE_VALUE_TY</span></span>.
|
|
</li><li>● <span class="extract"><span class="extract-syntax">punctuation</span></span> for a constructor with no independent meaning, such as <span class="extract"><span class="extract-syntax">INTERMEDIATE_TY</span></span>.
|
|
</li></ul>
|
|
<p class="commentary">For example:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax">builtin protocol SAYABLE_VALUE_TY {</span>
|
|
<span class="plain-syntax"> conforms-to: STORED_VALUE_TY</span>
|
|
<span class="plain-syntax"> singular: sayable value</span>
|
|
<span class="plain-syntax"> plural: sayable values</span>
|
|
<span class="plain-syntax">}</span>
|
|
</pre>
|
|
<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> The distinction really only exists as a mnemonic - it reminds us that it
|
|
wouldn't be safe to change the identifier without also changing the compiler.
|
|
<a href="#fnref:1" title="return to text"> ↩</a></p></li></ul>
|
|
<p class="commentary firstcommentary"><a id="SP5" class="paragraph-anchor"></a><b>§5. </b>A "macro" is a set of commands which could be applied to any constructor.
|
|
It will have no effect unless applied, which happens only by a special command
|
|
(see below) or, for certain macro names, when the code in this module applies
|
|
it automatically.
|
|
</p>
|
|
|
|
<p class="commentary">For example:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax">macro #REAL {</span>
|
|
<span class="plain-syntax"> conforms-to: REAL_ARITHMETIC_VALUE_TY</span>
|
|
<span class="plain-syntax">}</span>
|
|
</pre>
|
|
<p class="commentary">This declares a macro called <span class="extract"><span class="extract-syntax">#REAL</span></span>. All macros have names beginning with a
|
|
sharp sign, and continuing with capital letters.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP6" class="paragraph-anchor"></a><b>§6. </b>An "invention" is a piece of source text to be added to whatever is being
|
|
compiled.<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup> Invention names begin with an asterisk. For example:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax">invention *UNDERSTOOD-VARIABLE {</span>
|
|
<span class="plain-syntax"> <kind> understood is a <kind> which varies.</span>
|
|
<span class="plain-syntax">}</span>
|
|
</pre>
|
|
<p class="commentary">Note that the text is not quite literal, because it can contain wildcards like
|
|
<span class="extract"><span class="extract-syntax"><kind></span></span>, which expands to the name of the kind in question: for instance, we
|
|
might get "number understood is a number which varies". The legal wildcards are:
|
|
</p>
|
|
|
|
<ul class="items"><li>● <kind>, expanding to the singular name of the kind.
|
|
</li><li>● <lower-case-kind>, the same but always using lower case.
|
|
</li><li>● <kind-weak-ID>, the weak ID number for the base kind.
|
|
</li><li>● <printing-routine>, the identifier of its printing routine.
|
|
</li><li>● <comparison-routine>, similarly.
|
|
</li></ul>
|
|
<p class="commentary">There are a few limitations on what template text can include. Firstly,
|
|
nothing with angle brackets in, except where a wildcard appears. Secondly,
|
|
each sentence must end at the end of a line, and similarly the colon for
|
|
any rule or other definition. Thus this template would fail:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax">invention *UNDERSTOOD-VARIABLE {</span>
|
|
<span class="plain-syntax"> <kind> understood is a <kind> which</span>
|
|
<span class="plain-syntax"> varies. To judge <kind>: say "I judge [<kind> understood]."</span>
|
|
<span class="plain-syntax">}</span>
|
|
</pre>
|
|
<p class="commentary">because the first sentence ends in the middle of the second line, and the
|
|
colon dividing the phrase header from its definition is also mid-line. The
|
|
template must be reformatted thus to work:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code code-font">
|
|
<span class="plain-syntax">invention *UNDERSTOOD-VARIABLE {</span>
|
|
<span class="plain-syntax"> <kind> understood is a <kind> which varies.</span>
|
|
<span class="plain-syntax"> To judge <kind>:</span>
|
|
<span class="plain-syntax"> say "I judge [<kind> understood]."</span>
|
|
<span class="plain-syntax">}</span>
|
|
</pre>
|
|
<ul class="footnotetexts"><li class="footnote" id="fn:2"><p class="inwebfootnote"><sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup> Inventions are not elegant and have now mostly been phased out, except to
|
|
create the "K understood" variables for each base kind conforming to
|
|
<span class="extract"><span class="extract-syntax">understandable value</span></span>, using the example invention shown here.
|
|
<a href="#fnref:2" title="return to text"> ↩</a></p></li></ul>
|
|
<p class="commentary firstcommentary"><a id="SP7" class="paragraph-anchor"></a><b>§7. Commands. </b>Inside a macro or a constructor declaration, each line consists of a single
|
|
command, always written in the form <span class="extract"><span class="extract-syntax">command: value</span></span>. If the command occurs
|
|
in a constructor, it applies to that constructor; if in a macro, it is applied
|
|
to whatever constructor the macro is being applied to (if it ever is).
|
|
</p>
|
|
|
|
<p class="commentary">All commands are a single word, though sometimes hyphenated. White space
|
|
either side of the <span class="extract"><span class="extract-syntax">value</span></span> is trimmed away. <span class="extract"><span class="extract-syntax">value</span></span> is not allowed to be empty,
|
|
or to contain only white space.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP8" class="paragraph-anchor"></a><b>§8. </b>Constructor declarations are conventionally written in four groups of commands,
|
|
though this is just convention. Let's start with the first block, which names
|
|
the constructor and locates it in the lattice.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">conforms-to: K</span></span> declares that the new kind conforms to the existing kind <span class="extract"><span class="extract-syntax">K</span></span>.
|
|
Multiple conformances can be given, but there is seldom any need to, because if
|
|
<span class="extract"><span class="extract-syntax">K</span></span> then conforms to <span class="extract"><span class="extract-syntax">L</span></span>, our new kind will do so too. In general, new base
|
|
kinds should declare their conformance to the most specific protocol they can.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">compatible-with: K</span></span> declares that <span class="extract"><span class="extract-syntax">K</span></span> is compatible with the new kind (note:
|
|
not the other way round), in a way needing explicit conversion code at run-time:
|
|
i.e., <span class="extract"><span class="extract-syntax">K</span></span> does not conform to the new kind, but can be converted to it.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">singular</span></span> and <span class="extract"><span class="extract-syntax">plural</span></span> specify singular and plural natural language names for
|
|
the constructor. If these are omitted, it will be impossible to refer to in
|
|
source text, but that doesn't necessarily make the constructor useless: the
|
|
compiler can still generate it internally. Multiple legal wordings can be
|
|
given, divided by vertical strokes. Names of the construction kinds can be
|
|
written as <span class="extract"><span class="extract-syntax">k</span></span> and <span class="extract"><span class="extract-syntax">l</span></span> (note lower case). So, for example, <span class="extract"><span class="extract-syntax">list of k</span></span>.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">terms</span></span> is used only for proper constructors. For a unary constructor, it will
|
|
give one term; for binary, two terms, separated by a comma. Each term should
|
|
be <span class="extract"><span class="extract-syntax">covariant</span></span> or <span class="extract"><span class="extract-syntax">contravariant</span></span>, with an optional keyword after it:
|
|
</p>
|
|
|
|
<ul class="items"><li>● <span class="extract"><span class="extract-syntax">optional</span></span> means that it is legal to name the constructor without naming
|
|
this term. For example, "activity" is a legal way to say "activity on nothing".
|
|
</li><li>● <span class="extract"><span class="extract-syntax">list</span></span> means that it is legal to give a list of kinds here, in brackets
|
|
if there are some, or <span class="extract"><span class="extract-syntax">nothing</span></span> if there are not.
|
|
</li></ul>
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">invent-source-text: *NAME</span></span> causes new source text to be invented. <span class="extract"><span class="extract-syntax">*NAME</span></span>
|
|
must be an invention which has already been declared. If this command is applied
|
|
to a protocol, such as <span class="extract"><span class="extract-syntax">arithmetic value</span></span>, then the invention will be made not
|
|
for the protocol itself, but for every base kind which conforms to it: this can
|
|
result in a stream of similar-looking sentences.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">apply-macro: #NAME</span></span> does what it says, really. Here, however, it applies to
|
|
protocols just the same as to everything else.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP9" class="paragraph-anchor"></a><b>§9. </b>The second group concerns behaviours of the kinds in question, or methods
|
|
for compiling their data. They are in general meaningless for protocols or
|
|
other kinds which don't refer to data stored at run-time.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">default-value</span></span> is the default value for an uninitialised variable of this
|
|
kind. If this is not set, problem messages may be generated for such variables.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">can-coincide-with-property</span></span> is either <span class="extract"><span class="extract-syntax">yes</span></span> or <span class="extract"><span class="extract-syntax">no</span></span> (default <span class="extract"><span class="extract-syntax">no</span></span>), and means
|
|
what it says: the name of this kind is allowed also to be the name of a property
|
|
which takes values in this kind.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">can-exchange</span></span> is either <span class="extract"><span class="extract-syntax">yes</span></span> or <span class="extract"><span class="extract-syntax">no</span></span> (default <span class="extract"><span class="extract-syntax">no</span></span>), and means that data of
|
|
this kind can be serialised — printed out as text into an external file —
|
|
and read into a different program, but with the same meaning.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">constant-compilation-method</span></span> tells Inform how to compile constants of this
|
|
kind. The possible options are: <span class="extract"><span class="extract-syntax">none</span></span>, <span class="extract"><span class="extract-syntax">literal</span></span>, <span class="extract"><span class="extract-syntax">quantitative</span></span> and <span class="extract"><span class="extract-syntax">special</span></span>,
|
|
the default being <span class="extract"><span class="extract-syntax">none</span></span>:
|
|
</p>
|
|
|
|
<ul class="items"><li>● <span class="extract"><span class="extract-syntax">none</span></span> means there are no constants of this kind.
|
|
</li><li>● <span class="extract"><span class="extract-syntax">literal</span></span> means constants are literals in Inform source text, such as 65 or 11:12 PM.
|
|
</li><li>● <span class="extract"><span class="extract-syntax">quantitative</span></span> means they are named instances, as for enumerations.
|
|
</li><li>● <span class="extract"><span class="extract-syntax">special</span></span> means that the compiler needs to use ad-hoc code to handle
|
|
this kind; unless it contains that code, of course, this can't be used.
|
|
</li></ul>
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">loop-domain-schema</span></span> is an Inter schema for iterating through the valid
|
|
instances of the kind.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">comparison-schema</span></span> is an Inter schema for comparing a value of this kind
|
|
with a value of a named other kind to which it does not conform. It should
|
|
take the form <span class="extract"><span class="extract-syntax">NAME>>>SCHEMA</span></span>, where <span class="extract"><span class="extract-syntax">NAME</span></span> is the other kind, and <span class="extract"><span class="extract-syntax">SCHEMA</span></span>
|
|
the Inter code.
|
|
</p>
|
|
|
|
<p class="commentary">If the kind conforms to <span class="extract"><span class="extract-syntax">POINTER_VALUE_TY</span></span> then it stores values on the heap,
|
|
rather than in single words of memory, and in that case three more properies
|
|
become meaningful: <span class="extract"><span class="extract-syntax">multiple-block</span></span> is either <span class="extract"><span class="extract-syntax">yes</span></span> or <span class="extract"><span class="extract-syntax">no</span></span> (default <span class="extract"><span class="extract-syntax">no</span></span>), and
|
|
allows data to expand arbitrarily in size if necessary; <span class="extract"><span class="extract-syntax">heap-size-estimate</span></span>
|
|
should be a power of 2, and gives an initial allocation size in words; and
|
|
<span class="extract"><span class="extract-syntax">small-block-size</span></span> optionally allows a small block (in words) to point to the
|
|
data (thus adding further indirection).
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">is-incompletely-defined</span></span> is either <span class="extract"><span class="extract-syntax">yes</span></span> or <span class="extract"><span class="extract-syntax">no</span></span> (default <span class="extract"><span class="extract-syntax">no</span></span>), and is a
|
|
short-term device used to handle kinds which have been created but not yet
|
|
turned into units or enumerations.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP10" class="paragraph-anchor"></a><b>§10. </b>The third group supplies identifier names for Inter routines to perform run-time
|
|
duties related to the kind. Inform will simply assume such a routine is present;
|
|
this will usually be defined in the same kit which is supplying the Neptune file.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">comparison-routine</span></span> determines which of two values of the kind is greater.
|
|
The default is <span class="extract"><span class="extract-syntax">UnsignedCompare</span></span>. The special value <span class="extract"><span class="extract-syntax">signed</span></span> can be used to
|
|
ask for signed comparison of the 2s-complement run-time values, which is a
|
|
little quicker than calling a routine.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">printing-routine</span></span> prints out a textual representation of a value of the given
|
|
kind, and <span class="extract"><span class="extract-syntax">printing-routine-for-debugging</span></span> the same but for purposes of the
|
|
debugging output called for by the ACTIONS command. These have no effect for
|
|
kinds which do not conform to <span class="extract"><span class="extract-syntax">sayable value</span></span>.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">parsing-routine</span></span> is a "general parsing routine", which assists the run-time
|
|
command parser. <span class="extract"><span class="extract-syntax">distinguishing-routine</span></span>, similarly, determines whether two
|
|
things can be distinguished by textual commands. These have no effect in Basic
|
|
Inform projects, or for kinds which do not conform to <span class="extract"><span class="extract-syntax">understandable value</span></span>.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">recognition-routine</span></span> is a "recognition-only general parsing routine". Again
|
|
this has no effect in Basic Inform projects. It is only used for kinds which
|
|
do not conform to <span class="extract"><span class="extract-syntax">understandable value</span></span>, but can nevertheless be used when
|
|
the command parser allows things to be named by their property values, and
|
|
those values have the kind in question.
|
|
</p>
|
|
|
|
<p class="commentary firstcommentary"><a id="SP11" class="paragraph-anchor"></a><b>§11. </b>The final group is concerned only with documentation and indexing, and thus
|
|
has no effect on compilation.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">documentation-reference</span></span> is a reference keyword to the Inform documentation,
|
|
which can make be used to improve problem messages or the index by giving little
|
|
blue help buttons next to the kind's name.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">index-priority</span></span> is a non-negative integer. It is by default 100 for base kinds
|
|
and constructors, 0 for protocols and punctuation. 0 in fact means "omit from the
|
|
index", which is otherwise grouped in ascending order — i.e., lowest priority
|
|
numbers first.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">index-default-value</span></span> can be used in place of the <span class="extract"><span class="extract-syntax">default-value</span></span> in the index,
|
|
to make it look prettier.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">index-maximum-value</span></span> can similarly override the indexer's automated attempt to
|
|
print the largest representable value, and similarly for <span class="extract"><span class="extract-syntax">index-minimum-value</span></span>.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">indexed-grey-if-empty</span></span> is either <span class="extract"><span class="extract-syntax">yes</span></span> or <span class="extract"><span class="extract-syntax">no</span></span> (default <span class="extract"><span class="extract-syntax">no</span></span>), and specifies
|
|
that if the kind has no instances then it should be tinted grey in the index.
|
|
</p>
|
|
|
|
<p class="commentary"><span class="extract"><span class="extract-syntax">specification-text</span></span> provides the value of the specification pseudo-property
|
|
(an oddball feature of the Inform language which seemed like a good idea at
|
|
the time). This should be plain text, not HTML.
|
|
</p>
|
|
|
|
<nav role="progress"><div class="progresscontainer">
|
|
<ul class="progressbar"><li class="progressprev"><a href="3-sav.html">❮</a></li><li class="progresschapter"><a href="P-wtmd.html">P</a></li><li class="progresschapter"><a href="1-km.html">1</a></li><li class="progresschapter"><a href="2-knd.html">2</a></li><li class="progresschapter"><a href="3-dmn.html">3</a></li><li class="progresscurrentchapter">4</li><li class="progresscurrent">abgtn</li><li class="progresssection"><a href="4-nf.html">nf</a></li><li class="progresssection"><a href="4-ns.html">ns</a></li><li class="progresssection"><a href="4-mcr.html">mcr</a></li><li class="progresssection"><a href="4-st.html">st</a></li><li class="progresssection"><a href="4-kc.html">kc</a></li><li class="progresssection"><a href="4-kc2.html">kc2</a></li><li class="progressnext"><a href="4-nf.html">❯</a></li></ul></div>
|
|
</nav><!--End of weave-->
|
|
|
|
</main>
|
|
</body>
|
|
</html>
|
|
|