From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Why aren't there functions such as filter, take-while, etc. "by default"? Date: Mon, 26 Apr 2010 10:29:56 +0200 Organization: Organization?!? Message-ID: <87eii24nwb.fsf@lola.goethe.zz> References: <87fx2j5wle.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1272270622 18732 80.91.229.12 (26 Apr 2010 08:30:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 26 Apr 2010 08:30:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 26 10:30:21 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O6Jhs-0004Vi-Ot for ged-emacs-devel@m.gmane.org; Mon, 26 Apr 2010 10:30:21 +0200 Original-Received: from localhost ([127.0.0.1]:51100 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6Jhr-0007bk-TG for ged-emacs-devel@m.gmane.org; Mon, 26 Apr 2010 04:30:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6Jhl-0007bf-Uh for emacs-devel@gnu.org; Mon, 26 Apr 2010 04:30:13 -0400 Original-Received: from [140.186.70.92] (port=42704 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6Jhk-0007bX-7s for emacs-devel@gnu.org; Mon, 26 Apr 2010 04:30:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6Jhi-0001Cy-N9 for emacs-devel@gnu.org; Mon, 26 Apr 2010 04:30:12 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:52755) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6Jhi-0001Ck-Bt for emacs-devel@gnu.org; Mon, 26 Apr 2010 04:30:10 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O6Jhf-0004Qu-V2 for emacs-devel@gnu.org; Mon, 26 Apr 2010 10:30:07 +0200 Original-Received: from p5b2c1b55.dip.t-dialin.net ([91.44.27.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Apr 2010 10:30:07 +0200 Original-Received: from dak by p5b2c1b55.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Apr 2010 10:30:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ connect(): No such file or directory Original-Lines: 52 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p5b2c1b55.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.92 (gnu/linux) Cancel-Lock: sha1:6CnelGHsr+Op97nC1AkyE9KOmME= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:124214 Archived-At: Stefan Monnier writes: >>> Why does it have to be so hard to write Emacs Lisp without requiring cl? >>> Why aren't there functions such as filter (the equivalent of >>> remove-if-not in cl-seq.el), take-while, reduce etc. "native" in >>> Emacs? >> They make for no-surprise efficient programs primarily when the language >> has lexical closures. > > I do not understand this. What do you mean to say, and why is dynamic > scoping relevant (i.e. why wouldn't the same argument apply to mapcar, > mapconcat, etc...). It does apply to the latter functions equally well. However, those tend to be usable with primitive functions without dynamic consequences somewhat more often. The more complex filtering functions of Common Lisp are very much employed as an alternate programming style for iteration. If there is no conceivable way to transform them into byte code (or whatever) with a similar efficiency and predictability as the equivalent iteration code, they seem like a bad idea. When learning Elisp, I have been negatively surprised by the bad performance of using map* functions as opposed to straight iteration. I should really like to see a version of Elisp where one-shot lambda functions with outer references a) need not be written (let ((outer ...)) ... `(lambda (x) (... ',outer ... b) byte compile into the same or equally efficient byte code as their open-coded iteration equivalents It is ok if the debugger can use debugging info/signatures for approximating dynamical access for the user to the anonymous stack slots of lexical variables, but normal operation should not be affected. Since Lisp, after all, is supposed to be a functional language, I'd like to see Emacs Lisp not penalize functional programming styles. Currently it does, and so I don't think general-purpose iteration constructs encouraging lambda predicates are a good idea for now. It would appear that both the lexbind branch as well as an all-out guile strategy could provide paths forward. The latter would seem to have the advantage that we can get rid of the whole byte compilation issue in the Emacs codebase (which would likely get more rather than less complex with lexbind). _And_ give guile a large kick forward in improvement incentives. Likely more than the boost that the Emacs project gives Bazaar, and with more immediate benefits. -- David Kastrup