[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] Important fix and HTML markup improvements



The current draft says:
> 5. An unprefixed ( . e) MUST evaluate as e.

s/MUST evaluate as/MUST be read as/

I've attached a patch which fixes this, and also improves the HTML
markup.  Most notably, I converted many VAR elements to CODE elements,
e.g. every occurrence of $nfx$ and $bracket-apply$, since these are not
variables for purposes of this specification, but rather constant
symbols.

I used VAR for symbols that can stand for any of a set of expressions
(e.g. 'e', 'e1', and 'e2' in the n-expression spec), which I believe is
a more appropriate use of VAR.  I also tried to use CODE and SAMP where
appropriate, and avoided marking ellipses with either one.

What do you think?

    Regards,
      Mark


--- srfi-105.html	2012-10-30 23:50:56.694669579 -0400
+++ srfi-105-new.html	2012-10-31 04:55:27.762946812 -0400
@@ -92,13 +92,13 @@
 maps cleanly to
 <samp>(+&nbsp;x&nbsp;(*&nbsp;y&nbsp;z))</samp>.
 Forms with mixed infix operators and other complications have
-&#8220;<var>$nfx$</var>&#8221; prepended to
+&#8220;<code>$nfx$</code>&#8221; prepended to
 enable later macro processing, e.g.,
 <samp>{4&nbsp;+&nbsp;5&nbsp;*&nbsp;6}</samp> &#8658;
 <samp>($nfx$&nbsp;4&nbsp;+&nbsp;5&nbsp;*&nbsp;6)</samp>.
 Also, inside a curly-infix list (recursively),
-expressions of the form <samp>f(...)</samp> are simply
-an abbreviation for <samp>(f&nbsp;...)</samp>.</p>
+expressions of the form <code><var>f</var>(</code>...<code>)</code> are simply
+an abbreviation for <code>(<var>f</var>&nbsp;</code>...<code>)</code>.</p>
 
 <p>Note that this is derived from the
 &#8220;<a href="http://readable.sourceforge.net/";>readable</a>&#8221;
@@ -151,9 +151,9 @@
 the <em>simple</em> curly-infix list,
 a list whose visual presentation is in infix order instead of prefix order.
 The simple curly-infix list
-<samp>{operand-1 operator operand-2 operator operand-3 operator ...}</samp>
+<samp>{<var>operand-1</var> <var>operator</var> <var>operand-2</var> <var>operator</var> <var>operand-3</var> <var>operator</var> </samp>...<samp>}</samp>
 is mapped to
-<samp>(operator operand-1 operand-2 operand-3 ...)</samp> so that two or
+<samp>(<var>operator</var> <var>operand-1</var> <var>operand-2</var> <var>operand-3</var> </samp>...<samp>)</samp> so that two or
 more operands are handled cleanly.
 E.g., <samp>{a&nbsp;+&nbsp;b&nbsp;+&nbsp;c}</samp> &#8658;
 <samp>(+&nbsp;a&nbsp;b&nbsp;c)</samp>.</p>
@@ -195,11 +195,11 @@
 <ol>
 <li>A <dfn>simple</dfn> curly-infix list has an odd number of
 parameters, at least three parameters, and all even parameters are
-&#8220;<var>equal?</var>&#8221;.
+&#8220;<code>equal?</code>&#8221;.
 If there is more than one even parameter, and
 an even parameter contains a cycle, then
-the <var>equal?</var> comparison <em>MUST</em> terminate
-if <var>equal?</var> terminates (otherwise
+the <code>equal?</code> comparison <em>MUST</em> terminate
+if <code>equal?</code> terminates (otherwise
 the comparison <em>MAY</em> terminate).
 A simple curly-infix list is mapped by
 the reader into a list with the first even parameter
@@ -211,26 +211,26 @@
 <samp>{4&nbsp;*&nbsp;5&nbsp;*&nbsp;6}</samp> &#8658;
 <samp>(*&nbsp;4&nbsp;5&nbsp;6)</samp>.</li>
 <li>The <dfn>empty</dfn> curly-infix list
-<samp>{}</samp> is mapped to the empty list <samp>()</samp>.
+<code>{}</code> is mapped to the empty list <code>()</code>.
 An implementation <em>MUST</em> permit, and not require,
 whitespace between the braces in an empty curly-infix list.</li>
 <li>An <dfn>escaping</dfn> curly-infix list
-<samp>{e}</samp> is mapped to <samp>e</samp>.
+<code>{<var>e</var>}</code> is mapped to <code><var>e</var></code>.
 E.g., <samp>{5}</samp> is mapped to <samp>5</samp>.</li>
 <li>A <dfn>unary-operation</dfn> curly-infix list
-<samp>{e1&nbsp;e2}</samp>
+<code>{<var>e1</var>&nbsp;<var>e2</var>}</code>
 is mapped to
-<samp>(e1&nbsp;e2)</samp>.
+<code>(<var>e1</var>&nbsp;<var>e2</var>)</code>.
 E.g.,
 <samp>{-&nbsp;x}</samp> &#8658;
 <samp>(-&nbsp;x)</samp>.</li>
 <li>The mapping of a curly-infix list beginning with the symbol
-&#8220;<var>.</var>&#8221; is unspecified.
+&#8220;<code>.</code>&#8221; is unspecified.
 (Note: the reference implementation maps
-<samp>{.&nbsp;e}</samp> to <samp>e</samp>.)
+<code>{.&nbsp;<var>e</var>}</code> to <code><var>e</var></code>.)
 </li>
 <li>Any other curly-infix list (including all other improper lists) is
