unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: "Sjoerd van Leent Privé" <svanleent@gmail.com>
To: dwheeler@dwheeler.com
Cc: guile-devel@gnu.org
Subject: Re: SRFI-105 (curly-infix-expressions) marker #!srfi-105 ... could guile live with that?
Date: Fri, 07 Sep 2012 09:18:07 +0200	[thread overview]
Message-ID: <50499FAF.7060803@gmail.com> (raw)
In-Reply-To: <E1T9ETE-00065f-GP@fenris.runbox.com>

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




  reply	other threads:[~2012-09-07  7:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-05  2:36 SRFI-105 (curly-infix-expressions) marker #!srfi-105 ... could guile live with that? David A. Wheeler
2012-09-05  7:09 ` svanleent
2012-09-05 12:12   ` David A. Wheeler
2012-09-07  7:18     ` Sjoerd van Leent Privé [this message]
2012-09-05 21:52 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50499FAF.7060803@gmail.com \
    --to=svanleent@gmail.com \
    --cc=dwheeler@dwheeler.com \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).