[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SRFI-105 (curly-infix-expressions) marker #!srfi-105 ... could guile liv
From: |
David A. Wheeler |
Subject: |
SRFI-105 (curly-infix-expressions) marker #!srfi-105 ... could guile live with that? |
Date: |
Tue, 04 Sep 2012 22:36:17 -0400 (EDT) |
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
- SRFI-105 (curly-infix-expressions) marker #!srfi-105 ... could guile live with that?,
David A. Wheeler <=