-<dfn>mixed</dfn>.  A mixed curly-infix list <em>MUST</em> be mapped to that list with &#8220;<var>$nfx$</var>&#8221; added to its front.
+<dfn>mixed</dfn>.  A mixed curly-infix list <em>MUST</em> be mapped to that list with &#8220;<code>$nfx$</code>&#8221; added to its front.
 E.g.,
 <samp>{q&nbsp;+&nbsp;r&nbsp;*&nbsp;s}</samp>
 is mapped to
@@ -271,8 +271,8 @@
 </p>
 <ol>
 <li>
-<samp>e(...)</samp> &#8658;
-<samp>(e&nbsp;...)</samp>.
+<code><var>e</var>(</code>...<code>)</code> &#8658;
+<code>(<var>e</var>&nbsp;</code>...<code>)</code>.
 E.g.,
 <samp>cos(x)</samp> &#8658;
 <samp>(cos&nbsp;x)</samp>,
@@ -283,11 +283,11 @@
 <samp>read(.&nbsp;options)</samp> &#8658;
 <samp>(read&nbsp;.&nbsp;options)</samp>.</li>
 <li>
-<samp>e{}</samp> &#8658; <samp>(e)</samp>
+<code><var>e</var>{}</code> &#8658; <code>(<var>e</var>)</code>
 when there are zero or more whitespace characters
 within the braces;
 otherwise,
-<samp>e{...}</samp> &#8658; <samp>(e&nbsp;{...})</samp>.
+<code><var>e</var>{</code>...<code>}</code> &#8658; <code>(<var>e</var>&nbsp;{</code>...<code>})</code>.
 E.g.,
 <samp>f{n&nbsp;-&nbsp;1}</samp>
 &#8658;
@@ -298,12 +298,12 @@
 <samp>g{-&nbsp;x}</samp>
 &#8658;
 <samp>(g&nbsp;(-&nbsp;x))</samp>.</li>
-<li><samp>e[...]</samp> &#8658;
-<samp>($bracket-apply$&nbsp;e&nbsp;...)</samp></li>
+<li><code><var>e</var>[</code>...<code>]</code> &#8658;
+<code>($bracket-apply$&nbsp;<var>e</var>&nbsp;</code>...<code>)</code></li>
 <li>The above mappings <em>MUST NOT</em> be applied
 if one or more whitespace characters are present between e and the open
 paired character.</li>
-<li>An unprefixed <samp>(&nbsp;.&nbsp;e)</samp> <em>MUST</em> evaluate as <samp>e</samp>.</li>
+<li>An unprefixed <code>(&nbsp;.&nbsp;<var>e</var>)</code> <em>MUST</em> be read as <code><var>e</var></code>.</li>
 <li>
 These <em>MUST</em> recurse within lists and vectors,
 so any list or vector
@@ -515,8 +515,8 @@
 
 <p>
 An implementation of this SRFI <em>MUST</em> accept
