Here's a rewritten version of "Other requirements". I've added a requirement that parsing directives be on their own line, to simplify implementations. Thoughts? --- David A. Wheeler <h2 id="other-requirements">Other requirements</h2> <p> The directives <code>#!sweet</code>, <code>#!curly-infix</code>, and <code>#!no-sweet</code> are <i>parsing directives</i>. A parsing directive is <i>valid</i> if and only if it begins at the beginning of a line, it is terminated by an end of line, and it is not contained inside an expression (e.g., inside parentheses or a collecting list). The standard datum readers are <code>read</code>, <code>load</code>, <code>get-datum</code> (where applicable), and the default implementation REPL (where applicable). </p> <p> Portable Scheme applications <em>SHOULD</em> include a valid <code>#!sweet</code> directive before using sweet-expressions. Portable applications <em>SHOULD NOT</em> use this directive as the very first characters of a file because they might be misinterpreted on some platforms as an executable script header; an end of line before the directive avoids this problem. Scheme applications <em>MUST NOT</em> include a non-valid <code>#!sweet</code> directive. </p> <p> An implementation <em>MAY</em> signal an error if a parsing directive is not valid. An implementation <em>MUST</em> accept and ignore a valid <code>#!sweet</code> directive when sweet-expression reading is active. Implementations of this SRFI <em>MAY</em> implement sweet-expressions in their standard datum readers by default, even when a valid <code>#!sweet</code> directive is not (yet) received. </p> <p> An implementation may be a "native implementation". A native implementation <em>MUST</em> also accept, in its standard datum readers, a valid <code>#!sweet</code> directive, and from then on it <em>MUST</em> accept sweet-expressions from the same port (until some conflicting directive or instruction is given). </p> <p> A valid <code>#!curly-infix</code> directive <em>SHOULD</em> cause the current port to switch to SRFI-105 semantics (e.g., sweet-expression processing is disabled). A valid <code>#!no-sweet</code> directive <em>SHOULD</em> cause the current port to disable sweet-expression processing and <em>MAY</em> also disable curly-infix expression processing. </p> <p> A sweet-expression reader <em>MUST</em> support <a href="http://srfi.schemers.org/srfi-30/">SRFI-30 (Nested Multi-line comments) block comments</a> (<tt>#|</tt> ... <tt>|#</tt>) and <a href="http://srfi.schemers.org/srfi-62/">SRFI-62 (S-expression comments) datum comments</a> (<tt>#;</tt><var>datum</var>). It is <em>RECOMMENDED</em> that the sweet-expression reader support <a href="http://srfi.schemers.org/srfi-22/">SRFI-22 (Running Scheme Scripts on Unix)</a> (where <tt>#!</tt> followed by space ignores text to the end of the line), <tt>#!</tt> followed by a letter as a directive (such as <tt>#!fold-case</tt>) delimited by a whitespace character or end-of-file, and the formats <tt>#!/</tt> ... <tt>!#</tt> and <tt>#!.</tt> ... <tt>!#</tt> as multi-line non-nesting comments. </p> <p> A sweet-expression reader <em>MAY</em> implement datum labels with syntax <code>#<i>number</i>=<i>datum</i></code>. If the first character after the equal sign is not whitespace, such a reader <em>SHOULD</em> read it as a neoteric-expression. If the equal sign is followed by whitespace, a datum reader <em>MAY</em> reject it; the reader <em>MAY</em> also consider the datum an <i>it_expr</i>, and thus as a label for a sweet-expression (the sample implementation does not do this). </p> <p> A <i>well-formatted</i> s-expression is an expression interpreted identically by both traditional s-expressions and by sweet-expressions. A well-formatted file is a file interpreted identically by both traditional s-expressions and sweet-expressions. (In practice, it appears that <a href="#backwards-compatibility">most real s-expression files in Scheme are well-formatted</a>.) It is <em>RECOMMENDED</em> that files in traditional s-expression notation be well-formatted so that they can be directly read using a sweet-expression reader. </p> <p> Implementations <em>MUST</em> provide the procedures <var>sweet-read</var> as a sweet-expression reader and/or <var>neoteric-read</var> as a neoteric-expression reader. These procedures <em>MUST</em> support an optional port parameter. </p> <p> Implementations <em>SHOULD</em> enable a sweet-expression reader when reading a file whose name ends in “.sscm” (Sweet Scheme). Application authors <em>SHOULD</em> use the filename extension “.sscm” when writing portable Scheme programs using sweet-expressions. </p> <p> Implementations <em>MUST</em> provide the procedures <var>curly-write</var> and <var>neoteric-write</var> as writers that can write c-expressions and n-expressions respectively. These procedures <em>MUST</em> accept a first parameter (the object to write) and an optional second parameter (the port). Implementations that provide R7RS semantics (<var>write</var> with cycle detection, <var>write-shared</var> that identifies shared structures, and <var>write-simple</var> with no guarantee of cycle detection or shared structure identification) <em>SHOULD</em> include appropriate variants of these. That is, <var>curly-write</var> and <var>neoteric-write</var> that perform cycle detection, <var>curly-write-shared</var> and <var>neoteric-write-shared</var> identify shared structures, and <var>curly-write-simple</var> and <var>neoteric-write-simple</var> guarantee neither. </p> <p>Note that, by definition, this SRFI modifies lexical syntax.</p>
