From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Rationalising c[ad]\{2,5\}r. Date: Fri, 13 Mar 2015 16:41:24 +0000 Message-ID: <20150313164124.GA3972@acm.fritz.box> References: <20150311214324.GA2952@acm.fritz.box> <87zj7jb2p2.fsf@zigzag.favinet> <20150311230054.GB2952@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1426264936 10772 80.91.229.3 (13 Mar 2015 16:42:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Mar 2015 16:42:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 13 17:42:07 2015 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 1YWSez-0006sZ-D9 for ged-emacs-devel@m.gmane.org; Fri, 13 Mar 2015 17:42:05 +0100 Original-Received: from localhost ([::1]:37689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YWSet-0000Y4-PQ for ged-emacs-devel@m.gmane.org; Fri, 13 Mar 2015 12:41:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YWSeq-0000Xo-C4 for emacs-devel@gnu.org; Fri, 13 Mar 2015 12:41:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YWSej-0002F5-Jc for emacs-devel@gnu.org; Fri, 13 Mar 2015 12:41:56 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:10359 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YWSej-0002Ei-9K for emacs-devel@gnu.org; Fri, 13 Mar 2015 12:41:49 -0400 Original-Received: (qmail 24310 invoked by uid 3782); 13 Mar 2015 16:41:47 -0000 Original-Received: from acm.muc.de (pD9518314.dip0.t-ipconnect.de [217.81.131.20]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 13 Mar 2015 17:41:45 +0100 Original-Received: (qmail 5215 invoked by uid 1000); 13 Mar 2015 16:41:24 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.1 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:183850 Archived-At: Hello, Stefan. On Thu, Mar 12, 2015 at 09:53:13AM -0400, Stefan Monnier wrote: > > I propose the following solution: all these defuns should be in subr.el, > Emacs lived with just car/cdr for many many years. Then someone saw > that (car (cdr ...)) was fairly common in Elisp and decided that it was > worth moving cl.el's cadr/caar/cadr/cddr to subr.el (tho only those, > keeping the longer ones in cl.el). Yes. That causes problems (even if not serious ones) because the longer ones are loaded only with cl. > While there are a few uses of cXXr with more than 2 Xs, these aren't > very common, .... They're not that rare. I count 304 currently in Emacs, including eudc-cdaar (twice), in 78 files. That's a lot of files that need to require cl. > .... and I personally find them to be not terribly readable (basically, > car/cdr feel a bit like assembly-level programming to me, since they > access structure elements without giving them a name). They may not be very readable, but they're more readable as "(cadar ..)" than as "(car (cdr (car ..)))". > Additionally, these are usually somewhat inefficient (because some of > the inner car/cdr could/should be shared between different calls, but > our byte-compiler doesn't know how to do > common-subexpression-elimination, so it's better to spell them out as > something like (cadr (cadr x)) and then to manually move the inner cadr > to a let-binding to share it between various cXXr calls). I think the difference in execution time would tend towards zero. Each `car' or `cdr' is but a single compiled instruction, and let-binding variables, then accessing them, must be quite slow by comparison. > So while I'm not dead-set against adding many more cXXXr to subr.el, I'm > not in favor of it, since I think it encourages a poorly-readable and > inefficient programming style. OK. How about us sticking with the current maximum of four? > This said, I am in favor of moving cl--compiler-macro-cXXr to subr.el and > making use of it (in place of inlining) for cadr/caar/cddr/cdar. > [ It's my fault if it's not done that way yet, but that was just > a mistake on my part. ] I've incorporated that into the current version of my change. > > Just one thing, though, since `number-sequence' is also defined in > > subr.el, I'd have to wrap it in `eval-and-compile' to be able to use it > > in my macros. > I'm not sure it's necessary, because subr.el is preloaded (and preloaded > early, i.e. before eager macro-expansion is enabled). I'll try making my changes to subr.el then bootstrapping. > Stefan -- Alan Mackenzie (Nuremberg, Germany).