Help! I'm currently drafting SRFI-105, curly-infix-expressions:
http://srfi.schemers.org/srfi-105/
and "trying to please everyone" (ha!).
Can you tell me if the most recent draft is something guile could live with?
In particular, since SRFI-105 is a reader modification, some comments indicated
a strong desire for a simple marker like #!fold-case and #!no-fold-case. In
particular, it was strongly advocated that #!srfi-105 be that marker.
Guile support for curly-infix-expressions is very important to me. Yet obviously guile
has different semantics for #!, namely, #!...!#. Clearly #!srfi-105 could be handled by
a special case, but could people live with that? I even have a notion for how
"#!" could be implemented in a way that would consistently handle SRFI-22 (#!
followed by space), guile's #!...!#, and things like #!fold-case, but I don't know if
that would be ardently rejected or possibly accepted by guilers. The rationale (below)
discusses this.
Anyway, I'd like to know if the #!srfi-105 marker would be acceptable to guile
developers, and if not, what alternatives would be suggested.
Thanks.
--- David A. Wheeler
======= Text from the rationale ===========================
Why the marker #!srfi-105?
We would like implementations to always have curly-infix enabled. However, some
implementations may have other extensions that use {...}. 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. This marker was recommended during discussion
of SRFI-105. After all, R6RS and R7RS (draft 6) already use #!fold-case and
#!no-fold-case as special markers to control the reader. Using #!srfi-105 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 #!,
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 srfi- should be the namespace
for SRFIs.
This marker need not interfere with other uses of #!. SRFI-22 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 #! is almost always followed immediately by / or
., and other scripts could be trivially fixed to make that so. R6RS had a
non-normative recommendation to ignore a line that began with #!/usr/bin/env,
as well as a #! /usr/bin/env, but this is non-normative; an implementation
could easily implement #! followed by space as an ignored line, and treat #!
followed by / or . differently. Thus, implementations could trivially support
simultaneously markers such as #!srfi-105 to identify curly-infix, the SRFI-22
#!+space marker as an ignored line, and support #!/ ...!# and #!. ...!# as a
multi-line comment. Note that this SRFI does not mandate support or any
particular semantics for #!fold-case, #!no-fold-case, the SRFI-22 #!+space
convention, or #! followed by a slash or period; it is merely designed so that
implementations could implement them all simultaneously. We recommend that
#!srfi-105 not be the first two characters in a file (e.g., put a newline in
front of it). If the file were made executable, and execution was attempted,
this might confuse some systems into trying to run the program srfi-105.
--- David A. Wheeler