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: Wed, 26 Sep 2012 07:11:17 -0700 Message-ID: <655ECEE359404A249CF8B4D26E192967@us.oracle.com> 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; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1348668738 31698 80.91.229.3 (26 Sep 2012 14:12:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 14:12:18 +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 16:12:20 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 1TGsLY-0003uA-Sw for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2012 16:12:17 +0200 Original-Received: from localhost ([::1]:44116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGsLT-0007Dt-Oo for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2012 10:12:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGsLM-0007Av-E8 for emacs-devel@gnu.org; Wed, 26 Sep 2012 10:12:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGsLC-0001Oy-OA for emacs-devel@gnu.org; Wed, 26 Sep 2012 10:12:04 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:29823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGsL1-0001N5-7n; Wed, 26 Sep 2012 10:11:43 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8QEBeRP022433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Sep 2012 14:11:41 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8QEBePb003655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2012 14:11:40 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8QEBd2h014949; Wed, 26 Sep 2012 09:11:40 -0500 Original-Received: from dradamslap1 (/10.159.176.54) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Sep 2012 07:11:39 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac2blyvAjfY57hkeQpGa98uh/fZHAQAVATgA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 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:153586 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. Deprecation is typically a recommendation to use the new and not the old. Hence doc about migration/compatibility to help users do that. This does not sound much like a deprecation - perhaps it's only half-hearted. > > 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] I've already agreed that adding `cl-' aliases is not bad. It's about the macros. Why deprecate them? > - 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*". So you use a prefix instead of a suffix to avoid conflicts. Still not a reason to deprecate the existing macro names. (`mapcar(*)' is not a macro, BTW.) > - 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). That's a conflict within Emacs itself. There I agree that something better is needed. There is no logical reason why Emacs subr.el needed to use the same name (e.g. `dolist') for something that exists in Common Lisp and in cl.el with a different meaning. (And no, I don't think that Emacs had `dolist' etc. before Common Lisp existed.) But so be it - we are where we are. The problem you point out is apparently not with the code that uses one `dolist' or the other, but with the handling of library loading and eager macro expansion. If a user does not load cl then `dolist' should come from subr.el. But I imagine that this might well become a headache at some level, and clearly it is error prone - easy for a programmer to not know that some library loaded by a user loads the cl version, etc. So I can see your point here. But that's an argument for deprecating those macros that present a problem because of a conflict between the cl.el version and the subr.el version. That does not apply to macros like `loop' that do not suffer from that disease. Why have a blanket deprecation instead of doing the right thing case by case? > > 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. I'm not fighting anything. I asked for a recommendation for adapting existing code, to which you suggested doing nothing and said that recommendations for respecting this "deprecation" will come when the code is moved to `obsolete'. So that is apparently the real moment of deprecation. So why proclaim deprecation (and even obsolescence) now and not then? I would have preferred to see a discussion about such a deprecation before it pounced on us fullblown. But so be it. (It's possible there was such a discussion and I missed it. But I haven't heard that asserted.)