From: ludo@gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] Per-port read options, reader directives, SRFI-105
Date: Mon, 29 Oct 2012 12:14:36 +0100 [thread overview]
Message-ID: <87vcdtcyxv.fsf@gnu.org> (raw)
In-Reply-To: <87y5issnpb.fsf@tines.lan> (Mark H. Weaver's message of "Fri, 26 Oct 2012 21:33:52 -0400")
Hi Mark!
Mark H Weaver <mhw@netris.org> skribis:
> Thanks for your review and consent! I have incorporated your
> suggestions and pushed the improved patch set to stable-2.0.
Excellent, thanks!
> ludo@gnu.org (Ludovic Courtès) writes:
>> Regarding SRFI-105, I’m skeptical about a couple of things.
>>
>> First, $bracket-apply$, $nfx$, and $bracket-list$ need to be
>> user-defined, but implementations are allowed to provide a pre-defined
>> version of these. This sounds like an opportunity for incompatibilities
>> (which the document describes as a shortcoming of Guile’s infix module.)
>
> First of all, I should clarify that $bracket-list$ is not part of
> SRFI-105; it is part of GNU Kawa. However, since SRFI-105 adopted
> Kawa's convention for $bracket-apply$ within curly braces, I chose to
> also adopt Kawa's $bracket-list$ convention when curly-infix is enabled
> and when no other meaning has been given to square brackets.
>
> SRFI-105 says that $nfx$ and $bracket-apply$ "SHOULD NOT" be bound by
> default (except to something that produces an error), and that they
> "MUST NOT" be bound to anything that cannot be overridden.
Right, I had forgotten that part. That addresses the risk of
incompatibilities I was thinking of.
[...]
>> It’s also unhygienic, in the sense that programs that need it would
>> typically have to start with a definition of $nfx$ & co., although these
>> identifiers never appear literally in the neoteric code.
>
> I agree that this is not ideal, but I see no way around it without
> losing the benefits that these (optional) features are meant to provide.
>
> Apart from the fact that $nfx$ et are meant to be defined by the user,
> it is exactly the same situation as for 'quote', 'quasiquote',
> 'unquote', 'unquote-splicing', 'quasisyntax', etc. The whole point of
> these shorthand notations is to avoid having to type the associated
> identifier, and yet this means that an identifier is being referenced
> without appearing literally in the code.
Yes, right. It’s probably just that I hadn’t thought of these good ol’
identifiers in this way. ;-)
[...]
>>> +Guile also implements the following non-standard extension to SRFI-105:
>>> +if @code{curly-infix} is enabled but the @code{square-brackets} read
>>> +option is turned off, then lists within square brackets are read as
>>> +normal lists but with the special symbol @code{$bracket-list$} added to
>>> +the front. To enable this combination of read options within a file,
>>> +use the reader directive @code{#!curly-infix-and-bracket-lists}. For
>>> +example:
>>
>> Do you think it would be possible, or even desirable, to be able to turn
>> off this extension?
>
> I definitely think it's desirable to be able to assign some other
> meaning to square brackets, and indeed SRFI-105 allows us to do whatever
> we want with them (though they must be delimiters), and by default Guile
> treats square brackets an equivalent alternative to parentheses.
>
> My intent was that this extension would apply only when square brackets
> have no other meaning, and I changed the documentation to make this more
> clear. This gives us license to add additional read options to do other
> things with square brackets in the future.
OK, makes sense.
> [... skipped several of your suggestions which I incorporated ...]
>
>>> + ;;(pass-if (equal? '#1=f(#1#) '#1=(f #1#)))
>>
>> Not implemented yet?
>>
>>> + ;;(pass-if (equal? '#1={a + . #1#} '($nfx$ . #1=(a + . #1#))))
>>
>> Same?
>
> The '#1=' and '#1#' notation is part of SRFI-38 and R7RS (draft 6),
> which is not yet implemented in Guile. SRFI-105 does not require that
> we support this notation, but gives those examples of how the two
> notations should interact if they are both supported.
OK.
> Thanks again for your careful review. The final result certainly
> benefitted greatly from your input :)
And from your patience and thoroughness! ;-)
Thanks!
Ludo’.
prev parent reply other threads:[~2012-10-29 11:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-16 10:32 [PATCH] Per-port read options, reader directives, SRFI-105 Mark H Weaver
2012-10-23 6:06 ` Mark H Weaver
2012-10-23 20:44 ` Ludovic Courtès
2012-10-23 20:45 ` Ludovic Courtès
2012-10-23 20:53 ` Ludovic Courtès
2012-10-23 20:54 ` Ludovic Courtès
2012-10-23 20:57 ` Ludovic Courtès
2012-10-23 20:58 ` Ludovic Courtès
2012-10-23 21:26 ` Ludovic Courtès
2012-10-24 4:04 ` Mark H Weaver
2012-10-24 13:13 ` Ludovic Courtès
2012-10-24 14:41 ` Mark H Weaver
2012-10-26 17:30 ` Ludovic Courtès
2012-10-23 21:30 ` Ludovic Courtès
2012-10-24 19:00 ` Mark H Weaver
2012-10-24 21:52 ` David A. Wheeler
2012-10-26 17:41 ` Ludovic Courtès
2012-10-26 17:44 ` Ludovic Courtès
2012-10-26 21:21 ` Ludovic Courtès
2012-10-27 1:33 ` Mark H Weaver
2012-10-29 11:14 ` Ludovic Courtès [this message]
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=87vcdtcyxv.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
--cc=mhw@netris.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).