From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs Package Management Date: Wed, 16 Sep 2009 14:41:45 -0400 Message-ID: References: <485b0c380808011427n4d3144eey3f8daf3abac83bf4@mail.gmail.com> <87d45vzt4j.fsf@hagelb.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1253126534 29723 80.91.229.12 (16 Sep 2009 18:42:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2009 18:42:14 +0000 (UTC) Cc: tromey@redhat.com, emacs-devel@gnu.org, rms@gnu.org, joakim@verona.se, phil@hagelb.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 16 20:42:06 2009 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.50) id 1MnzS9-0002eJ-JG for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2009 20:42:05 +0200 Original-Received: from localhost ([127.0.0.1]:58118 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnzS9-0002BY-3c for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2009 14:42:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnzS4-0002BM-2o for emacs-devel@gnu.org; Wed, 16 Sep 2009 14:42:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnzRz-0002Ak-Ma for emacs-devel@gnu.org; Wed, 16 Sep 2009 14:41:59 -0400 Original-Received: from [199.232.76.173] (port=38670 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnzRz-0002Ah-Di for emacs-devel@gnu.org; Wed, 16 Sep 2009 14:41:55 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:52774 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnzRw-0001dV-6h; Wed, 16 Sep 2009 14:41:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAM/OsEpFpZBe/2dsb2JhbACBU94whBcFh30 X-IronPort-AV: E=Sophos;i="4.44,399,1249272000"; d="scan'208";a="45787025" Original-Received: from 69-165-144-94.dsl.teksavvy.com (HELO pastel.home) ([69.165.144.94]) by ironport2-out.pppoe.ca with ESMTP; 16 Sep 2009 14:41:45 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A60E6827E; Wed, 16 Sep 2009 14:41:45 -0400 (EDT) In-Reply-To: (Miles Bader's message of "Tue, 15 Sep 2009 17:30:03 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:115395 Archived-At: > * remove-if / delete-if / remove-if-not / delete-if-not > (_without_ the CL keyword arguments) > [These are very handy for filtering lists of values. The keyword > arguments are not very important, and keywordless core versions > would be compatible with keyword-supporting cl.el versions in the > same way that core `dolist' is compatible with cl.el `dolist'] Clearly we do not need both the *-if and the *-if-not, but I agree that such a filtering function would come in handy at times. OTOH the (delq nil (mapcar ...)) idiom isn't a bad replacement. > * mapcan > [Useful for mapping when there isn't a 1-1 relationship between > argument list elements and result list elements] I find that (apply 'nconc (mapcar ...)) works just as well, so I don't find it very useful. > * multiple-argument mapping (mapcar, mapc, etc) functions > [Useful and obvious generalization of existing mapping functions; > Gnus already contains its own implementation of a multiple-argument > mapcar] I wonder what kind of impact it does/would have on performance. In any case my main concern right now is that I do not want to introduce any more of the "duplicate definition", like the ones of `push' and `dolist'. I just found out that my "clever" idea of reloading stale preloaded files in lisp/Makefile's `compile_one' rule bumps into this problem pretty badly: if both subr.el and vc-hooks.el are stale, then when recompiling vc-hooks.el, we end up first reloading subr.el which overrides the push definition previously installed by cl.el, leading to a vc-hooks.elc that is corrupt (because it requires CL's version of push). Stefan