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: policy, recommendations regarding `cl-*' Date: Tue, 25 Sep 2012 23:29:39 -0400 Message-ID: References: <83pq59hl5w.fsf@gnu.org> <78C072FCB2534C21835E7E6788B10624@us.oracle.com> <5B02507A2A7040EE81A33348E6AAB04D@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348630186 14521 80.91.229.3 (26 Sep 2012 03:29:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 03:29:46 +0000 (UTC) Cc: 'Eli Zaretskii' , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 26 05:29:51 2012 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 1TGiJq-0006ec-JY for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2012 05:29:50 +0200 Original-Received: from localhost ([::1]:33672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGiJl-0002tW-E3 for ged-emacs-devel@m.gmane.org; Tue, 25 Sep 2012 23:29:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGiJj-0002tB-Bt for emacs-devel@gnu.org; Tue, 25 Sep 2012 23:29:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGiJi-0008NO-Ia for emacs-devel@gnu.org; Tue, 25 Sep 2012 23:29:43 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:51830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGiJg-0008MB-Q2; Tue, 25 Sep 2012 23:29:40 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0FAG6Zu09FxLT4/2dsb2JhbABEr1qEN4EIghUBAQQBViMFCws0EhQYDSSIHAW6CZBEA6MzgViDBQ X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="199989032" Original-Received: from 69-196-180-248.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.248]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 25 Sep 2012 23:29:40 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9824958EAB; Tue, 25 Sep 2012 23:29:39 -0400 (EDT) In-Reply-To: <5B02507A2A7040EE81A33348E6AAB04D@us.oracle.com> (Drew Adams's message of "Tue, 25 Sep 2012 19:51:43 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:153553 Archived-At: > And deprecation calls out for doc about how to move from the old to > the new, as I mentioned. We'll do that when we move cl.el to lisp/obsolete/, which I expect is still several years away. > Why on earth are you deprecating existing macros in favor of the same > macros with a `cl-' prefix? I haven't seen an answer to that yet. Various reasons, tho I don't think it matters much: - why have the old names when you have the new names? [I know you'll say backward compatibility, but the question is meant in the long term. cl.el is still kept for compatibility for now] - several old names are actually problematic: - it starts with mild problems such as mapcar*, function* and friends where the * was needed just to avoid conflicts, where in the new names you can use the natural "cl-mapcar" rather than "cl-mapcar*". - then gets to the actual conflicts like dolist/dotimes (luckily push/pop has been fixed by extending Elisp's builtin push/pop to cover CL's semantics) which even recently brought real problems where eager macroexpansion failed for some files because substituting subr.el's dolist with CL's dolist creates a circular dependency between CL macroexp and gv (IIRC). > And I'm hoping you will change your mind about it. Not a chance. > But my immediate concern is maintaining code for multiple Emacs versions that > uses cl.el macros. You're fighting a non-problem. Stefan