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

Re: [PATCH] Important fix and HTML markup improvements

This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.

"David A. Wheeler" <dwheeler@xxxxxxxxxxxx> writes:
> Mark H Weaver:
>> The current draft says:
>> > 5. An unprefixed ( . e) MUST evaluate as e.
>> s/MUST evaluate as/MUST be read as/
> I agree that the word "evaluate" here is misleading, so yes, we should
> fix that to clarify things.  However, the rest of the text uses "maps
> to" or its abbreviation =>.  So for consistency with the rest of the
> text, it should probably instead say something like this:
> .... 5. An unprefixed ( . e) MUST map to e.


> I propose accepting the HTML tagging, and changing the line about
> unprefixed (. e) to use the term "map" like everything else does.  Any
> other last-minute comments?

These are probably not worth uploading a new version for, but in case
any other changes are made, here are some more minor markup tweaks
consistent with my last patch.


--- srfi-105.html	2012-10-31 11:20:10.168320379 -0400
+++ srfi-105-new.html	2012-10-31 11:54:35.346211597 -0400
@@ -301,7 +301,7 @@
 <li><code><var>e</var>[</code>...<code>]</code> &#8658;
 <li>The above mappings <em>MUST NOT</em> be applied
-if one or more whitespace characters are present between e and the open
+if one or more whitespace characters are present between <var>e</var> and the open
 paired character.</li>
 <li>An unprefixed <code>(&nbsp;.&nbsp;<var>e</var>)</code> <em>MUST</em> map to <code><var>e</var></code>.</li>
@@ -944,8 +944,8 @@
 <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>Bitwise and: <code>bit</code>...<code>and</code>, <code>log</code>...<code>and</code>, <code>&amp;</code></li>
+<li>Bitwise or/xor: <code>bit</code>...<code>or</code>, <code>log</code>...<code>or</code>, <code>|</code></li>
@@ -1020,7 +1020,7 @@
 <li>An &#8220;escaping&#8221;
-<samp>{e}</samp> is mapped to <samp>e</samp>
+<code>{<var>e</var>}</code> is mapped to <code><var>e</var></code>
 so that <code>{</code>...<code>}</code> can be used
 for grouping:
@@ -1035,7 +1035,7 @@
 in sweet-expressions for symbols
 that would otherwise have other meanings.</li>
 <li>The &#8220;unary-operation&#8221; curly-infix list
-<samp>{e&nbsp;f}</samp> &#8658; <samp>(e&nbsp;f)</samp>,
+<code>{<var>e</var>&nbsp;<var>f</var>}</code> &#8658; <code>(<var>e</var>&nbsp;<var>f</var>)</code>,
 so that
 <samp>{-&nbsp;x}</samp> &#8658; <samp>(-&nbsp;x)</samp>,
 the likely interpretation, and also so that the neoteric-expressions like
@@ -1589,11 +1589,11 @@
 Quoting rules and macros continue to work as usual. In addition:
-The prefixed <samp>e(...)</samp> form provides
+The prefixed <code><var>e</var>(</code>...<code>)</code> form provides
 a more traditional-looking format for function calls,
  e.g., <samp>cos(x)</samp> instead of <samp>(cos&nbsp;x)</samp>.</li>
-The prefixed <samp>e{...}</samp> form simplifies
+The prefixed <code><var>e</var>{</code>...<code>}</code> form simplifies
 combining function calls and infix expressions
 when there is only one parameter to the function call.
 This is a common case;
@@ -1611,20 +1611,20 @@
-Prefixed square brackets <samp>e[...]</samp> &#8658;
+Prefixed square brackets <code><var>e</var>[</code>...<code>]</code> &#8658;
 This is intended to simplify use of indexed arrays, associative arrays, and similar constructs.
-The <samp>(.&nbsp;e)</samp> rule handles expressions like <samp>read(.&nbsp;port)</samp>,
+The <code>(.&nbsp;<var>e</var>)</code> rule handles expressions like <samp>read(.&nbsp;port)</samp>,
 ensuring that they map to <samp>(read&nbsp;.&nbsp;port)</samp>.
-If <samp>(.&nbsp;x)</samp> didn&#8217;t mean <samp>x</samp>, then it would
+If <code>(.&nbsp;<var>x</var>)</code> didn&#8217;t mean <code><var>x</var></code>, then it would
 be easy to get this case wrong.  Also, if someone wanted to build on
 top of an existing reader, they would have to reimplement parts of the
 list-processing system if this wasn&#8217;t handled.
 It is already true that
-<samp>(.&nbsp;x)</samp> is <samp>x</samp> in guile,
+<code>(.&nbsp;<var>x</var>)</code> is <code><var>x</var></code> in guile,
 so there was already a working example that this
 is a reasonable extension.  In fact, in a typical implementation of a
 list reader, it takes extra effort to <em>prevent</em> this extension,
@@ -1717,9 +1717,9 @@
 Scheme implementations with brackets and braces</a>
 shows these differences;
 several Scheme implementations follow the R6RS specification that
-accepts <samp>[...]</samp> as a synonym for <samp>(...)</samp>,
-GNU Kawa interprets <samp>[...]</samp> as the redefinable constructor
+accepts <code>[</code>...<code>]</code> as a synonym for <code>(</code>...<code>)</code>,
+GNU Kawa interprets <code>[</code>...<code>]</code> as the redefinable constructor
 and two implementations (Rep and FemtoLisp) use them as vector constructors.
 By intentionally not defining the interpretation of unprefixed
 square brackets, implementations are free to continue to use whatever