[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Marker #!srfi-105

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


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.

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
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
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
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>.