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

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

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

[svanleent]

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
>

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

[David A. Wheeler]

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

There are advantages either direction.  I agree with you on the advantage of #!curly-infix, which was an alternative recommendation.  However, John Cowan strongly argues that the advantage of #!srfi-105 is that it tells you "where to go for more information", as well as being more general.

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

True.  We use .sscm for "sweet-scheme", for example.

--- David A. Wheeler

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

[Ludovic Courtès]

Hi David,

"David A. Wheeler" <dwheeler@dwheeler.com> skribis:

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

If that can be implemented without breaking backward compatibility, then
it’d be fine, I think.

Though I think out-of-band means should always work.  For instance, when
compiling SRFI-105 code, one could write “guild compile --srfi-105
foo.sweet”, or
(compile #:from (lookup-language 'scheme-sweet-expressions) ...).

Thanks,
Ludo’.

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

[Sjoerd van Leent Privé]

On 05-09-12 14:12, David A. Wheeler wrote:
> svanleent:
>>   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.
> There are advantages either direction.  I agree with you on the advantage of #!curly-infix, which was an alternative recommendation.  However, John Cowan strongly argues that the advantage of #!srfi-105 is that it tells you "where to go for more information", as well as being more general.
I believe it is information versus information. I believe strongly that 
a notion of #!curly-infix would be more readable than #!srfi-105. The 
latter doesn't explain at all why the file looks drastically different, 
whereas a notion of #!curly-infix (or #!sweet-scheme, #!scheme for the 
same reason) is more understandable. However, as you say, it doesn't say 
anything about the specification being involved, so for that matter, I 
believe the following could be applied: The guile parser could give us 
the literal SRFI's being implemented and with a bit of help from Emacs 
or whatever a developer prefers, it could become just as navigatable, to 
the extend of opening up the right info/pdf file or browser URL. Here it 
should be the tools to help us, and this requires an obvious effort.

The implementation could be implemented as an option passed to guile as 
simple as guile --info-spec SCM-FILE1 ... SCM-FILE-N. The benefit is 
that this could enable to have more readable names in other cases as 
well (such as module inclusion, etc.)

I understand well that this involves an additional step, however, to my 
mind, it makes coding much more elegant.

>> Also, a file extension might change the folding mode. This could by
>> something like .scmc (scheme-curly).
> True.  We use .sscm for "sweet-scheme", for example.
>
> --- David A. Wheeler