From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Double unquote/unquote-splicing Date: Tue, 05 Nov 2013 13:01:36 +0900 Message-ID: <877gcnlcnz.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87wqko6z8g.fsf@nbtrap.com> <874n7sf3pi.fsf@nbtrap.com> <87habsdlwo.fsf@nbtrap.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1383624127 3675 80.91.229.3 (5 Nov 2013 04:02:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2013 04:02:07 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Nathan Trapuzzano Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 05 05:02:11 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 1VdXqA-0005cy-EM for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2013 05:02:06 +0100 Original-Received: from localhost ([::1]:53211 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdXqA-00029V-3R for ged-emacs-devel@m.gmane.org; Mon, 04 Nov 2013 23:02:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdXq0-00028N-1b for emacs-devel@gnu.org; Mon, 04 Nov 2013 23:02:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdXpp-000704-2H for emacs-devel@gnu.org; Mon, 04 Nov 2013 23:01:55 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:46627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdXpo-0006uo-IK for emacs-devel@gnu.org; Mon, 04 Nov 2013 23:01:45 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id B4B6E97069B; Tue, 5 Nov 2013 13:01:36 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A55DB1A275E; Tue, 5 Nov 2013 13:01:36 +0900 (JST) In-Reply-To: <87habsdlwo.fsf@nbtrap.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 182d01410b8d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:164950 Archived-At: Nathan Trapuzzano writes: > However, the fact is that nested backquotes _are_ for wizards. The > problem is, Emacs' nested backquotes aren't fully functional, the result > being that the code is harder for us non-wizards to read. Like Stefan, I couldn't understand what your example is supposed to do *without reading the expansion*. That I do understand, though it took some head-scratching. "It's pretty, so it must be right" is a fallacy. The temptation to write what really should be a cond with a large number of exceptional cases as a backquote construct looping over applications of a general function is probably not good for Emacs. Emacs is about user interface: its beauty mostly is, and generally should be, "skin deep". > 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. Note also that "powerful" (== expressive) syntax is not necessarily *efficient* syntax. This is especially so for Emacs Lisp. I don't really see why people want to write wizardly code in Emacs Lisp. Why not use a language designed for that purpose instead? Emacs Lisp is a slow implementation (though with lexical scope it can get a lot faster, it is unlikely to approach the performance of well-tuned Common Lisp implementations, let alone the faster Scheme implementations) with idiosyncratic, unstandardized semantics that change at the whim of the maintainers. This doesn't matter much in its primary role as a user interface (nothing in the computing environment is as slow as the user ;-). But UIs are typically a matter of attention to detail and context, rather than complex algorithms. 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.