Heya, I should probably do these mods on the git repo directly, but I still have to figure out how I got access the last time again, LOL. Probably need to generate new SSH id's or something (hard disk crashed last month, so settings got lost)....
<h1><a name="related-srfis">Related SRFIs</a></h1> <p> <a href="http://srfi.schemers.org/srfi-49/";>SRFI-49 (Indentation-sensitive syntax)</a> (superseded by this), <a href="http://srfi.schemers.org/srfi-105/";>SRFI-105 (Curly-infix-expressions)</a> (incorporated by this), <a href="http://srfi.schemers.org/srfi-30/";>SRFI-30 (Nested Multi-line comments)</a> (some interactions) <a href="http://srfi.schemers.org/srfi-62/";>SRFI-62 (S-expression comments)</a> (some interactions) </p> Of course, SRFI-30 and SRFI-62 are incorporated into R6RS, so maybe not necessary to mention them. ---- Missing </p>: <p> See the <a href="#design-rationale">design rationale</a> for a detailed discussion on how and why it is designed this way. </p> <!-- this one --> ---- Ara ara, should we spec this? <p> A tool that reads sweet-expressions and writes out s-expressions <em>SHOULD</em> specially treat lines that begin with a semicolon when they are not currently reading an expression (e.g., no expression has been read, or the last expression read has been completed with a blank line). Such a tool <em>SHOULD</em> (when outside an expression) copy exactly any line beginning with semicolon followed by a whitespace or semicolon. Such a tool <em>SHOULD</em> (when outside an expression) also copy lines beginning with “;#” or “;!” without the leading semicolon, and copy lines beginning with “;_” without either of those first two characters. Application authors <em>SHOULD</em> follow a semicolon in the first column with a whitespace character or semicolon if they mean for it to be a comment. </p> I'm mostly concerned with the ";#" and ";!" rules, which would cause divergent behavior in the two cases: (1) if preprocessed with the tool and loaded into a standard Scheme s-expr reader (or even t-expr reader) and (2) if read into a Scheme t-expr reader. Perhaps a better behavior would be: - If such a tool finds a "#!" line that isn't "#!sweet" followed by whitespace or "#!curly-infix" followed by whitespace, then it <em>SHOULD</em> copy that line verbatim to the output. Such a tool <em>MUST</em> also treat symbol's case as significant. The intent is that other reader options, such as R6RS "#!fold-case" and "#!no-fold-case", can be used on a Scheme implementation without a sweet-expression reader by using such a tool as a preprocessor. - What you think? ---- Also I'd like to add my own text on SUBLIST: <p>SUBLIST also makes certain idioms possible. For instance, some functions need to change their behavior based on the type of the inputs. Here's an example, an implementation of SRFI-105's <var>$bracket-apply$</var>: </p> <pre> define c[i] cond vector?(c) vector-ref c i string?(c) string-ref c i pair?(c) list-ref c i else error "Not a collection" </pre> <p> This function shows a common occurrence in Scheme programming: A function that immediately begins with <code>cond</code>. The formatting of <code>cond</code> above, however, has several lines that consist of a single n-expression item (e.g. "<code>cond</code>", "<code>else</code>", "<code>string?(c)</code>", etc.). </p> <p> Vertical space is precious. Using SUBLIST, we can compress the code to: </p> <pre> define c[i] $ cond vector?(c) $ vector-ref c i string?(c) $ string-ref c i pair?(c) $ list-ref c i else $ error "Not a collection" </pre> <p> Arguably, this can be done by putting the <code>cond</code> branches in explicit parentheses. Howver, the idiom supported by SUBLIST is more general than explicit parentheses can be, because SUBLIST does not disable indentation processing. In particular, this idiomatic formatting of <code>cond</code> using SUBLIST makes possible the following code: </p> <pre> define merge(< as bs) $ cond null?(as) $ bs null?(bs) $ as {car(as) < car(bs} $ cons car as merge < (cdr as) bs else $ cons car bs merge < as (cdr bs) </pre> <p> Without SUBLIST, the more complex branches of the <code>cond</code> would have to be formatted differently from the simpler branches (unless you are willing to waste a line to write just "<code>as</code>"), or would be expressed in deeply-nested parentheses, defeating the purpose of using sweet-expressions. </p> <!-- to be inserted before this line: --> <p>After discussion, sublist was accepted in July 2012.</p> ---- That's all for now. Sincerely, AmkG ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
