From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: policy, recommendations regarding `cl-*' Date: Tue, 25 Sep 2012 19:51:43 -0700 Message-ID: <5B02507A2A7040EE81A33348E6AAB04D@us.oracle.com> References: <83pq59hl5w.fsf@gnu.org><78C072FCB2534C21835E7E6788B10624@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1348627940 32611 80.91.229.3 (26 Sep 2012 02:52:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 02:52:20 +0000 (UTC) Cc: 'Eli Zaretskii' , emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 26 04:52:24 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 1TGhjW-00086b-59 for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2012 04:52:18 +0200 Original-Received: from localhost ([::1]:47675 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGhjR-0001dY-1C for ged-emacs-devel@m.gmane.org; Tue, 25 Sep 2012 22:52:13 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGhjP-0001dQ-6a for emacs-devel@gnu.org; Tue, 25 Sep 2012 22:52:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGhjO-0004O6-7k for emacs-devel@gnu.org; Tue, 25 Sep 2012 22:52:11 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:45126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGhjM-0004Nf-Mn; Tue, 25 Sep 2012 22:52:08 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8Q2q5Du003746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Sep 2012 02:52:06 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8Q2q39c011588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2012 02:52:03 GMT Original-Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8Q2q2ZU001052; Tue, 25 Sep 2012 21:52:02 -0500 Original-Received: from dradamslap1 (/10.159.183.137) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Sep 2012 19:52:02 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac2bhHLxbWHmXgo9TLCBV92Nv/uh2gACLkTw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 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:153552 Archived-At: > Drew. Just keep using (require 'cl) for code that needs to run in > Emacs<24.3 and move on. Yes, I hope to remove cl.el at the > some point. Sadly, I know this time is not anywhere close. OK, will do. That is, (eval-when-compile (require 'cl)). I do not use cl at runtime. > As for "new stuff more compatible with CL but using the wrong name", > I do not know what you're referring to (you're using cl-loop as an > example, but loop is now an alias for cl-loop, so that can't > be it), so just be concrete (but brief) and maybe I can explain it. I do not see anything in either of the two messages I sent that resembles the phrase you quote or the terms it uses ("compatible"? "wrong name"?). I have no idea what that phrase means or where you got it. AFAICT, it is not from me. I don't understand it, and I cannot answer you. Perhaps you are really quoting someone else? Wrt `cl-loop' and `loop': As long as one is an alias for the other, I have no problem using either. Of course. What I do not think is a great idea is the deprecation. (Was there even a proposal about deprecation and a discussion of the proposal?) As I made clear, I am in favor of having a separate "namespace"-clean library that systematically uses the prefix `cl-'. What I disagree is a good idea is to _deprecate_ the longstanding Emacs versions that do not have such a prefix. IOW, if the aim, as was expressed in the original discussion where you proposed `cl-lib.el' and the prefix `cl-', is simply to give users a clean way to use cl.el functions at runtime, then I'm all in favor of that, and I agree with the prefixing. That is very different from deprecating the cl.el stuff. And that deprecation is not just some vaguely "at some point" hope on your part - you are deprecating it *now*. And deprecation calls out for doc about how to move from the old to the new, as I mentioned. The CL manual and NEWS are silent on this, so far. This too is not great. (I realize that we are not ready to release yet, so there is still time to make this right.) But above all I am specifically concerned about the macros, since those are what I use (I do not use the functions at runtime). 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. And I'm hoping you will change your mind about it. Again, I have no problem with "duplicating" the macros via aliasing. My problem is with their deprecation. That is my concern for code that I maintain: just the macro names. Above and in the previous two messages, I've expressed additional concerns that do not necessarily affect me directly - about the Emacs code organization and the process of discussing, deprecating, and communicating compatibility/migration information about deprecations. But my immediate concern is maintaining code for multiple Emacs versions that uses cl.el macros.