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.
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>(+ x (* y z))</samp>. Forms with mixed infix operators and other complications have -“<var>$nfx$</var>” prepended to +“<code>$nfx$</code>” prepended to enable later macro processing, e.g., <samp>{4 + 5 * 6}</samp> ⇒ <samp>($nfx$ 4 + 5 * 6)</samp>. Also, inside a curly-infix list (recursively), -expressions of the form <samp>f(...)</samp> are simply -an abbreviation for <samp>(f ...)</samp>.</p> +expressions of the form <code><var>f</var>(</code>...<code>)</code> are simply +an abbreviation for <code>(<var>f</var> </code>...<code>)</code>.</p> <p>Note that this is derived from the “<a href="http://readable.sourceforge.net/">readable</a>” @@ -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 + b + c}</samp> ⇒ <samp>(+ a b 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 -“<var>equal?</var>”. +“<code>equal?</code>”. 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 * 5 * 6}</samp> ⇒ <samp>(* 4 5 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 e2}</samp> +<code>{<var>e1</var> <var>e2</var>}</code> is mapped to -<samp>(e1 e2)</samp>. +<code>(<var>e1</var> <var>e2</var>)</code>. E.g., <samp>{- x}</samp> ⇒ <samp>(- x)</samp>.</li> <li>The mapping of a curly-infix list beginning with the symbol -“<var>.</var>” is unspecified. +“<code>.</code>” is unspecified. (Note: the reference implementation maps -<samp>{. e}</samp> to <samp>e</samp>.) +<code>{. <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 “<var>$nfx$</var>” added to its front. +<dfn>mixed</dfn>. A mixed curly-infix list <em>MUST</em> be mapped to that list with “<code>$nfx$</code>” added to its front. E.g., <samp>{q + r * s}</samp> is mapped to @@ -271,8 +271,8 @@ </p> <ol> <li> -<samp>e(...)</samp> ⇒ -<samp>(e ...)</samp>. +<code><var>e</var>(</code>...<code>)</code> ⇒ +<code>(<var>e</var> </code>...<code>)</code>. E.g., <samp>cos(x)</samp> ⇒ <samp>(cos x)</samp>, @@ -283,11 +283,11 @@ <samp>read(. options)</samp> ⇒ <samp>(read . options)</samp>.</li> <li> -<samp>e{}</samp> ⇒ <samp>(e)</samp> +<code><var>e</var>{}</code> ⇒ <code>(<var>e</var>)</code> when there are zero or more whitespace characters within the braces; otherwise, -<samp>e{...}</samp> ⇒ <samp>(e {...})</samp>. +<code><var>e</var>{</code>...<code>}</code> ⇒ <code>(<var>e</var> {</code>...<code>})</code>. E.g., <samp>f{n - 1}</samp> ⇒ @@ -298,12 +298,12 @@ <samp>g{- x}</samp> ⇒ <samp>(g (- x))</samp>.</li> -<li><samp>e[...]</samp> ⇒ -<samp>($bracket-apply$ e ...)</samp></li> +<li><code><var>e</var>[</code>...<code>]</code> ⇒ +<code>($bracket-apply$ <var>e</var> </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>( . e)</samp> <em>MUST</em> evaluate as <samp>e</samp>.</li> +<li>An unprefixed <code>( . <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 -“<var>$nfx$</var>” or -“<var>$bracket-apply$</var>” +“<code>$nfx$</code>” or +“<code>$bracket-apply$</code>” by default to a procedure, macro, or syntax that <em>cannot</em> be overridden. An implementation <em>SHOULD NOT</em> bind the symbols -“<var>$nfx$</var>” or -“<var>$bracket-apply$</var>” +“<code>$nfx$</code>” or +“<code>$bracket-apply$</code>” 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 “<var>$nfx$</var>” and/or -“<var>$bracket-apply$</var>” +bind the “<code>$nfx$</code>” and/or +“<code>$bracket-apply$</code>” symbols (as it is then a library, this case actually falls under the “reserved for use by library writers” clause above). Application writers and other library writers using that implementation are then free to use or not use the implementation’s provided -“<var>$nfx$</var>” and/or -“<var>$bracket-apply$</var>” +“<code>$nfx$</code>” and/or +“<code>$bracket-apply$</code>” 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 “infix” -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 — 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 o g o h o ...}</samp> ⇒ <samp>(o f g h ...)</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’s true that {...} are often used in math for set notation. But +It’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’s hard to express good rules for detecting infix operators, and the rules become too complex for users (e.g., “punctuation-only symbols” -doesn’t detect “<var>and</var>” or “<var>or</var>”). +doesn’t detect “<code>and</code>” or “<code>or</code>”). 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 “simple” curly-infix-list for equality?</a></h2> +<h2><a name="rationale_equal">Why use <code>equal?</code> to compare operators in a “simple” 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 ,op y ,op 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 -“<var>$nfx$</var>” macro or procedure, or by later postprocessing +“<code>$nfx$</code>” 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) * -(y)}</code> +<samp>{-(x) * -(y)}</samp> and -<code>{-{x} * -{y}}</code> +<samp>{-{x} * -{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’t provided. -However, prepending “<var>$nfx$</var>” +However, prepending “<code>$nfx$</code>” 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 “math” extension. In this extension, if a mixed curly-infix list is seen, it first attempts to apply the “math” ruleset, and only -prepends “$nfx$” if it does not meet the requirements. In this extension: +prepends “<code>$nfx$</code>” 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., -“char-ci<=?” would be considered an operator with the -same precedence as “<=”. +“<samp>char-ci<=?</samp>” would be considered an operator with the +same precedence as “<samp><=</samp>”. If there’s still no match for any operator, the expression does not meet the “math” 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 “+” 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 + b + c * d}</samp> is the “<code>+</code>” operator applied to three operands: <samp>a</samp>, <samp>b</samp>, and <samp>(* c 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 + b - c}</samp> maps to <samp>{{a + b} - 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 < b <= c}? +comparisons, to support notations such as <samp>{a < b <= 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: ↓, ⇓}</li> -<li>Exponentiation/superscript/up-arrow: exp..., **, ^, sup {Unicode: ↑, ⇑}</li> -<li>Multiplication/division: *, /, div..., mod..., quo... {Unicode: ÷, ×}</li> -<li>Addition/subtraction: +, -</li> -<li>Bitwise and: bit...and, log...and, &</li> -<li>Bitwise or/xor: bit...or, log...or, |</li> +<li>Subscript/down-arrow: <code>sub</code> {Unicode: ↓, ⇓}</li> +<li>Exponentiation/superscript/up-arrow: <code>exp</code>..., <code>**</code>, <code>^</code>, <code>sup</code> {Unicode: ↑, ⇑}</li> +<li>Multiplication/division: <code>*</code>, <code>/</code>, <code>div</code>..., <code>mod</code>..., <code>quo</code>... {Unicode: ÷, ×}</li> +<li>Addition/subtraction: <code>+</code>, <code>-</code></li> +<li>Bitwise and: <code>bit...and</code>, <code>log...and</code>, <code>&</code></li> +<li>Bitwise or/xor: <code>bit...or</code>, <code>log...or</code>, <code>|</code></li> <li>Comparison: <ul> <li> -Ranged: < , <= , >=, > {Unicode: ≥, ≤, ∋, ∉, ⊄, ⊂, ⊆, ⊃, ⊇} +Ranged: <code><</code> , <code><=</code> , <code>>=</code>, <code>></code> {Unicode: ≥, ≤, ∋, ∉, ⊄, ⊂, ⊆, ⊃, ⊇} </li> -<li>Unranged: =, ==, !=, <>, =/=, eq..., in, is {Unicode: ≠, ≈, ≅}</li> +<li>Unranged: <code>=</code>, <code>==</code>, <code>!=</code>, <code><></code>, <code>=/=</code>, <code>eq</code>..., <code>in</code>, <code>is</code> {Unicode: ≠, ≈, ≅}</li> </ul> -<li>Logical conjunction: and {Unicode: ∩, ∧}</li> -<li>Logical/exclusive disjunction: or, xor, eor {Unicode: ∪, ∨, ⊕}</li> -<li>Implication/right arrows/doubled arrows: ->, =>, <->, <=>, -->, ==>, <-->, <==> {Unicode: ↔, ⇔, →, ⇒}</li> -<li>Definition/assignment/left arrow: <-, <--, <==, :=, ::= {Unicode: ≡, ←, ⇐}</li> +<li>Logical conjunction: <code>and</code> {Unicode: ∩, ∧}</li> +<li>Logical/exclusive disjunction: <code>or</code>, <code>xor</code>, <code>eor</code> {Unicode: ∪, ∨, ⊕}</li> +<li>Implication/right arrows/doubled arrows: <code>-></code>, <code>=></code>, <code><-></code>, <code><=></code>, <code>--></code>, <code>==></code>, <code><--></code>, <code><==></code> {Unicode: ↔, ⇔, →, ⇒}</li> +<li>Definition/assignment/left arrow: <code><-</code>, <code><--</code>, <code><==</code>, <code>:=</code>, <code>::=</code> {Unicode: ≡, ←, ⇐}</li> </ol> <p> @@ -965,11 +965,11 @@ A “simple math” 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: -*, /; +, -; < , <= , >=, >, =, <>, eq...; -<var>and</var>; and <var>or</var>; -adding exponentiation (e.g., ** and exp...) at a higher precedence level, -and implication (e.g., -> and =>) would make sense for a short list. -(The <> isn’t in many Scheme specifications, but it is odd to omit +<code>*</code>, <code>/</code>; <code>+</code>, <code>-</code>; <code><</code> , <code><=</code> , <code>>=</code>, <code>></code>, <code>=</code>, <code><></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>-></code> and <code>=></code>) would make sense for a short list. +(The <code><></code> isn’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’s not, many “$nfx$” processors would likely generate the +Even when it’s not, many “<code>$nfx$</code>” 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 “$nfx$” macro is to allow application authors +Yet the point of the “<code>$nfx$</code>” 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>(+ a 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 x)</samp>. It makes it easy to use prefix notation; e.g., <samp>{ f(x) }</samp> is another way to write <samp>(f 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’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>#! /usr/bin/env</var> (with a space before the slash), +with “<code>#!/usr/bin/env</code>” (without a space), as well +as “<code>#! /usr/bin/env</code>” (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>#!/ ...!#</var> and <var>#!. ...!#</var> as a +the SRFI-22 <code>#!</code>+space marker as an ignored line, +and the format <code>#!/</code> ... <code>!#</code> and <code>#!.</code> ... <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 “infix convention” -with the form “<code>(a . operation . b)</code>”</a>. An +with the form “<code>(a . operation . b)</code>”</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 “infix @@ -1203,7 +1203,7 @@ they already know. The notation <samp>{a + b}</samp> is much more similar to the standard notation -“a + b” than +“<samp>a + b</samp>” than <samp>(a . + . b)</samp>.</li> <li>It is easy to make mistakes. If you forget a “<code>.</code>” somewhere, you end up with the wrong result, and possibly without an @@ -1232,7 +1232,7 @@ <li>Even Racket users don’t use this convention often. Its documentation says that “Racket programmers use the infix convention sparingly—mostly for asymmetric binary operators -such as <var><</var> and <var>is-a?</var>”. +such as <code><</code> and <code>is-a?</code>”. 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ø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> <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> <code>|</code> syntax for peculiar variable names.” </p> @@ -1315,9 +1315,9 @@ chosen to delimit the infix expressions. That’s on purpose, since I had and haven’t decided what I like best yet.” In the sample implementation, -the 3-character sequence “@${“ begins an infix expression, +the 3-character sequence “<code>@${</code>“ begins an infix expression, which switches to a completely different language that -ends with a matching “}”. +ends with a matching “<code>}</code>”. </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 “begin with a letter, and is optionally followed by series of letters, -digits or underscores. An underscore is converted to a -”. +digits or underscores. An underscore is converted to a <code>-</code>”. Under these rules, it is not possible to call procedures with names like “<samp>char=?</samp>” or use variables -with “*” embedded in them. -It does allow references to variable names with “-” +with “<code>*</code>” embedded in them. +It does allow references to variable names with “<code>-</code>” embedded in them, but in this approach names must be spelled differently (and thus inconsistently) -by replacing every “-” with “_”. -Thus, variables like “list-ref” must -be spelled as “list_ref” inside the infix.plt notation +by replacing every “<code>-</code>” with “<code>_</code>”. +Thus, variables like “<samp>list-ref</samp>” must +be spelled as “<samp>list_ref</samp>” 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ø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 “-” with “_” where this is not done, +replacing every “<code>-</code>” with “<code>_</code>” 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 “I think most people would like Scheme a lot better if they could say... -display(... instead of -(display ... ” +<samp>display(</samp>... instead of +<samp>(display </samp>... ” </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, “<var>not</var>” +for example, “<code>not</code>” (which is normally given only one parameter) -often encloses infix “<var>and</var>” and -“<var>or</var>”. +often encloses infix “<code>and</code>” and +“<code>or</code>”. Thus, <samp>f{n - 1}</samp> ⇒ @@ -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., “<var>write</var>” +<p>There is no requirement that writers (e.g., “<code>write</code>” 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 “<var>and</var>”, -the symbol “<var>or</var>”, or a +symbol “<code>and</code>”, +the symbol “<code>or</code>”, 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>, -“apart from the fact that <samp>$nfx$</samp> +“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 -‘quote’, ‘quasiquote’, -‘unquote’, ‘unquote-splicing’, -‘quasisyntax’, etc. +‘<code>quote</code>’, ‘<code>quasiquote</code>’, +‘<code>unquote</code>’, ‘<code>unquote-splicing</code>’, +‘<code>quasisyntax</code>’, 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 ‘write’), and the user has to know a few more rules for how to +by ‘<code>write</code>’), 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’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: “A