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 15:09:05 -0700 Message-ID: <78C072FCB2534C21835E7E6788B10624@us.oracle.com> References: <83pq59hl5w.fsf@gnu.org> 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 1348610974 10275 80.91.229.3 (25 Sep 2012 22:09:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2012 22:09:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Eli Zaretskii'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 26 00:09:39 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 1TGdJy-0006qX-KJ for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2012 00:09:38 +0200 Original-Received: from localhost ([::1]:54973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGdJt-0008Mx-KC for ged-emacs-devel@m.gmane.org; Tue, 25 Sep 2012 18:09:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGdJr-0008Ms-0C for emacs-devel@gnu.org; Tue, 25 Sep 2012 18:09:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGdJp-0005fa-MD for emacs-devel@gnu.org; Tue, 25 Sep 2012 18:09:30 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:30754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGdJn-0005fL-R4; Tue, 25 Sep 2012 18:09:27 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8PM9PYl009466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Sep 2012 22:09:25 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8PM9OjO029496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 22:09:24 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 q8PM9OfC023614; Tue, 25 Sep 2012 17:09:24 -0500 Original-Received: from dradamslap1 (/10.159.183.137) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Sep 2012 15:09:23 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83pq59hl5w.fsf@gnu.org> Thread-Index: Ac2bYO2oFtT7w3jbRNKxErWoKtWXeQAANYlw 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: 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:153545 Archived-At: > I think, as long as you need to support versions of Emacs without > cl-lib, just leave the code as it was, i.e. use 'loop' in the above > example. 1. That's certainly what I am doing for now, at least. But deprecation typically expresses an intention to later desupport. My question is really what is recommended for supporting multiple Emacs releases when `loop' etc. are no longer supported. The point in separating deprecation from desupport in time is generally to give users a heads-up and time to adapt. In principle, users would want to start now to prepare for later desupport. And that is why software providers typically provide migration suggestions at the time of deprecation, not just at the time of desupport. For free software, at least, it makes sense for such suggestions to include how to support multiple releases. 2. It's not really clear to me either why it is the Emacs-traditional versions that are being changed to have the prefix `cl-' now. If it were the other way around (give the new versions a prefix), then there would be no backward compatibility problem. No? I'm probably missing something, but why is it important for Emacs to use a name without a prefix such as `cl-' for something new, even if it might be closer to the real Common Lisp meaning than is the old? Why not continue to use, say, `loop' for what it has always been, and add a new `super-duper-closer-to-c-l-loop' macro for a better, closer-to-the-real-thing version? I'm guessing there were packaging considerations involved, and I imagine they had something to do with the requests by some people to use more cl.el stuff at runtime. But the overall picture is not real clear to me. And as I said, neither NEWS nor the CL manual helps in this regard. Nor did searching emacs-devel for "cl-lib" help. Searching more than subject lines, I did however find a message that says this: > > But I guess this is a common problem. Isn't there a common > > solution? I.e. is there a package containing the cl > > functions with a proper name prefix like `cl-signum'? > SM> That's indeed the upcoming solution: as discussed somewhat SM> recently, I suggested we provide a new package `cl-lib' SM> which would be like CL but with a clean namespace (i.e. SM> everything starts with "cl-"). Then (require 'cl-lib) SM> would be perfectly acceptable. cl.el would become a file SM> that just provides a bunch of aliases for backward SM> compatibility purposes. That just states what was done, without much rationale. And it says nothing about deprecation. (But in retrospect you can read a lot into that last sentence.) I must have missed the discussion that led to that decision. I do see this supportive reply - by me - to an earlier thread: SM> I think a first step is to provide a new package `cl-lib' SM> which would provide the CL functions (i.e. all those functions SM> people seem to like but can't use because we disallow CL at SM> runtime) under a clean "cl-" prefix. This would allow all of SM> CL to be used (either via (require 'cl-lib) or (eval-when-compile SM> (require 'cl))) and would hence address the most pressing issues. D> D> 1+ D> D> (But I don't see how (eval-when-compile (require 'cl))) would D> allow all of CL to be used, unless you meant only at compile time.) D> D> That also has the advantage of skirting, for now, (a) the D> problem of conflicts with Emacs stuff with the same name and D> (b) the work needed to replace the more limited Emacs stuff that D> has the same name. But again, there was nothing there about _deprecation_. I thought we were discussing only adding an additional library with the `cl-' prefix, for those who wanted to use CL functions at runtime. I am in favor of that, as I indicated. What was discussed there does not imply that someone would need to change their code because we also intend to desupport `remove-if' etc. in favor of `cl-remove-if' etc. But that's apparently I'm seeing now as the real intention. This, in NEWS, is pretty clear in stating that we are in fact _deprecating_ `remove-if', `loop', and so on: The old `cl' is now deprecated and is just a bunch of aliases that provide the old non-prefixed names. (Notice how similar that "bunch of aliases" part is to the previous vague statement, above? But now we've added "is now deprecated and"!) I completely missed the discussion (if it existed) that led to that decision. What the reason was given for deprecating? More importantly (for me): What I use are _macros_, like `loop'. I have respected the guideline to avoid using CL functions at runtime. So why on earth are we also deprecating macros `loop' etc. in favor of macros `cl-loop' etc.? That's what I really don't get. Why should I need to change code that uses those longstanding macros, even if new, improved, less limited ones might be made available? For something like this, I would have expected at least some kind of an announcement mail, explaining the design goal and the implemented solution to meet it. (And I would have preferred a discussion that led up to a decision.) What am I missing? What's the point? What problem are we trying to solve, and how does this deprecation help us solve it? 3. Coming back to my original question: Assuming that I _will_ need to change code that uses `loop' etc., just what code changes are recommended, to allow users like me to continue to support multiple Emacs versions? I will do nothing for now, of course, as Eli suggests. But what guidelines are there for where we're headed?