From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nathan Trapuzzano Newsgroups: gmane.emacs.devel Subject: Re: Double unquote/unquote-splicing Date: Tue, 05 Nov 2013 10:22:58 -0500 Message-ID: <87bo1yhnzh.fsf@nbtrap.com> References: <87wqko6z8g.fsf@nbtrap.com> <874n7sf3pi.fsf@nbtrap.com> <87habsdlwo.fsf@nbtrap.com> <877gcnlcnz.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1383665011 28398 80.91.229.3 (5 Nov 2013 15:23:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2013 15:23:31 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 05 16:23:35 2013 Return-path: Envelope-to: ged-emacs-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 1VdiTZ-0000QA-Vb for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2013 16:23:30 +0100 Original-Received: from localhost ([::1]:56748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdiTZ-0005gT-GN for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2013 10:23:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdiTM-0005Ue-8T for emacs-devel@gnu.org; Tue, 05 Nov 2013 10:23:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdiTE-0005IV-Hk for emacs-devel@gnu.org; Tue, 05 Nov 2013 10:23:16 -0500 Original-Received: from oproxy17-pub.mail.unifiedlayer.com ([74.220.201.171]:58115) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1VdiTD-0005Gw-TW for emacs-devel@gnu.org; Tue, 05 Nov 2013 10:23:08 -0500 Original-Received: (qmail 30041 invoked by uid 0); 5 Nov 2013 15:23:01 -0000 Original-Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy17-pub.mail.unifiedlayer.com with SMTP; 5 Nov 2013 15:23:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=HQkKOrlNpKd75BnrAJCeYhWQnBTxvhdkxrNfcsietr8=; b=ay7FznJga602QteOG/CEZD/TJ5C4MwFa7ol7/r4P0ZvJ/9OTv32m02PSnVhr6xqFE8zqMXx4isnup3ITAFJlIxjNFi/x1tieD3zUoQDHYwGTW+WaNtLmoKKruLMK6WM/; Original-Received: from [50.90.253.209] (port=48295 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (TLSv1:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1VdiT6-00079W-Py; Tue, 05 Nov 2013 08:23:01 -0700 In-Reply-To: <877gcnlcnz.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Tue, 05 Nov 2013 13:01:36 +0900") User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3.50 (gnu/linux) X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.220.201.171 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164962 Archived-At: "Stephen J. Turnbull" writes: > "It's pretty, so it must be right" is a fallacy. I haven't argued in these terms at all. > > In summary, this change would > > > > 1. break nothing, > > 2. require virtually no work to be done, > > 3. render macro-writing macros easier to read and write; and > > 4. bring Elisp behavior right in line with CL and Scheme. > > > > Even if you disagree with (3), this seems like a win all around. > > AFAICS, (1) hasn't been properly checked, and one can also disagree > with (4), as phrased. There will still be plenty of differences in > behavior. Only nested backquotes (an infrequently used facility) will > be synchronized. I suspect Stefan would agree with me about (1). This proposal would allow syntax that currently signals an error. If your code doesn't already throw said error, this won't change anything. As for (4), of course I only meant _in this instance_ Elisp semantics would be equivalent to CL's and Scheme's. > I'm not really against this, but if it makes Stefan uneasy, I'll side > with Stefan's ambiguous intuition against the rather tenuous claims in > favor. I think the only claim that can be legitimately said to be "tenuous" is (3), given its subjective nature. It seems to me that the other points are simply true.