From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Per-port read options, reader directives, SRFI-105 Date: Mon, 29 Oct 2012 12:14:36 +0100 Message-ID: <87vcdtcyxv.fsf@gnu.org> References: <87a9vmvh9s.fsf@tines.lan> <87mwzdzpqf.fsf@tines.lan> <87r4onwv9e.fsf@tines.lan> <874nlh2alx.fsf@gnu.org> <87y5issnpb.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1351509298 21195 80.91.229.3 (29 Oct 2012 11:14:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Oct 2012 11:14:58 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Oct 29 12:15:06 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 1TSnJ8-0004V6-De for guile-devel@m.gmane.org; Mon, 29 Oct 2012 12:15:02 +0100 Original-Received: from localhost ([::1]:47614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TSnJ0-0003EI-7l for guile-devel@m.gmane.org; Mon, 29 Oct 2012 07:14:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TSnIu-0003CY-Iq for guile-devel@gnu.org; Mon, 29 Oct 2012 07:14:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TSnIk-00059U-Oz for guile-devel@gnu.org; Mon, 29 Oct 2012 07:14:48 -0400 Original-Received: from xanadu.aquilenet.fr ([88.191.123.111]:42723) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TSnIk-00059O-G6 for guile-devel@gnu.org; Mon, 29 Oct 2012 07:14:38 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by xanadu.aquilenet.fr (Postfix) with ESMTP id 25BC9A441; Mon, 29 Oct 2012 12:14:37 +0100 (CET) Original-Received: from xanadu.aquilenet.fr ([127.0.0.1]) by localhost (xanadu.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q3b4ZIc-SAY; Mon, 29 Oct 2012 12:14:37 +0100 (CET) Original-Received: from pluto (unknown [193.50.110.126]) by xanadu.aquilenet.fr (Postfix) with ESMTPSA id D2460A29E; Mon, 29 Oct 2012 12:14:36 +0100 (CET) X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 8 Brumaire an 221 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87y5issnpb.fsf@tines.lan> (Mark H. Weaver's message of "Fri, 26 Oct 2012 21:33:52 -0400") User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 88.191.123.111 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:15060 Archived-At: Hi Mark! Mark H Weaver 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=C3=A8s) writes: >> Regarding SRFI-105, I=E2=80=99m 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=E2=80=99s 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=E2=80=99s also unhygienic, in the sense that programs that need it wo= uld >> 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=E2=80=99s probably just that I hadn=E2=80=99t thought of th= ese good ol=E2=80=99 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=3Df(#1#) '#1=3D(f #1#))) >> >> Not implemented yet? >> >>> + ;;(pass-if (equal? '#1=3D{a + . #1#} '($nfx$ . #1=3D(a + . = #1#)))) >> >> Same? > > The '#1=3D' 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=E2=80=99.