<!--Weave of 'How to Write a Web' generated by Inweb-->
<ulclass="crumbs"><li><ahref="../index.html">Home</a></li><li><ahref="index.html">inweb</a></li><li><ahref="index.html#M">Manual</a></li><li><b>How to Write a Web</b></li></ul><pclass="purpose">How to mark up code for literate programming.</p>
<ulclass="toc"><li><ahref="M-htwaw.html#SP1">§1. The title of a section</a></li><li><ahref="M-htwaw.html#SP2">§2. Paragraphing</a></li><li><ahref="M-htwaw.html#SP6">§6. Conditional compilation</a></li><li><ahref="M-htwaw.html#SP7">§7. Commentary</a></li><li><ahref="M-htwaw.html#SP12">§12. Code samples and other extraneous matter</a></li><li><ahref="M-htwaw.html#SP13">§13. Links</a></li><li><ahref="M-htwaw.html#SP14">§14. Cross-references</a></li><li><ahref="M-htwaw.html#SP18">§18. Figures</a></li><li><ahref="M-htwaw.html#SP19">§19. Embedded video</a></li><li><ahref="M-htwaw.html#SP22">§22. Mathematics notation</a></li><li><ahref="M-htwaw.html#SP23">§23. Footnotes</a></li></ul><hrclass="tocbar">
<pclass="inwebparagraph"><aid="SP1"></a><b>§1. The title of a section. </b>In any section file, there will be a few lines at the top which occur before
the first paragraph of code begins. (The first paragraph begins on the first
line which starts with an <codeclass="display"><spanclass="extract-syntax">@</span></code> character.)
</p>
<pclass="inwebparagraph">The first line should be the title of the section, followed by a full stop.
For example:
</p>
<preclass="display">
<spanclass="plain-syntax"> The Sieve of Eratosthenes.</span>
</pre>
<pclass="inwebparagraph">A section title must contain only filename-safe characters, and it's probably
wise to make them filename-safe on all platforms: so don't include either
kind of slash, or a colon, and in general go easy on punctuation marks.
</p>
<pclass="inwebparagraph">Optionally, a section heading can also specify its own range abbreviation,
which must be given in round brackets and followed by a colon:
</p>
<preclass="display">
<spanclass="plain-syntax"> (S/sieve): The Sieve of Eratosthenes.</span>
</pre>
<pclass="inwebparagraph">If this is not done (and usually it is not), Inweb will construct a range
abbreviation itself: in this case, it comes up with <codeclass="display"><spanclass="extract-syntax">S/tsoe</span></code>.
</p>
<pclass="inwebparagraph">Subsequent lines of text are then taken as the optional description of the
purpose of the code in this section. (This is used on contents pages.) For
example:
</p>
<preclass="display">
<spanclass="plain-syntax"> A fairly fast way to determine if small numbers are prime, given storage.</span>
</pre>
<pclass="inwebparagraph"><aid="SP2"></a><b>§2. Paragraphing. </b>A standard paragraph is introduced with an <codeclass="display"><spanclass="extract-syntax">@</span></code> command, which must place
that magic character in the first column of the line:
</p>
<preclass="display">
<spanclass="plain-syntax"></span><spanclass="function-syntax">@</span><spanclass="plain-syntax"> This is some comment at the start of a new paragraph, which...</span>
</pre>
<pclass="inwebparagraph">A fancier paragraph with a subheading attached is introduced using the
<codeclass="display"><spanclass="extract-syntax">@h</span></code> or <codeclass="display"><spanclass="extract-syntax">@heading</span></code> command instead. (This is simply a long and short version
of the same command.) The text of the subheading then follows, up to the
first full stop.
</p>
<preclass="display">
<spanclass="plain-syntax"></span><spanclass="function-syntax">@heading</span><spanclass="plain-syntax"> Reflections on the method.</span>
</pre>
<pclass="inwebparagraph">Paragraphs can contain three ingredients, all optional, but if given then
given in this order: comment, definitions, and code. The following
<spanclass="plain-syntax"> int isprime(int n) {</span>
<spanclass="plain-syntax"> if (n <= 1) return FALSE;</span>
<spanclass="plain-syntax"> for (int m = 2; m*m <= n; m++)</span>
<spanclass="plain-syntax"> if (n % m == 0)</span>
<spanclass="plain-syntax"> return FALSE;</span>
<spanclass="plain-syntax"> return TRUE;</span>
<spanclass="plain-syntax"> }</span>
</pre>
<pclass="inwebparagraph"><aid="SP3"></a><b>§3. </b>Definitions are made using one of three commands: <codeclass="display"><spanclass="extract-syntax">@d</span></code> or <codeclass="display"><spanclass="extract-syntax">@define</span></code>; or
<codeclass="display"><spanclass="extract-syntax">@e</span></code> or <codeclass="display"><spanclass="extract-syntax">@enum</span></code>; or <codeclass="display"><spanclass="extract-syntax">@default</span></code>, which is rarely used and has no abbreviation.
These create new constants in the program, with the values given: they are
the equivalent of a <codeclass="display"><spanclass="extract-syntax">#define</span></code> directive in C. <codeclass="display"><spanclass="extract-syntax">@define</span></code> is the simpler form.
<pclass="inwebparagraph">sets <codeclass="display"><spanclass="extract-syntax">ENIGMATIC_NUMBER</span></code> to 90125. Unlike in the C preprocessor, multi-line
definitions are automatically handled, so for example:
</p>
<preclass="display">
<spanclass="plain-syntax"></span><spanclass="function-syntax">@</span><spanclass="plain-syntax"> The following macro defines a function:</span>
<spanclass="plain-syntax"> printf("The banana has an eat-by date of %d.", consume_by_banana(&my_banana));</span>
<spanclass="plain-syntax"> }</span>
</pre>
<pclass="inwebparagraph">In fact, a definition continues until the next definition, or until the code
part of the paragraph begins, or until the paragraph ends, whichever comes
first.
</p>
<pclass="inwebparagraph">Enumerations with <codeclass="display"><spanclass="extract-syntax">@enum</span></code> are a convenience to define enumerated constants.
For example,
</p>
<preclass="display">
<spanclass="plain-syntax"></span><spanclass="function-syntax">@enum</span><spanclass="plain-syntax"> JANUARY_MNTH from 0</span>
<pclass="inwebparagraph">What happens is that <codeclass="display"><spanclass="extract-syntax">@enum</span></code> looks at the tail of the name, from the last
underscore to the end: in this case, <codeclass="display"><spanclass="extract-syntax">_MNTH</span></code>. The first time an enumerated
value is asked for with this tail, <codeclass="display"><spanclass="extract-syntax">from</span></code> is used to specify the lowest
number to be used - in the above case, months begin counting from 0. With
each subsequent <codeclass="display"><spanclass="extract-syntax">_MNTH</span></code> request, <codeclass="display"><spanclass="extract-syntax">@enum</span></code> allocates the next unused value.
</p>
<pclass="inwebparagraph">All symbols defined with <codeclass="display"><spanclass="extract-syntax">@define</span></code> or <codeclass="display"><spanclass="extract-syntax">@enum</span></code> are global, and can be used
from anywhere in the web, including in sections or paragraphs earlier than
the ones in which they are defined. (The tangler automatically arranges code
as necessary to make this work.)
</p>
<pclass="inwebparagraph">A symbol defined with <codeclass="display"><spanclass="extract-syntax">@default</span></code> has the given value only if some other use
of <codeclass="display"><spanclass="extract-syntax">@d</span></code> or <codeclass="display"><spanclass="extract-syntax">@e</span></code> in the web has not already defined it. For example, if the
<pclass="inwebparagraph">We can tell the tangler to place the code early in the tangled program,
rather than at its natural place in the sequence, by annotating
</p>
<preclass="display">
<spanclass="plain-syntax"> = (early code)</span>
</pre>
<pclass="inwebparagraph">instead of just <codeclass="display"><spanclass="extract-syntax">=</span></code>. (This is occasionally useful where, for example, it's
necessary to create global variables which will be referred to in other
sections of code.) The more extreme <codeclass="display"><spanclass="extract-syntax">= (very early code)</span></code> can be used in C
for complicated header file inclusions, but should be kept to an absolute
minimum, if only for clarity.
</p>
<pclass="inwebparagraph"><aid="SP5"></a><b>§5. </b>One last feature, but it's the most important. Some code extracts are
given names, in angle brackets. If so, then the paragraph is the definition
<spanclass="plain-syntax"> printf("I'm ruined! Ruined, I say!\n");</span>
<spanclass="plain-syntax"> exit(1);</span>
</pre>
<pclass="inwebparagraph">Notice that the equals sign is still there: it's just that the chunk of code
is given a name, written inside <codeclass="display"><spanclass="extract-syntax">@<</span></code> and <codeclass="display"><spanclass="extract-syntax">@></span></code> "brackets". (This notation
goes all the way back to Knuth's original WEB.)
</p>
<pclass="inwebparagraph">What does the tangler do with this? It doesn't place the code as the next
item in the program. Instead, it expands any mention of <codeclass="display"><spanclass="extract-syntax">@<Dramatic finale@></span></code>
elsewhere in the section with this block of code. It can be expanded as
many times as necessary, but only within the same section. Another section
would be quite free to define its own <codeclass="display"><spanclass="extract-syntax">@<Dramatic finale@></span></code>, but it would
not be able to see this one.
</p>
<pclass="inwebparagraph">Why is this important? One of the points of literate programming is to
subdivide the program on conceptual lines, even within single functions.
For example:
</p>
<preclass="display">
<spanclass="plain-syntax"></span><spanclass="function-syntax">@<Perform the sieve@> =</span>
<spanclass="plain-syntax"></span><spanclass="function-syntax">@<Start with all numbers from 2 upwards in the sieve@></span><spanclass="plain-syntax">;</span>
<spanclass="plain-syntax"> for (int n=2; n*n <= RANGE; n++)</span>
<spanclass="plain-syntax"> if (still_in_sieve[n])</span>
<spanclass="plain-syntax"></span><spanclass="function-syntax">@<Shake out multiples of n@></span><spanclass="plain-syntax">;</span>
<pclass="inwebparagraph">This is easier to understand than writing the function all in one go, and
more practicable than breaking it up into smaller functions.
</p>
<pclass="inwebparagraph">Named paragraphs behave, in some ways, like macro definitions, and those
have a bad name nowadays - probably fairly. But Inweb makes them much
safer to use than traditional macros, because it tangles them into code
blocks, not just into runs of statements. A variable defined inside a
named paragraph has, as its scope, just that paragraph. And this:
</p>
<preclass="display">
<spanclass="plain-syntax"> if (still_in_sieve[n])</span>
<spanclass="plain-syntax"></span><spanclass="function-syntax">@<Shake out multiples of n@></span><spanclass="plain-syntax">;</span>
</pre>
<pclass="inwebparagraph">works safely because <codeclass="display"><spanclass="extract-syntax">@<Shake out multiples of n@></span></code> is, thanks to being a
code block, semantically a single statement.
</p>
<pclass="inwebparagraph">Finally, note that if there are no commentary or definitions attached to
the paragraph then it's not necessary to type the initial <codeclass="display"><spanclass="extract-syntax">@</span></code>. That is,
<spanclass="plain-syntax"></span><spanclass="function-syntax">@<Prepare to exit@> =</span>
</pre>
<pclass="inwebparagraph">...is not necessary, and it's sufficient to type just:
</p>
<preclass="display">
<spanclass="plain-syntax"></span><spanclass="function-syntax">@<Prepare to exit@> =</span>
</pre>
<pclass="inwebparagraph"><aid="SP6"></a><b>§6. Conditional compilation. </b>In some languages, especially C, it's very hard to write a program which will
run on multiple operating systems without some use of conditional compilation:
that is, putting some code or definitions inside <codeclass="display"><spanclass="extract-syntax">#ifdef</span></code> clauses or the like.
</p>
<pclass="inwebparagraph">Inweb can't alter this sad fact of life, but it can make the process tidier.
If a paragraph has the tag <codeclass="display"><spanclass="extract-syntax">^"ifdef-SYMBOL"</span></code>, then any material in it will
be tangled in such a way that it takes effect only if <codeclass="display"><spanclass="extract-syntax">SYMBOL</span></code> is defined.
For example, in a C-language web with the paragraph:
</p>
<preclass="display">
<spanclass="plain-syntax"></span><spanclass="function-syntax">@h</span><spanclass="plain-syntax"> Windows stuff. ^"ifdef-PLATFORM_WINDOWS"</span>
<pclass="inwebparagraph">...the definition of <codeclass="display"><spanclass="extract-syntax">THREADS_AVAILABLE</span></code> and the function <codeclass="display"><spanclass="extract-syntax">start_threads</span></code>
would be made only inside a <codeclass="display"><spanclass="extract-syntax">#ifdef PLATFORM_WINDOWS</span></code> clause; the same would
happen for any typedefs or <codeclass="display"><spanclass="extract-syntax">#include</span></code>s made.
</p>
<pclass="inwebparagraph">Similarly, tagging a paragraph <codeclass="display"><spanclass="extract-syntax">^"ifndef-SYMBOL"</span></code> causes it to have effect
only if <codeclass="display"><spanclass="extract-syntax">SYMBOL</span></code> is undefined. A paragraph can have any number of such
conditions applied to it, and if so then all of the conditions must be met.
</p>
<pclass="inwebparagraph">Note that since tags can be applied to entire sections of a web, at the
Contents listing, it's straightforward to give, say, two versions of a
section file, one with effect on MacOS, one with effect on Windows.
</p>
<pclass="inwebparagraph"><aid="SP7"></a><b>§7. Commentary. </b>The comment part of a paragraph is ignored by the tangler, and appears only
in weaves. For the most part, the text is simply copied over verbatim: but
Inweb quietly tries to improve the appearance of what it copies, and a
few special notations are allowed, to help with this.
</p>
<pclass="inwebparagraph"><aid="SP8"></a><b>§8. </b>A doubled hyphen becomes an em-rule; double-quotation marks automatically
smarten (in TeX format, at least).
</p>
<pclass="inwebparagraph"><aid="SP9"></a><b>§9. </b>Lines beginning with what look like bracketed list numbers or letters are
set as such, running on into little indented paragraphs. Thus
</p>
<preclass="display">
<spanclass="plain-syntax"> (a) Intellectual property has the shelf life of a banana. (Bill Gates)</span>
<spanclass="plain-syntax"> (b) He is the very pineapple of politeness! (Richard Brinsley Sheridan)</span>
<spanclass="plain-syntax"> (c) Harvard takes perfectly good plums as students, and turns them into</span>
</li><li>(a) Intellectual property has the shelf life of a banana. (Bill Gates)
</li><li>(b) He is the very pineapple of politeness! (Richard Brinsley Sheridan)
</li><li>(c) Harvard takes perfectly good plums as students, and turns them into
prunes. (Frank Lloyd Wright)
</li></ul>
<pclass="inwebparagraph">A line which begins <codeclass="display"><spanclass="extract-syntax">(...)</span></code> will be treated as a continuation of indented
matter (following on from some break-off such as a source quotation).
A line which begins <codeclass="display"><spanclass="extract-syntax">(-X)</span></code> will be treated as if it were <codeclass="display"><spanclass="extract-syntax">(X)</span></code>, but
<ulclass="items"><li>(d) Pick a song and sing a yellow nectarine. (Scott Weiland)
</p>
<pclass="inwebparagraph"><aid="SP10"></a><b>§10. </b>Text placed between vertical strokes will be set in a fixed-space, code
style font, <codeclass="display"><spanclass="extract-syntax">thus</span></code>. This paragraph appears in the web you are reading thus:
</p>
<preclass="display">
<spanclass="plain-syntax"></span><spanclass="function-syntax">@</span><spanclass="plain-syntax"> Text placed between vertical strokes will be set in a fixed-space, code</span>
<spanclass="plain-syntax"> style font, |thus|. This paragraph appears in the web you are reading thus:</span>
</pre>
<pclass="inwebparagraph">This notation may be inconvenient if you need the vertical stroke character
for something else, especially as the notation is used both in code comments
and in paragraph commentary. But both notations can be configured in the
Contents page of a web, thus:
</p>
<preclass="display">
<spanclass="element-syntax">Code In Code Comments Notation</span><spanclass="plain-syntax">:</span><spanclass="string-syntax"> Off</span>
<spanclass="element-syntax">Code In Commentary Notation</span><spanclass="plain-syntax">:</span><spanclass="string-syntax"> %%</span>
</pre>
<pclass="inwebparagraph">This example would turn off the feature in code comments, but allow it in
paragraph commentary; we would then need to write...
</p>
<preclass="display">
<spanclass="plain-syntax"></span><spanclass="function-syntax">@</span><spanclass="plain-syntax"> Text placed between vertical strokes will be set in a fixed-space, code</span>
<spanclass="plain-syntax"> style font, %%thus%%. This paragraph appears in the web you are reading thus:</span>
</pre>
<pclass="inwebparagraph"><aid="SP11"></a><b>§11. </b>A line written thus:
</p>
<preclass="display">
<spanclass="plain-syntax">>> The monkey carries the blue scarf.</span>
</pre>
<pclass="inwebparagraph">is typeset as an extract of text thus:
</p>
<blockquote>
<p>The monkey carries the blue scarf.</p>
</blockquote>
<pclass="inwebparagraph">(This is a feature used for Inform 7 "code" samples, those being essentially
natural language text.)
</p>
<pclass="inwebparagraph"><aid="SP12"></a><b>§12. Code samples and other extraneous matter. </b>When is code not code? When it's an extract of text being displayed for
documentation reasons, is the answer. We can include this like so:
</p>
<preclass="display">
<spanclass="plain-syntax"> = (text)</span>
<spanclass="plain-syntax"> Here is my sample bit of text.</span>
<spanclass="plain-syntax"> ...which is essential in order to restore the state of</span>
</pre>
<pclass="inwebparagraph"><aid="SP13"></a><b>§13. Links. </b>URLs in the web are automatically recognised and a weave to HTML will
make them into links. For example:
</p>
<preclass="display">
<spanclass="plain-syntax"> For further reading, see: https://en.wikipedia.org/wiki/How_to_Avoid_Huge_Ships</span>
</pre>
<pclass="inwebparagraph">For further reading, see: <ahref="https://en.wikipedia.org/wiki/How_to_Avoid_Huge_Ships"class="external">https://en.wikipedia.org/wiki/How_to_Avoid_Huge_Ships</a>
</p>
<pclass="inwebparagraph">Note that URLs are considered to continue to the next white space, so don't
end them with full stops or commas.
</p>
<pclass="inwebparagraph">URLs will also be recognised in any text extract marked as <codeclass="display"><spanclass="extract-syntax">hyperlinked</span></code>.
<pclass="inwebparagraph"><aid="SP14"></a><b>§14. Cross-references. </b>These are like links, but internal. These are normally written within <codeclass="display"><spanclass="extract-syntax">//</span></code>
signs and are only available in the commentary of a web. They allow us to
place cross-references like so:
</p>
<preclass="display">
<spanclass="plain-syntax"> To see how cross-references are implemented, see //Format Methods//,</span>
<spanclass="plain-syntax"> or more generally the whole of //Chapter 5//; to decipher the text,</span>
<spanclass="plain-syntax"> Inweb uses code from //foundation// at //foundation: Web Modules//.</span>
</pre>
<pclass="inwebparagraph">To see how cross-references are implemented, see <ahref="5-fm.html"class="internal">5-fm.html</a>,
or more generally the whole of <ahref="5-wt.html"class="internal">5-wt.html</a>; to decipher the text,
Inweb uses code from <ahref="../foundation-module/index.html"class="internal">../foundation-module/index.html</a> at <ahref="../foundation-module/8-wm.html"class="internal">../foundation-module/8-wm.html</a>.
</p>
<pclass="inwebparagraph">What happened in that last sentence is that Inweb noticed the following:
</p>
</li></ul>
<li>(a) "Format Methods" is the name of a section of code in the Inweb web;
</li><li>(b) The web also has a "Chapter 5";
</li><li>(c) It uses a module called "foundation";
</li><li>(d) And that module has a section called "Web Modules".
</li></ul>
<pclass="inwebparagraph">Inweb then made links accordingly. Chapters, which can be referred to either
numerically, link to the first section in them; modules likewise. Errors are
thrown if these references to sections are in any way ambiguous. They are not
case sensitive.
</p>
<pclass="inwebparagraph"><aid="SP15"></a><b>§15. </b>Sometimes we want to make a link without literally showing the destination.
This is simple: for example,
</p>
<preclass="display">
<spanclass="plain-syntax"> First //the program has to configure itself -> Configuration//, then...</span>
then..."; the text "the program has to configure itself" links to <ahref="1-cnf.html"class="internal">1-cnf.html</a>.
</p>
<pclass="inwebparagraph"><aid="SP16"></a><b>§16. </b>It's also possible to reference function names and type names, provided that
the language definition supports these (see <ahref="M-spl.html"class="internal">M-spl.html</a>):
this is certainly the case for C-like languages. For example,
</p>
<preclass="display">
<spanclass="plain-syntax"> Individual lines of a web are stored in //source_line// structures,</span>
<spanclass="plain-syntax"> and mostly created by //Reader::read_file//.</span>
</pre>
<pclass="inwebparagraph">produces: Individual lines of a web are stored in <ahref="2-lc.html#SP1"class="internal">2-lc.html#SP1</a> structures,
and mostly created by <ahref="2-tr.html#SP6"class="internal">2-tr.html#SP6</a>. And that should link to the
structure definition and function of these names inside the Inweb program.
</p>
<pclass="inwebparagraph">Lastly, cross-references can even be made to webs quite separate from the
current one, but this requires the use of a Colony file.
See <ahref="M-mwiw.html"class="internal">M-mwiw.html</a>.
</p>
<pclass="inwebparagraph"><aid="SP17"></a><b>§17. </b>Cross-references also work inside text extracts marked as <codeclass="display"><spanclass="extract-syntax">hyperlinked</span></code>.
<spanclass="plain-syntax"> See the //Manual// for more on this.</span>
<spanclass="plain-syntax"> =</span>
</pre>
<pclass="inwebparagraph">produces:
</p>
<preclass="display">
<spanclass="plain-syntax"> See the </span><ahref="M-iti.html"class="internal">M-iti.html</a><spanclass="plain-syntax"> for more on this.</span>
</pre>
<pclass="inwebparagraph"></p>
<pclass="inwebparagraph">This notation may be inconvenient if you need <codeclass="display"><spanclass="extract-syntax">//</span></code> for something else, but it
can be configured in the Contents page of a web, say like so:
<pclass="inwebparagraph"><aid="SP18"></a><b>§18. Figures. </b>Images to be included in weaves of a web are called "Figures", as they
would be in a printed book. These images should ideally be in PNG, JPG or PDF
format and placed in a subdirectory of the web called <codeclass="display"><spanclass="extract-syntax">Figures</span></code>: for instance,
the weaver would seek <codeclass="display"><spanclass="extract-syntax">Fig_2_3.pdf</span></code> at pathname <codeclass="display"><spanclass="extract-syntax">Figures/Fig_2_3.pdf</span></code>.
</p>
<pclass="inwebparagraph">To embed an image, we write like so:
<pclass="inwebparagraph">The YouTube ID number <codeclass="display"><spanclass="extract-syntax">GR3aImy7dWw</span></code> can be read from its Share URL, which in
this case was <codeclass="display"><spanclass="extract-syntax">https://youtu.be/GR3aImy7dWw</span></code>.
</p>
<pclass="inwebparagraph">Similarly for Vimeo:
</p>
<preclass="display">
<spanclass="plain-syntax"> = (embedded Vimeo video 204519)</span>
<pclass="inwebparagraph"><aid="SP20"></a><b>§20. </b>Adding width and height is straightforward; by default the dimensions are
720 by 405.
</p>
<preclass="display">
<spanclass="plain-syntax"> = (embedded Vimeo video 204519 at 400 by 300)</span>
<spanclass="plain-syntax"> = (embedded SoundCloud audio 42803139 at 200)</span>
</pre>
<pclass="inwebparagraph">The latter sets just the height (of the displayed waveform, that is —
arguably music has width and not height, but SoundCloud thinks otherwise).
</p>
<pclass="inwebparagraph"><aid="SP21"></a><b>§21. </b>It's easy to add services. These are all handled by using prototype code
for a suitable HTML <codeclass="display"><spanclass="extract-syntax"><iframe></span></code>, and those prototypes are stored in the
<codeclass="display"><spanclass="extract-syntax">Embedding</span></code> subdirectory of the Inweb installation. But you can use your
own prototypes instead, by creating an <codeclass="display"><spanclass="extract-syntax">Embedding</span></code> subdirectory of your own
web; this overrides the ones built in. If your service is, say, <codeclass="display"><spanclass="extract-syntax">WebTubeo</span></code>,
then the file would be <codeclass="display"><spanclass="extract-syntax">W/Embedding/WebTubeo.html</span></code>.
</p>
<pclass="inwebparagraph"><aid="SP22"></a><b>§22. Mathematics notation. </b>Literate programming is a good technique to justify code which hangs on
unobvious pieces of mathematics or computer science, and which must therefore
be explained carefully. Formulae or equations are a real convenience for that.
</p>
<pclass="inwebparagraph">For example, it's known that the average running time of Euclid's GCD
algorithm on \(a\) and numbers coprime to \(a\) is:
<pclass="inwebparagraph">(This is always <codeclass="display"><spanclass="extract-syntax">On</span></code>, the default, or <codeclass="display"><spanclass="extract-syntax">Off</span></code>.)
</p>
<pclass="inwebparagraph"><aid="SP23"></a><b>§23. Footnotes. </b>Not everyone likes footnotes,<supid="fnref:1"><ahref="#fn:1"rel="footnote">1</a></sup> but sometimes they're a tidy way to make
<ulclass="footnotetexts"><liclass="footnote"id="fn:1"><pclass="inwebfootnote"><supid="fnref:1"><ahref="#fn:1"rel="footnote">1</a></sup> But see Anthony Grafton, "The Footnote: A Curious History" (Harvard
University Press, 1999).
<ahref="#fnref:1"title="return to text">↩</a></p></li><liclass="footnote"id="fn:2"><pclass="inwebfootnote"><supid="fnref:2"><ahref="#fn:2"rel="footnote">2</a></sup> For example, to cite Donald Knuth, "Evaluation of Porter's constant",
Computers & Mathematics with Applications, 2, 137-39 (1976).
<ahref="#fnref:2"title="return to text">↩</a></p></li></ul><pclass="inwebparagraph"><aid="SP24"></a><b>§24. </b>The content of that sentence was typed as follows:
</p>
<preclass="display">
<spanclass="plain-syntax"> Not everyone likes footnotes,[1] but sometimes they're a tidy way to make</span>
<spanclass="plain-syntax"> references.[2]</span>
<spanclass="plain-syntax"> [1] But see Anthony Grafton, "The Footnote: A Curious History" (Harvard</span>
<spanclass="plain-syntax"> University Press, 1999).</span>
<spanclass="plain-syntax"> [2] For example, to cite Donald Knuth, "Evaluation of Porter's constant",</span>
<spanclass="plain-syntax"> Computers & Mathematics with Applications, 2, 137-39 (1976).</span>
</pre>
<pclass="inwebparagraph">Note that footnotes should be numbered upwards from 1 in each individual
paragraph; Inweb automatically renumbers them for each woven section, but
we don't have to worry about that when typing.
</p>
<pclass="inwebparagraph">If you're reading this as a web page (with Javascript on), then you should
have seen clickable footnote blobs, which reveal the text. If Javascript is
off, there's a more conventionally textual presentation.
</p>
<pclass="inwebparagraph">These blob-footnotes are fine for snarky asides or quick references, but long
discursive notes need more space, so if you intend to use those then you
should probably turn this rendering off altogether:
<pclass="inwebparagraph">Footnotes are otherwise rendered by the <codeclass="display"><spanclass="extract-syntax">Bigfoot</span></code> plugin, which is the default
value of this; its big feet unfortunately tread on the <codeclass="display"><spanclass="extract-syntax">MathJax3</span></code> plugin, so
right now it's not possible to have mathematics in a footnote when <codeclass="display"><spanclass="extract-syntax">Bigfoot</span></code>
is in use.
</p>
<pclass="inwebparagraph"><aid="SP25"></a><b>§25. </b>Once again, notation may be an issue, and so it's controllable. By default,
<pclass="inwebparagraph">would be sensible. The "cue" between these notations is required to be a
string of digits; each must occur just once in its section; and each must
have a text and a cue which match up correctly.
</p>
<hrclass="tocbar">
<ulclass="toc"><li><ahref="M-wtaw.html">Back to 'Webs, Tangling and Weaving'</a></li><li><ahref="M-mwiw.html">Continue with 'Making Weaves into Websites'</a></li></ul><hrclass="tocbar">
