SRFI-105 (curly-infix-expressions) marker #!srfi-105 ... could guile live with that?

[David A. Wheeler]

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