From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: svanleent Newsgroups: gmane.lisp.guile.devel Subject: Re: SRFI-105 (curly-infix-expressions) marker #!srfi-105 ... could guile live with that? Date: Wed, 05 Sep 2012 09:09:30 +0200 Message-ID: <5046FAAA.1050204@gmail.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1346828992 3672 80.91.229.3 (5 Sep 2012 07:09:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2012 07:09:52 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Sep 05 09:09:48 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T99kB-0000ke-9p for guile-devel@m.gmane.org; Wed, 05 Sep 2012 09:09:47 +0200 Original-Received: from localhost ([::1]:46709 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T99k8-0004Rk-B1 for guile-devel@m.gmane.org; Wed, 05 Sep 2012 03:09:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T99k5-0004Ra-8s for guile-devel@gnu.org; Wed, 05 Sep 2012 03:09:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T99jy-0004VA-VM for guile-devel@gnu.org; Wed, 05 Sep 2012 03:09:41 -0400 Original-Received: from mail-ey0-f169.google.com ([209.85.215.169]:41236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T99jy-0004Ug-MR for guile-devel@gnu.org; Wed, 05 Sep 2012 03:09:34 -0400 Original-Received: by eaaf11 with SMTP id f11so63781eaa.0 for ; Wed, 05 Sep 2012 00:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HpJjERfyVM8LkEusWig5VkCPxWPM/S2WOFgdplgv7iY=; b=danQcfva6czK8kty31xIVNs/5isRCexQ/k8uV6JXoSVtHCBXHi2qSUBlDNrRRRH6ZJ 9BpLXiOtyUd569CsUBTZlICE26V2PLGIYQIp3nXzCWwxNBbX4hJ1B2/q2hQx9zxBf0Fq gfn7QSYQEzzhl+UH+2BnJBIHoRiYlQidvHxVziQ84XIg8RLAthwZu9Zne6nmFbTAxXNK gInvc6QR9e/K3TzcaZJx7qI4w7g5y0xkBbtqVA7WjdNGsC4ePODrqYaRxnNwGGG17Qrl ptkGyuhVmM7wETDYGWS38CdUCE+YpeXnSjMmex9K9uIgQ4DV6uXy84GA3ldY1dsLb44y vvKg== Original-Received: by 10.14.172.193 with SMTP id t41mr29320317eel.25.1346828973554; Wed, 05 Sep 2012 00:09:33 -0700 (PDT) Original-Received: from [172.16.3.219] (5352DA6A.cm-6-3d.dynamic.ziggo.nl. [83.82.218.106]) by mx.google.com with ESMTPS id u8sm1588112eel.11.2012.09.05.00.09.31 (version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 00:09:32 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.215.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14854 Archived-At: 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,=20 which is the whole reason for the existence of curly-infixing. Also, a file extension might change the folding mode. This could by=20 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 i= ndicated a strong desire for a simple marker like #!fold-case and #!no-fo= ld-case. In particular, it was strongly advocated that #!srfi-105 be tha= t marker. > > Guile support for curly-infix-expressions is very important to me. Yet= obviously guile has different semantics for #!, namely, #!...!#. Clearl= y #!srfi-105 could be handled by a special case, but could people live wi= th 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 ar= dently rejected or possibly accepted by guilers. The rationale (below) d= iscusses this. > > Anyway, I'd like to know if the #!srfi-105 marker would be acceptable t= o guile developers, and if not, what alternatives would be suggested. > > Thanks. > > --- David A. Wheeler > > > =3D=3D=3D=3D=3D=3D=3D Text from the rationale =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Why the marker #!srfi-105? > > We would like implementations to always have curly-infix enabled. Howev= er, some implementations may have other extensions that use {...}. We wan= t a simple, standard way to identify code that uses curly-infix so that r= eaders will switch to curly-infix if they need to switch. This marker was= recommended during discussion of SRFI-105. After all, R6RS and R7RS (dra= ft 6) already use #!fold-case and #!no-fold-case as special markers to co= ntrol the reader. Using #!srfi-105 is a simple, similar-looking marker fo= r a similar situation. What’s more, it implies a reasonable convent= ion for reader extensions: markers that begin with #!, followed by an ASC= II 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 f= or 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 support= ed 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 mul= ti-line arguments. But in practice the #! is almost always followed immed= iately 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-normat= ive; an implementation could easily implement #! followed by space as an = ignored line, and treat #! followed by / or . differently. Thus, implemen= tations 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 t= his 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 im= plement 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 t= he file were made executable, and execution was attempted, this might con= fuse some systems into trying to run the program srfi-105. > > --- David A. Wheeler >