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.
A key issue in the previous discussions was having some sort of reader marker to enable this SRFI, in case it isn't already enabled. I've used #!srfi-105 as the marker, even though #!...!# has a different use in guile. SRFI-105 doesn't require support for anything other than its own marker, but I think SRFI-105 would be more acceptable if there *COULD* be a rationalized general interpretation for "#!". So, below is a copy of the rationale for this marker, from the draft SRFI 105. I think it shows that "#!" COULD have a general semantic that would unify SRFI-22, guile, and R7RS' markers. There's no requirement that this convention be implemented, but I think showing you COULD have a convention would encourage acceptance. If anyone has any comments, please post. Thanks. --- David A. Wheeler =================== <p> We would like implementations to always have curly-infix enabled. However, some implementations may have other extensions that use <code>{</code>...<code>}</code>. We want a simple, standard way to identify code that uses curly-infix so that readers will switch to curly-infix if they need to switch. <a href="http://srfi.schemers.org/srfi-105/mail-archive/msg00027.html"> This marker was recommended during discussion of SRFI-105</a>. After all, R6RS and R7RS (draft 6) already use <var>#!fold-case</var> and <var>#!no-fold-case</var> as special markers to control the reader. Using <var>#!srfi-105</var> is 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 have the rest read as an identifier (up to a whitespace) and use that to control the reader, and <code>srfi-</code> should be the namespace for SRFIs. </p> <p> This marker need not interfere with other uses of <var>#!</var>. <a href="http://srfi.schemers.org/srfi-22/srfi-22.html">SRFI-22</a> supports <var>#!</var> 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. Guile, clisp, and several other Lisps support <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 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>, as well as a <var>#! /usr/bin/env</var>, 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 <code>/</code> or <code>.</code> differently. Thus, implementations could trivially support simultaneously markers such as <var>#!srfi-105</var> to identify curly-infix, the SRFI-22 <var>#!</var>+space marker as an ignored line, and support <var>#!/ ...!#</var> and <var>#!. ...!#</var> 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; it is merely designed so that implementations <em>could</em> implement them all simultaneously. We recommend that <var>#!srfi-105</var> not be the first two characters in a file (e.g., put a newline in front of it). If the file began with <var>#!srfi-105</var>, is made executable, and then execution is attempted, this might confuse some systems into trying to run the program <var>srfi-105</var>. </p>