-the marker <var>#!curly-infix</var> followed by a whitespace character
-in its standard datum readers (e.g., <var>read</var> and, if applicable,
+the marker <code>#!curly-infix</code> followed by a whitespace character
+in its standard datum readers (e.g., <code>read</code> and, if applicable,
 the default implementation REPL).
 This marker (including the trailing whitespace character)
 <em>MUST</em> be consumed and considered whitespace.
@@ -542,13 +542,13 @@
 <p>
 An implementation <em>MUST NOT</em>
 bind the symbols
-&#8220;<var>$nfx$</var>&#8221; or
-&#8220;<var>$bracket-apply$</var>&#8221;
+&#8220;<code>$nfx$</code>&#8221; or
+&#8220;<code>$bracket-apply$</code>&#8221;
 by default to a procedure, macro, or syntax
 that <em>cannot</em> be overridden.
 An implementation <em>SHOULD NOT</em> bind the symbols
-&#8220;<var>$nfx$</var>&#8221; or
-&#8220;<var>$bracket-apply$</var>&#8221;
+&#8220;<code>$nfx$</code>&#8221; or
+&#8220;<code>$bracket-apply$</code>&#8221;
 to a procedure, macro, or syntax in the
 default environment, with the exception that it
 <em>MAY</em> bind them by default to something that produces an error.
@@ -562,16 +562,16 @@
 <em>However</em>, an implementation <em>MAY</em>
 provide one or more
 <em>libraries</em> that when imported
-bind the &#8220;<var>$nfx$</var>&#8221; and/or
-&#8220;<var>$bracket-apply$</var>&#8221;
+bind the &#8220;<code>$nfx$</code>&#8221; and/or
+&#8220;<code>$bracket-apply$</code>&#8221;
 symbols
 (as it is then a library, this case actually falls under
 the &#8220;reserved for use by library writers&#8221; clause above).
 Application writers and other library writers
 using that implementation are then free to use or not use
 the implementation&#8217;s provided
-&#8220;<var>$nfx$</var>&#8221; and/or
-&#8220;<var>$bracket-apply$</var>&#8221;
+&#8220;<code>$nfx$</code>&#8221; and/or
+&#8220;<code>$bracket-apply$</code>&#8221;
 as provided by those libraries.
 </p>
 
@@ -613,13 +613,13 @@
 
 <h2><a name="rationale_changereader">Why not macros? Why modify the reader?</a></h2>
 <p>Many previous systems have implemented &#8220;infix&#8221;
-systems as a named macro or procedure (e.g., <var>INFIX</var>).
+systems as a named macro or procedure (e.g., <code>INFIX</code>).
 This looks ugly, and it does the wrong thing &#8212; the resulting list
-always has <var>INFIX</var> at the beginning,
+always has <code>INFIX</code> at the beginning,
 not the actual infix operator, so this
 approach can interfere with quoting, macros, and other capabilities.
 In particular,
-consider the following <var>syntax-rules</var> macro
+consider the following <code>syntax-rules</code> macro
 for function composition:
 </p>
 <pre>
@@ -637,10 +637,10 @@
 <samp>{f&nbsp;o&nbsp;g&nbsp;o&nbsp;h&nbsp;o&nbsp;...}</samp>
 &#8658; <samp>(o&nbsp;f&nbsp;g&nbsp;h&nbsp;...)</samp>.
 Infix cannot be implemented as a macro alone,
-as the <var>syntax-rules</var> form has
+as the <code>syntax-rules</code> form has
 a particular treatment for the pattern.
 A macro for infix would very likely confuse
-the <var>syntax-rules</var> form.
+the <code>syntax-rules</code> form.
 </p>
 <p>
 A reader notation that
@@ -714,12 +714,12 @@
 </p>
 
 <p>
-It&#8217;s true that {...} are often used in math for set notation. But
+It&#8217;s true that <code>{</code>...<code>}</code> are often used in math for set notation. But
 infix notation is far more basic, and common, than sets.
 Also, traditional function call notation and infix are helpful when working
 with sets, so infix notation is the more important need.
 Once you allow neoteric-expressions,
-the notation set(...) is a reasonable alternative.
+the notation <code>set(</code>...<code>)</code> is a reasonable alternative.
 </p>
 
 <h2><a name="rationale_notdifferentsyntax">Why not use a completely different notation inside the expression?</a></h2>
@@ -756,7 +756,7 @@
 but this turns out to not work well. It&#8217;s hard to express
 good rules for detecting infix operators, and the rules become too
 complex for users (e.g., &#8220;punctuation-only symbols&#8221;
-doesn&#8217;t detect &#8220;<var>and</var>&#8221; or &#8220;<var>or</var>&#8221;).
+doesn&#8217;t detect &#8220;<code>and</code>&#8221; or &#8220;<code>or</code>&#8221;).
 And in
 any case, if they were automatically detected, an escape mechanism
 would be needed anyway -
@@ -773,15 +773,15 @@
 infix, use <code>{</code>...<code>}</code>.</p>
 
 
-<h2><a name="rationale_equal">Why use <var>equal?</var> to compare operators in a &#8220;simple&#8221; curly-infix-list for equality?</a></h2>
+<h2><a name="rationale_equal">Why use <code>equal?</code> to compare operators in a &#8220;simple&#8221; curly-infix-list for equality?</a></h2>
 <p>
-Operators are compared using <var>equal?</var> so that
+Operators are compared using <code>equal?</code> so that
 constructs like <samp>,op</samp> are legal operators,
 e.g., <samp>{x&nbsp;,op&nbsp;y&nbsp;,op&nbsp;z}</samp>.
 Note that unfortunately if the operator construct contains a cycle, it might not terminate
-if <var>equal?</var> does not terminate in the presence of cycles.
+if <code>equal?</code> does not terminate in the presence of cycles.
 This was specified this way so that implementers
-could use the normal Scheme <var>equal?</var> comparison instead of
+could use the normal Scheme <code>equal?</code> comparison instead of
 having to implement a special comparison operator just for this
 particular case.
 </p>
@@ -845,7 +845,7 @@
 We also ensure that the notation is clearly homoiconic.</p>
 <p>Instead, where precedence is desired, application and library writers
 can implement precedence by defining and controlling the scope of an
-&#8220;<var>$nfx$</var>&#8221; macro or procedure, or by later postprocessing
+&#8220;<code>$nfx$</code>&#8221; macro or procedure, or by later postprocessing
 of that symbol.
 Scheme macros are already quite powerful and capable of handling this;
 in these cases, <code>{</code>...<code>}</code> provides a more
@@ -861,9 +861,9 @@
 This does not lead to hard-to-read expressions, however.
 Examples of simple curly-infix lists combining infix and unary operations
 include
-<code>{-(x)&nbsp;*&nbsp;-(y)}</code>
+<samp>{-(x)&nbsp;*&nbsp;-(y)}</samp>
 and
-<code>{-{x}&nbsp;*&nbsp;-{y}}</code>
+<samp>{-{x}&nbsp;*&nbsp;-{y}}</samp>
 (the notation is designed so that both work).
 </p>
 
@@ -871,7 +871,7 @@
 who started this project,
 considered reporting an error if a simple infix
 expression isn&#8217;t provided.
-However, prepending &#8220;<var>$nfx$</var>&#8221;
+However, prepending &#8220;<code>$nfx$</code>&#8221;
 is much more flexible.</p>
 
 <h2><a name="rationale_precedence_addable">Could precedence be added?</a></h2>
@@ -893,7 +893,7 @@
 Here is an example of such an extension, called a &#8220;math&#8221; extension.
 In this extension, if a mixed curly-infix list is seen,
 it first attempts to apply the &#8220;math&#8221; ruleset, and only
-prepends &#8220;$nfx$&#8221; if it does not meet the requirements.  In this extension:
+prepends &#8220;<code>$nfx$</code>&#8221; if it does not meet the requirements.  In this extension:
 </p>
 <ol>
 <li>All even-numbered parameters must be symbols, there must be an odd number of parameters, and there must be at least five parameters (the minimum to have more than one operator).
@@ -909,17 +909,17 @@
 an operator of the precedence table; that new symbol is then compared to
 the table.
 This allows the use of many more operators, e.g.,
-&#8220;char-ci&lt;=?&#8221; would be considered an operator with the
-same precedence as &#8220;&lt;=&#8221;.
+&#8220;<samp>char-ci&lt;=?</samp>&#8221; would be considered an operator with the
+same precedence as &#8220;<samp>&lt;=</samp>&#8221;.
 If there&#8217;s still no match for any operator,
 the expression does not meet the &#8220;math&#8221; ruleset, and
-the normal mixed rules are used (<var>$nfx$</var> is inserted at the front).
+the normal mixed rules are used (<code>$nfx$</code> is inserted at the front).
 </li>
 <li>
-When the same operator is repeated, the operator simply gains another operand, so {a + b + c * d} is the &#8220;+&#8221; operator applied to three operands: a, b, and (* c d).
+When the same operator is repeated, the operator simply gains another operand, so <samp>{a&nbsp;+&nbsp;b&nbsp;+&nbsp;c&nbsp;*&nbsp;d}</samp> is the &#8220;<code>+</code>&#8221; operator applied to three operands: <samp>a</samp>, <samp>b</samp>, and <samp>(*&nbsp;c&nbsp;d)</samp>.
 </li>
 <li>
-Other different operators of the same precedence are interpreted in left-to-right order, so {a + b - c} maps to {{a + b} - c}.
+Other different operators of the same precedence are interpreted in left-to-right order, so <samp>{a&nbsp;+&nbsp;b&nbsp;-&nbsp;c}</samp> maps to <samp>{{a&nbsp;+&nbsp;b}&nbsp;-&nbsp;c}</samp>.
 </li>
 </ol>
 
@@ -927,7 +927,7 @@
 But there would be substantial arguments about the semantics of
 any precedence system.
 For example, should there be support for combining different ranged
-comparisons, to support notations such as {a &lt; b &lt;= c}?
+comparisons, to support notations such as <samp>{a&nbsp;&lt;&nbsp;b&nbsp;&lt;=&nbsp;c}</samp>?
 Should some operators be right-associative, and if so, which ones?
 There would also be substantial disagreement on exactly what operators
 should be in the precedence table (including which combinations and if
@@ -940,23 +940,23 @@
 would be challenging to get agreement on such a list:
 </p>
 <ol>
-<li>Subscript/down-arrow: sub {Unicode: &#8595;, &#8659;}</li>
-<li>Exponentiation/superscript/up-arrow: exp..., **, ^, sup {Unicode: &#8593;, &#8657;}</li>
-<li>Multiplication/division: *, /, div..., mod..., quo...   {Unicode: &#247;, &#215;}</li>
-<li>Addition/subtraction: +, -</li>
-<li>Bitwise and: bit...and, log...and, &amp;</li>
-<li>Bitwise or/xor: bit...or, log...or, |</li>
+<li>Subscript/down-arrow: <code>sub</code> {Unicode: &#8595;, &#8659;}</li>
+<li>Exponentiation/superscript/up-arrow: <code>exp</code>..., <code>**</code>, <code>^</code>, <code>sup</code> {Unicode: &#8593;, &#8657;}</li>
+<li>Multiplication/division: <code>*</code>, <code>/</code>, <code>div</code>..., <code>mod</code>..., <code>quo</code>...   {Unicode: &#247;, &#215;}</li>
+<li>Addition/subtraction: <code>+</code>, <code>-</code></li>
+<li>Bitwise and: <code>bit...and</code>, <code>log...and</code>, <code>&amp;</code></li>
+<li>Bitwise or/xor: <code>bit...or</code>, <code>log...or</code>, <code>|</code></li>
 <li>Comparison:
 <ul>
 <li>
-Ranged: &lt; , &lt;= , &gt;=, &gt;  {Unicode: &#8805;, &#8804;, &#8715;, &#8713;, &#8836;, &#8834;, &#8838;, &#8835;, &#8839;}
+Ranged: <code>&lt;</code> , <code>&lt;=</code> , <code>&gt;=</code>, <code>&gt;</code>  {Unicode: &#8805;, &#8804;, &#8715;, &#8713;, &#8836;, &#8834;, &#8838;, &#8835;, &#8839;}
 </li>
-<li>Unranged:  =, ==, !=, &lt;&gt;, =/=, eq..., in, is {Unicode: &#8800;, &#8776;, &#8773;}</li>
+<li>Unranged:  <code>=</code>, <code>==</code>, <code>!=</code>, <code>&lt;&gt;</code>, <code>=/=</code>, <code>eq</code>..., <code>in</code>, <code>is</code> {Unicode: &#8800;, &#8776;, &#8773;}</li>
 </ul>
-<li>Logical conjunction: and {Unicode: &#8745;, &#8743;}</li>
-<li>Logical/exclusive disjunction: or, xor, eor {Unicode: &#8746;, &#8744;, &#8853;}</li>
-<li>Implication/right arrows/doubled arrows: -&gt;, =&gt;,  &lt;-&gt;, &lt;=&gt;, --&gt;, ==&gt;, &lt;--&gt;, &lt;==&gt; {Unicode: &#8596;, &#8660;, &#8594;, &#8658;}</li>
-<li>Definition/assignment/left arrow: &lt;-, &lt;--, &lt;==, :=, ::=  {Unicode: &#8801;, &#8592;, &#8656;}</li>
+<li>Logical conjunction: <code>and</code> {Unicode: &#8745;, &#8743;}</li>
+<li>Logical/exclusive disjunction: <code>or</code>, <code>xor</code>, <code>eor</code> {Unicode: &#8746;, &#8744;, &#8853;}</li>
+<li>Implication/right arrows/doubled arrows: <code>-&gt;</code>, <code>=&gt;</code>,  <code>&lt;-&gt;</code>, <code>&lt;=&gt;</code>, <code>--&gt;</code>, <code>==&gt;</code>, <code>&lt;--&gt;</code>, <code>&lt;==&gt;</code> {Unicode: &#8596;, &#8660;, &#8594;, &#8658;}</li>
+<li>Definition/assignment/left arrow: <code>&lt;-</code>, <code>&lt;--</code>, <code>&lt;==</code>, <code>:=</code>, <code>::=</code>  {Unicode: &#8801;, &#8592;, &#8656;}</li>
 </ol>
 
 <p>
@@ -965,11 +965,11 @@
 A &#8220;simple math&#8221; ruleset could be devised instead,
 e.g., perhaps it has a shorter list of built-in operators.
 The extant code using curly-infix tends to combine these:
-*, /; +, -; &lt; , &lt;= , &gt;=, &gt;, =, &lt;&gt;, eq...;
-<var>and</var>; and <var>or</var>;
-adding exponentiation (e.g., ** and exp...) at a higher precedence level,
-and implication (e.g., -&gt; and =&gt;) would make sense for a short list.
-(The &lt;&gt; isn&#8217;t in many Scheme specifications, but it is odd to omit
+<code>*</code>, <code>/</code>; <code>+</code>, <code>-</code>; <code>&lt;</code> , <code>&lt;=</code> , <code>&gt;=</code>, <code>&gt;</code>, <code>=</code>, <code>&lt;&gt;</code>, <code>eq</code>...;
+<code>and</code>; and <code>or</code>;
+adding exponentiation (e.g., <code>**</code> and <code>exp</code>...) at a higher precedence level,
+and implication (e.g., <code>-&gt;</code> and <code>=&gt;</code>) would make sense for a short list.
+(The <code>&lt;&gt;</code> isn&#8217;t in many Scheme specifications, but it is odd to omit
 it from a precedence list.)
 </p>
 
@@ -978,7 +978,7 @@
 one (such as these) could be added later.
 If a precedence system were added, all existing code using simple
 curly-infix expressions, or 0..2 parameter expressions, would work unchanged.
-Even when it&#8217;s not, many &#8220;$nfx$&#8221; processors would likely generate the
+Even when it&#8217;s not, many &#8220;<code>$nfx$</code>&#8221; processors would likely generate the
 same order in most actual cases.
 Since it would be difficult to gain such agreement, and the value of
 such a system is doubtful, it is better to provide a much simpler
@@ -986,21 +986,21 @@
 Again, any support for precedence is an extension beyond this SRFI.
 </p>
 
-<h2><a name="rationale_nfx_undefined">Why is $nfx$ not predefined?</a></h2>
-<p>Implementations should not predefine a meaning for <i>$nfx$</i>,
+<h2><a name="rationale_nfx_undefined">Why is <code>$nfx$</code> not predefined?</a></h2>
+<p>Implementations should not predefine a meaning for <code>$nfx$</code>,
 other than possibly to something that always produces an error
 (e.g., raises an exception).
 </p>
 <p>
-If anyone wrote code that depended on some local implementation of $nfx$,
+If anyone wrote code that depended on some local implementation of <code>$nfx$</code>,
 then by definition it would become implementation-dependent.
-Yet the point of the &#8220;$nfx$&#8221; macro is to allow application authors
+Yet the point of the &#8220;<code>$nfx$</code>&#8221; macro is to allow application authors
 the ability to control what to do in that case,
 not to make them unwittingly dependent on an implementation.
 </p>
 <p>
 Of course, an implementation could provide a pre-canned macro that could
-be used as a definition of $nfx$.  But in that case, importing the
+be used as a definition of <code>$nfx$</code>.  But in that case, importing the
 library would be an explicit act,
 easily seen in the code, instead of being hidden.
 That way, it is easy to determine when an implementation-dependent
@@ -1027,7 +1027,7 @@
 is equivalent to
 <samp>(+&nbsp;a&nbsp;b)</samp>.
 It ensures that the neoteric-expression
-<samp>f{x}</samp> becomes the likely-intended <samp>(f x)</samp>.
+<samp>f{x}</samp> becomes the likely-intended <samp>(f&nbsp;x)</samp>.
 It makes it easy to use prefix notation; e.g.,
 <samp>{&nbsp;f(x)&nbsp;}</samp> is another way to write
 <samp>(f&nbsp;x)</samp>.
@@ -1059,7 +1059,7 @@
 </pre>
 
 
-<h2><a name="rationale_marker">Why a marker starting with <var>#!</var> and a letter?</a></h2>
+<h2><a name="rationale_marker">Why a marker starting with <code>#!</code> and a letter?</a></h2>
 
 <p>
 We would like implementations to always have curly-infix enabled.
@@ -1072,13 +1072,13 @@
 </p>
 
 <p>
-The <var>#!</var> marker prefix was suggested due to its similarity
+The <code>#!</code> marker prefix was suggested due to its similarity
 to other markers.
 After all, R6RS and R7RS (draft 6) already use
-<var>#!fold-case</var> and <var>#!no-fold-case</var>
+<code>#!fold-case</code> and <code>#!no-fold-case</code>
 as special markers to control the reader.
 Using another marker beginning with
-<var>#!</var> and a letter allows for a simple, similar-looking marker
+<code>#!</code> and a letter allows for a simple, similar-looking marker
 for a similar situation.
 What&#8217;s more, it implies a reasonable convention for reader extensions:
 markers that begin with <code>#!</code>, followed by an ASCII letter, should
@@ -1096,9 +1096,9 @@
 </p>
 
 <p>
-This marker need not interfere with other uses of <var>#!</var>.
+This marker need not interfere with other uses of <code>#!</code>.
 <a href="http://srfi.schemers.org/srfi-22/srfi-22.html";>SRFI-22</a> supports
-<var>#!</var>
+<code>#!</code>
 followed by space as a comment to the end of the line; this is supported
 by several implementations, but this is easily distinguished from this
 marker by the space.
@@ -1106,26 +1106,26 @@
 <code>#!</code>...<code>!#</code>
 as a multi-line comment, enabling scripts with mixed languages and
 multi-line arguments.
-But in practice the <var>#!</var> is almost always
+But in practice the <code>#!</code> is almost always
 followed immediately by <code>/</code> or <code>.</code>, and other scripts
 could be trivially fixed to make that so.
 R6RS had a non-normative recommendation to ignore a line that began
-with <var>#!/usr/bin/env</var> (without a space), as well
-as a <var>#!&nbsp;/usr/bin/env</var> (with a space before the slash),
+with &#8220;<code>#!/usr/bin/env</code>&#8221; (without a space), as well
+as &#8220;<code>#!&nbsp;/usr/bin/env</code>&#8221; (with a space before the slash),
 but this is non-normative;
-an implementation could easily implement <var>#!</var> followed by space
-as an ignored line, and treat <var>#!</var> followed by
+an implementation could easily implement <code>#!</code> followed by space
+as an ignored line, and treat <code>#!</code> followed by
 <code>/</code> or <code>.</code> differently.
 Thus, implementations could trivially support (simultaneously) markers
-beginning with <var>#!</var> followed by a letter
+beginning with <code>#!</code> followed by a letter
 (such as the one to identify curly-infix),
-the SRFI-22 <var>#!</var>+space marker as an ignored line,
-and the format <var>#!/&nbsp;...!#</var> and <var>#!.&nbsp;...!#</var> as a
+the SRFI-22 <code>#!</code>+space marker as an ignored line,
+and the format <code>#!/</code>&nbsp;...&nbsp;<code>!#</code> and <code>#!.</code>&nbsp;...&nbsp;<code>!#</code> as a
 multi-line comment.
 Note that this SRFI does <em>not</em> mandate support or any particular
-semantics for <var>#!fold-case</var>, <var>#!no-fold-case</var>,
-the SRFI-22 <var>#!</var>+space convention, or
-<var>#!</var> followed by a slash or period;
+semantics for <code>#!fold-case</code>, <code>#!no-fold-case</code>,
+the SRFI-22 <code>#!</code>+space convention, or
+<code>#!</code> followed by a slash or period;
 it is merely designed so that implementations <em>could</em>
 implement them all simultaneously.
 </p>
@@ -1138,9 +1138,9 @@
 </p>
 
 <p>
-We recommend that <var>#!curly-infix</var> not be the very first characters
+We recommend that <code>#!curly-infix</code> not be the very first characters
 in a file (e.g., put a newline in front of it).
-If the file began with <var>#!curly-infix</var>, is made executable,
+If the file began with <code>#!curly-infix</code>, is made executable,
 and then execution is attempted,
 this might confuse some systems into trying to run the
 program <var>curly-infix</var>.
@@ -1155,24 +1155,24 @@
 Mandating module support is unnecessary and might inhibit its
 adoption.</p>
 
-<h2><a name="rationale_marker_105">Why the marker <var>#!curly-infix</var>?</a></h2>
+<h2><a name="rationale_marker_105">Why the marker <code>#!curly-infix</code>?</a></h2>
 
 <p>
 There were two competing alternatives:
-<var>#!srfi-105</var> and <var>#!curly-infix</var>.
+<code>#!srfi-105</code> and <code>#!curly-infix</code>.
 </p>
 
 <p>
 The
 <a href="http://srfi.schemers.org/srfi-105/mail-archive/msg00027.html";>
-<var>#!srfi-105</var> was recommended during discussion of SRFI-105</a>,
+<code>#!srfi-105</code> marker was recommended during discussion of SRFI-105</a>,
 in part because it makes it clear where more information can be gathered.
 Also, it suggests that <code>srfi-</code> should be
 the namespace for SRFIs, a plausible convention.
 </p>
 
 <p>
-However, <var>#!curly-infix</var> marker
+However, the <code>#!curly-infix</code> marker
 has the advantage of being more obvious about what is being enabled.
 Modern search engines make it easy to find where information is, using
 either naming convention.
@@ -1185,7 +1185,7 @@
 <p><a href=
 "http://docs.racket-lang.org/guide/Pairs__Lists__and_Racket_Syntax.html";>
 Racket allows a notation called the &#8220;infix convention&#8221;
-with the form &#8220;<code>(a . operation . b)</code>&#8221;</a>. An
+with the form &#8220;<code>(a&nbsp;.&nbsp;operation&nbsp;.&nbsp;b)</code>&#8221;</a>. An
 advantage of this alternative is that it does not use the braces,
 so it might be easier to implement in Schemes which already define
 <code>{</code>...<code>}</code> in a local extension. However, the Racket &#8220;infix
@@ -1203,7 +1203,7 @@
 they already know.
 The notation <samp>{a&nbsp;+&nbsp;b}</samp>
 is much more similar to the standard notation
-&#8220;a&nbsp;+&nbsp;b&#8221; than
+&#8220;<samp>a&nbsp;+&nbsp;b</samp>&#8221; than
 <samp>(a&nbsp;.&nbsp;+&nbsp;.&nbsp;b)</samp>.</li>
 <li>It is easy to make mistakes. If you forget a &#8220;<code>.</code>&#8221;
 somewhere, you end up with the wrong result, and possibly without an
@@ -1232,7 +1232,7 @@
 <li>Even Racket users don&#8217;t use this convention often. Its
 documentation says that &#8220;Racket programmers use the infix
 convention sparingly&#8212;mostly for asymmetric binary operators
-such as <var>&lt;</var> and <var>is-a?</var>&#8221;.
+such as <code>&lt;</code> and <code>is-a?</code>&#8221;.
 The documentation does not say why,
 but its extra length and awkwardness may be part of the reason.
 In any case, the fact that the Racket documentation recommends that it
@@ -1289,13 +1289,13 @@
 Jens Axel S&#248;gaard explained that its design rationale was as follows:
 </p>
 <ol type="i">
-<li>The operations + - * / ^ [are] written using their standard syntax</li>
+<li>The operations <code>+</code> <code>-</code> <code>*</code> <code>/</code> <code>^</code> [are] written using their standard syntax</li>
 <li>No other operations get special syntax</li>
 <li>function application is name[]
 (same choice as Mathematica - but it could
 easily be name() instead)</li>
-<li>Since - is used in Scheme names, one can use _ to write names using -</li>
-<li>Other names can be written using | | syntax.</li>
+<li>Since <code>-</code> is used in Scheme names, one can use <code>_</code> to write names using -</li>
+<li>Other names can be written using <code>|</code>&nbsp;<code>|</code> syntax.</li>
 </ol>
 
 <p>
@@ -1305,8 +1305,8 @@
 http://reference.wolfram.com/mathematica/guide/Syntax.html</a>.
 The rationale is to keep the infix operations to the essentials in
 order not to interfere too much with builtin names of Scheme.
-Since - is so common in the variable names, a special syntax _
-is needed. Other names can be used by the standard | | syntax
+Since <code>-</code> is so common in the variable names, a special syntax <code>_</code>
+is needed. Other names can be used by the standard <code>|</code>&nbsp;<code>|</code> syntax
 for peculiar variable names.&#8221;
 </p>
 
@@ -1315,9 +1315,9 @@
 chosen to delimit the infix expressions. That&#8217;s on purpose,
 since I had and haven&#8217;t decided what I like best yet.&#8221;
 In the sample implementation,
-the 3-character sequence &#8220;@${&#8220; begins an infix expression,
+the 3-character sequence &#8220;<code>@${</code>&#8220; begins an infix expression,
 which switches to a completely different language that
-ends with a matching &#8220;}&#8221;.
+ends with a matching &#8220;<code>}</code>&#8221;.
 </p>
 
 <p>
@@ -1366,7 +1366,7 @@
 <p>
 Differences in this approach, which some may see as advantages, are that
 infix operators need not be separated by whitespace,
-it provides precedence of * and / over + and -,
+it provides precedence of <code>*</code> and <code>/</code> over <code>+</code> and <code>-</code>,
 and it builds in a simple assignment statement if you want it.
 Like many infix notations (including curly-infix), for many expressions
 the infix.plt package is a far clearer notation than the
@@ -1396,7 +1396,7 @@
 </li>
 <li>Because it has a precedence system, it is necessarily less homoiconic
 when precedence is used.
-Note that curly-infix supports precedence via <var>$nfx$</var>, and
+Note that curly-infix supports precedence via <code>$nfx$</code>, and
 a built-in precedence system <em>could</em> be added later
 if this was desired by the community.
 </li>
@@ -1410,40 +1410,40 @@
 Its documentation states that
 identifiers (which are also used for function names) must
 &#8220;begin with a letter, and is optionally followed by series of letters,
-digits or underscores.  An underscore is converted to a -&#8221;.
+digits or underscores.  An underscore is converted to a <code>-</code>&#8221;.
 Under these rules, it is not possible to call procedures with names like
 &#8220;<samp>char=?</samp>&#8221; or use variables
-with &#8220;*&#8221; embedded in them.
-It does allow references to variable names with &#8220;-&#8221;
+with &#8220;<code>*</code>&#8221; embedded in them.
+It does allow references to variable names with &#8220;<code>-</code>&#8221;
 embedded in them, but in this approach
 names must be spelled differently (and thus inconsistently)
-by replacing every &#8220;-&#8221; with &#8220;_&#8221;.
-Thus, variables like &#8220;list-ref&#8221; must
-be spelled as &#8220;list_ref&#8221; inside the infix.plt notation
+by replacing every &#8220;<code>-</code>&#8221; with &#8220;<code>_</code>&#8221;.
+Thus, variables like &#8220;<samp>list-ref</samp>&#8221; must
+be spelled as &#8220;<samp>list_ref</samp>&#8221; inside the infix.plt notation
 as documented.
 The infix.plt documentation did not, at the time of this writing,
 document any way around this limitation.
 However, on 2012-10-21,
 Jens Axel S&#248;gaard reported that other identifiers <em>can</em>
-be referred to using the |...| syntax.
+be referred to using the <code>|</code>...<code>|</code> syntax.
 This works around the problem, but is slightly more cumbersome when
-it is necessary, and is inconsistent with other code where |...|
+it is necessary, and is inconsistent with other code where <code>|</code>...<code>|</code>
 is not required.
 These are fundamental side-effects of not <em>requiring</em> infix operators
 to be delimited (e.g., by whitespace).
-Since some symbols must be escaped with |...| inside infix.plt
+Since some symbols must be escaped with <code>|</code>...<code>|</code> inside infix.plt
 but not outside, and some symbols require
-replacing every &#8220;-&#8221; with &#8220;_&#8221; where this is not done,
+replacing every &#8220;<code>-</code>&#8221; with &#8220;<code>_</code>&#8221; where this is not done,
 some symbols are represented inconsistently... and this
 inconsistency can lead to potentially hard-to-find errors.
 </li>
 <li>
 The notation is completely different and inconsistent
 with the surrounding Lisp notation.
-The curly braces {...} are suddenly used for the list creation operation
+The curly braces <code>{</code>...<code>}</code> are suddenly used for the list creation operation
 instead of parentheses,
-square brackets x[...] are used for function application
-instead of parentheses, and the parentheses (...) are
+square brackets <code>x[</code>...<code>]</code> are used for function application
+instead of parentheses, and the parentheses <code>(</code>...<code>)</code> are
 instead used for grouping (and not for list creation or function application).
 The same punctuation mark
 can have a completely different meaning in different contexts,
@@ -1512,7 +1512,7 @@
 It includes
 <a href="http://gnuvola.org/software/guile/doc/Reading-Infix.html";>support
 for reading infix expressions</a>.
-Once activated, infix expressions are surrounded by #[ and ].
+Once activated, infix expressions are surrounded by <code>#[</code> and <code>]</code>.
 Infix operators are surrounded by whitespace.
 It supports precedence, which sounds like an advantage,
 but operators must be registered before use (and few are predefined),
@@ -1565,8 +1565,8 @@
 on July 2000 he said
 &#8220;I think most people would like Scheme
 a lot better if they could say...
-display(... instead of
-(display&nbsp;... &#8221;
+<samp>display(</samp>... instead of
+<samp>(display&nbsp;</samp>...&nbsp;&#8221;
 </li>
 <li>
 Peter Norvig had a reader implementation
@@ -1597,10 +1597,10 @@
 combining function calls and infix expressions
 when there is only one parameter to the function call.
 This is a common case;
-for example, &#8220;<var>not</var>&#8221;
+for example, &#8220;<code>not</code>&#8221;
 (which is normally given only one parameter)
-often encloses infix &#8220;<var>and</var>&#8221; and
-&#8220;<var>or</var>&#8221;.
+often encloses infix &#8220;<code>and</code>&#8221; and
+&#8220;<code>or</code>&#8221;.
 Thus,
 <samp>f{n&nbsp;-&nbsp;1}</samp>
 &#8658;
@@ -1694,16 +1694,16 @@
 This was changed to eliminate the inconsistency.</p>
 
 <p>
-The symbol <var>$bracket-apply$</var> was once <var>bracketaccess</var>,
+The symbol <code>$bracket-apply$</code> was once <code>bracketaccess</code>,
 but it turns out that the Kawa Scheme implementation already used
-<var>$bracket-apply$</var>.
-Originally <var>$nfx$</var> was <var>nfx</var>, as this was used by some
+<code>$bracket-apply$</code>.
+Originally <code>$nfx$</code> was <code>nfx</code>, as this was used by some
 predefined macros for infix notation; it was changed slightly so that it
 would be unlikely to interfere with any pre-existing
-<var>nfx</var> procedure or macro, but would still be similar to its
+<code>nfx</code> procedure or macro, but would still be similar to its
 previous name.
-The symbols <var>$bracket-apply$</var>
-and <var>$nfx$</var> are somewhat more awkward to type
+The symbols <code>$bracket-apply$</code>
+and <code>$nfx$</code> are somewhat more awkward to type
 directly, but this is actually a good thing; this means it is even more
 unlikely to be used unintentionally by user code.
 
@@ -1761,16 +1761,16 @@
 which is essentially the same rule as before.</p>
 
 <h2><a name="rationale_otherdetails">Other details</a></h2>
-<p>There is no requirement that writers (e.g., &#8220;<var>write</var>&#8221;
+<p>There is no requirement that writers (e.g., &#8220;<code>write</code>&#8221;
 or a pretty-printer) write out curly-infix-expressions. They may
 choose to do so, e.g., for lists of length 3-6 whose car is the
-symbol &#8220;<var>and</var>&#8221;,
-the symbol &#8220;<var>or</var>&#8221;, or a
+symbol &#8220;<code>and</code>&#8221;,
+the symbol &#8220;<code>or</code>&#8221;, or a
 punctuation-only symbol. However, it would probably be wise to wait
 until many implementations can handle c-expressions.</p>
 
 <p>
-The <samp>$nfx$</samp> and <samp>$bracket-apply$</samp> symbols are
+The <code>$nfx$</code> and <code>$bracket-apply$</code> symbols are
 unhygienic, in the sense that programs that need it would
 in many cases need to begin by defining them, even though these identifiers
 do not appear literally in the code.
@@ -1781,19 +1781,19 @@
 As noted in a
 <a href="http://lists.gnu.org/archive/html/guile-devel/2012-10/msg00134.html";>
 guile-devel post by Mark H. Weaver on 2012-10-26</a>,
-&#8220;apart from the fact that <samp>$nfx$</samp>
+&#8220;apart from the fact that <code>$nfx$</code>
 etc. are meant to be defined by the user,
 it is exactly the same situation as for
-&#8216;quote&#8217;, &#8216;quasiquote&#8217;,
-&#8216;unquote&#8217;, &#8216;unquote-splicing&#8217;,
-&#8216;quasisyntax&#8217;, etc.
+&#8216;<code>quote</code>&#8217;, &#8216;<code>quasiquote</code>&#8217;,
+&#8216;<code>unquote</code>&#8217;, &#8216;<code>unquote-splicing</code>&#8217;,
+&#8216;<code>quasisyntax</code>&#8217;, etc.
 The whole point of
 these shorthand notations is to avoid having to type the associated
 identifier, and yet this means that an identifier is being referenced
 without appearing literally in the code.
 These shorthand notations always involve a tradeoff.  It means that the
 syntax is not quite as simple as the original s-expressions (as printed
-by &#8216;write&#8217;), and the user has to know a few more rules for how to
+by &#8216;<code>write</code>&#8217;), and the user has to know a few more rules for how to
 interpret the notation.  Experience shows that humans tend to prefer a
 bit more complexity in their syntax if there is something to be gained from it.
 I think it&#8217;s worthwhile to add a few more rules in exchange
@@ -1819,7 +1819,7 @@
 Implementations should <em>always</em> do
 this, but an implementation that complies with this SRFI must
 at least activate this behavior
-when they read the <var>#!curly-infix</var> marker
+when they read the <code>#!curly-infix</code> marker
 followed by whitespace.
 </p>
 <p>This reference implementation is SRFI type 2: &#8220;A