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

[svanleent <svanleent@gmail.com>]

David,

 From a pragmatic side, wouldn't it be better to just have a marker like 
#!curly-infix. The number 105 doesn't say much when reading the code, 
which is the whole reason for the existence of curly-infixing.

Also, a file extension might change the folding mode. This could by 
something like .scmc (scheme-curly).

Just my $0.02
Sjoerd

On 05-09-12 04:36, David A. Wheeler wrote:
> 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
>