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: Wed, 26 Sep 2012 15:44:15 -0400 Message-ID: References: <83pq59hl5w.fsf@gnu.org> <78C072FCB2534C21835E7E6788B10624@us.oracle.com> <5B02507A2A7040EE81A33348E6AAB04D@us.oracle.com> <655ECEE359404A249CF8B4D26E192967@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348688667 23852 80.91.229.3 (26 Sep 2012 19:44:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 19:44:27 +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 21:44:32 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 1TGxX0-0000tl-Tq for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2012 21:44:27 +0200 Original-Received: from localhost ([::1]:37703 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGxWv-0007n2-V7 for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2012 15:44:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGxWs-0007mm-R2 for emacs-devel@gnu.org; Wed, 26 Sep 2012 15:44:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGxWr-00026A-JG for emacs-devel@gnu.org; Wed, 26 Sep 2012 15:44:18 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:55996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGxWr-000261-Bf; Wed, 26 Sep 2012 15:44:17 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q8QJiFhT028071; Wed, 26 Sep 2012 15:44:15 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 2053CB404D; Wed, 26 Sep 2012 15:44:15 -0400 (EDT) In-Reply-To: <655ECEE359404A249CF8B4D26E192967@us.oracle.com> (Drew Adams's message of "Wed, 26 Sep 2012 07:11:17 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 132.204.246.20 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:153600 Archived-At: > 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. Definitely half-hearted: real deprecation would mean moving to lisp/obsolete. The only extent to which it's currently deprecated is that I used the word "deprecated" in the NEWS file. C-h f loop RET won't tell you that it's deprecated and neither will the byte-compiler. > I've already agreed that adding `cl-' aliases is not bad. It's about the > macros. Why deprecate them? Why should macros be treated differently? >> - 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. That's not the point. The point is that "cl-" is used systematically for every element, whereas "*" was only used in an ad-hoc manner for those elements where the was a conflict and where the implementors decided the conflict had to be solved by renaming. > 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. It's kept a subset of the CL meaning, hence the same name. And being able to choose names freely in subr.el is the whole point of not allowing the use of cl.el. > 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. Yes, a package which uses subr.el's dolist will end up using CL's dolist (against its wishes) if cl.el happens to be loaded. This may cause cl-macs to be loaded which in turn will cause other things to be loaded. So when you consider dependencies, any dolist use should be considered as potentially using CL's dolist (and hence using `block'), even if it sticks to subr.el's subset. > 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. Yes, CL's dolist and dotimes are the parts of CL I hope to deprecate as soon as possible. > 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? Because CL has tons of stuff and I don't have time to go one by one. We can still move things back to "non-prefixed" on a case by case basis anyway, now or in the future. I first wanted to clean up the namespace. > 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? It's a change that will affect many packages, so I prefer getting people to get used to the idea and maybe even start moving to cl-lib for those rare packages where backward compatibility is not an issue. > 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.) I don't see the point of a discussion about it since it's currently nothing more than a word in etc/NEWS, with no other concrete impact, it just clarifies what's the intention behind cl-lib (i.e. it's not just to have a version that's OK even at run-time, but really to replace the old). Stefan