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&#8217;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>#!&nbsp;/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>#!/&nbsp;...!#</var> and <var>#!.&nbsp;...!#</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>