Declaring cl.el obsolete

Declaring cl.el obsolete

[Stefan Monnier]

cl-lib was released 6 years and its uptake has been much more successful
than in my wildest dreams.

AFAIK it has been technically obsolete already for the last 6 years, in
that everything it offers is provided by cl-lib or lexical-binding.

I count 6 files in master that still (require 'cl).  Of those, 2 only
require `cl` conditionally (when running on XEmacs or on Emacs<21),
2 are themselves obsolete (cl-compat and lucid.el), so really there are
only 2 packages bundled with Emacs and still actively using `cl`:
vhdl-mode and MH-E.

So I think Emacs-27 is a good time to declare it officially obsolete
(and hence move it to the lisp/obsolete directory).

Comments, objections?


        Stefan

Re: Declaring cl.el obsolete

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 22 May 2019 23:26:39 -0400
> 
> I count 6 files in master that still (require 'cl).

Did you also look in ELPA?  And what about MELPA?

Maybe we should do this more gradually, like first deprecate it and
print some kind of warning for it?

Re: Declaring cl.el obsolete

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So I think Emacs-27 is a good time to declare it officially obsolete
> (and hence move it to the lisp/obsolete directory).

I think there's a probably a gazillion out-of-tree packages out there
with (require 'cl), so actually removing cl at some point would break a
lot of stuff...  and without much of a technical reason, I think?

So I'm against declaring it obsolete.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Declaring cl.el obsolete

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think there's a probably a gazillion out-of-tree packages out there
> with (require 'cl),

OK, "722,834 code results" is a bit smaller than "gazillion", but:

https://github.com/search?utf8=%E2%9C%93&q=%22%28require+%27cl%29%22+extension%3Ael&type=Code&ref=advsearch&l=&l=

(You apparently have to be logged in to do the search.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Declaring cl.el obsolete

[Noam Postavsky]

On Thu, 23 May 2019 at 00:47, Eli Zaretskii <eliz@gnu.org> wrote:

> Maybe we should do this more gradually, like first deprecate it and
> print some kind of warning for it?

Isn't that what moving to lisp/obsolete/ does?

Re: Declaring cl.el obsolete

[Stefan Monnier]

>> So I think Emacs-27 is a good time to declare it officially obsolete
>> (and hence move it to the lisp/obsolete directory).
> I think there's a probably a gazillion out-of-tree packages out there
> with (require 'cl), so actually removing cl at some point would break a
> lot of stuff...  and without much of a technical reason, I think?

I don't intend to ever completely kill cl.el, actually.
The way I see it, we'd obsolete it in Emacs-27, then move it to GNU ELPA
somewhere around Emacs-30.


        Stefan

Re: Declaring cl.el obsolete

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Thu, 23 May 2019 06:28:41 -0400
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Emacs developers <emacs-devel@gnu.org>
> 
> On Thu, 23 May 2019 at 00:47, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Maybe we should do this more gradually, like first deprecate it and
> > print some kind of warning for it?
> 
> Isn't that what moving to lisp/obsolete/ does?

Maybe.  I'm not really sure what we want to do with this.

Re: Declaring cl.el obsolete

[Ken Olum]

If I understand things correctly, the important difference between cl
and cl-lib is that the former provides actual Common Lisp compatibility,
whereas the latter allows you to use some Common Lisp features by
renaming functions that are in Common Lisp but not in Emacs lisp by
adding "cl-".  My goal is just to be able to write code without worrying
about which functions are in which language, so I would like to stick
with cl.  Thus it seems to me that cl-lib provides different
functionality and doesn't render cl obsolete.

For whatever it's worth, some of the controversy here and in the
backquote discussion seems to arise from differences between people who
are Lisp programmers in the rest of their lives and those using it only
for emacs.

                                        Ken

Re: Declaring cl.el obsolete

[Sam Steingold]

> * Ken Olum <xqb@pbfzbf.cul.ghsgf.rqh> [2019-05-23 11:08:31 -0400]:
>
> My goal is just to be able to write code without worrying about which
> functions are in which language, so I would like to stick with cl.

This is understandable, but I must remind everyone that (require 'cl) does
_not_ turn Emacs Lisp into Common Lisp (emphatically and intentionally).
I am sure you are aware of this sad reality.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1671
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://jihadwatch.org http://no2bds.org http://mideasttruth.com
A poet who reads his verse in public may have other nasty habits.

Re: Declaring cl.el obsolete

[Romanos Skiadas]

On 23/05/2019 09:50, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> I think there's a probably a gazillion out-of-tree packages out there
>> with (require 'cl),
> OK, "722,834 code results" is a bit smaller than "gazillion", but:
>
> https://github.com/search?utf8=%E2%9C%93&q=%22%28require+%27cl%29%22+extension%3Ael&type=Code&ref=advsearch&l=&l=
>
> (You apparently have to be logged in to do the search.)
>
This is slightly misleading, it seems like github also takes into 
account (require 'cl-lib), e.g. it matched

https://github.com/chetnashah/dotemacs/blob/f6b1d41d52000e70ec970499c98e424af3cd2e40/.emacs.d/elpa/slime-20160907.602/contrib/slime-listener-hooks.el 


from page 100:

https://github.com/search?l=&p=100&q=%22%28require+%27cl%29%22+extension%3Ael&ref=advsearch&type=Code&utf8=%E2%9C%93

And it also takes into account comments and ifs for older Emacsen, which 
presumably are ok.

- Romanos

Re: Declaring cl.el obsolete

[조성빈]

> 2019. 5. 24. 오전 2:03, Romanos Skiadas <rom.skiad@gmail.com> 작성:
> 
> On 23/05/2019 09:50, Lars Ingebrigtsen wrote:
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> 
>>> I think there's a probably a gazillion out-of-tree packages out there
>>> with (require 'cl),
>> OK, "722,834 code results" is a bit smaller than "gazillion", but:
>> 
>> https://github.com/search?utf8=%E2%9C%93&q=%22%28require+%27cl%29%22+extension%3Ael&type=Code&ref=advsearch&l=&l=
>> 
>> (You apparently have to be logged in to do the search.)
>> 
> This is slightly misleading, it seems like github also takes into account (require 'cl-lib), e.g. it matched
> 
> https://github.com/chetnashah/dotemacs/blob/f6b1d41d52000e70ec970499c98e424af3cd2e40/.emacs.d/elpa/slime-20160907.602/contrib/slime-listener-hooks.el 
> 
> from page 100:
> 
> https://github.com/search?l=&p=100&q=%22%28require+%27cl%29%22+extension%3Ael&ref=advsearch&type=Code&utf8=%E2%9C%93

I also see GitHub matching (require ‘cl-lib) from page 3:

Matched https://github.com/martialboniou/Dots/blob/e116fb08e406243f847af63760877d7c6d14a91c/emacs/emacs.d.symlink/lisp/run-tests.el
At 
https://github.com/search?p=3&q=%22%28require+%27cl%29%22+extension%3Ael

> And it also takes into account comments and ifs for older Emacsen, which presumably are ok.
> 
> - Romanos
> 
> 

Re: Declaring cl.el obsolete

[Stefan Monnier]

>> > Maybe we should do this more gradually, like first deprecate it and
>> > print some kind of warning for it?
>> Isn't that what moving to lisp/obsolete/ does?
> Maybe.

I don't understand this "Maybe".

Moving a package to lisp/obsolete (which always comes with an
announcement in etc/NEWS) does two things, AFAICT:

- announce that this package is officially deprecated.
- cause a warning to be emitted when the package is used.

IOW exactly what you say we should do "first", except maybe that we use
the term "obsoleted" instead of "deprecated".  So is the specific word
the source of your doubt?


        Stefan

Re: Declaring cl.el obsolete

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Noam Postavsky <npostavs@gmail.com>,  emacs-devel@gnu.org
> Date: Fri, 24 May 2019 10:28:03 -0400
> 
> IOW exactly what you say we should do "first", except maybe that we use
> the term "obsoleted" instead of "deprecated".  So is the specific word
> the source of your doubt?

Yes.

And I wasn't the only one who didn't necessarily agree with your
proposal.

Re: Declaring cl.el obsolete

[Stefan Monnier]

>> IOW exactly what you say we should do "first", except maybe that we use
>> the term "obsoleted" instead of "deprecated".  So is the specific word
>> the source of your doubt?
> Yes.

Then let's deprecate it instead of obsolete it (with a corresponding
warning when you use it).

I personally don't care about the difference.


        Stefan
        

PS: But I'm curious why you explain why you'd prefer "deprecate" over
"obsolete"?  We usually don't really distinguish between the two,
AFAICT, since we almost never deprecate something unless it has
a replacement which causes it to be obsolete.  In this case, the reason
why we'd deprecate it is because there are alternatives we prefer, so in
this sens it's "obsolete".  Also we have infrastructure to say something
is obsolete in a "formal" way which causes corresponding messages to be
emitted when applicable, whereas we don't have such an infrastructure
for "deprecated".

Re: Declaring cl.el obsolete

[Romanos Skiadas]

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]


On 24/05/2019 02:22, 조성빈 wrote:
>
>> 2019. 5. 24. 오전 2:03, Romanos Skiadas <rom.skiad@gmail.com> 작성:
>>
>> On 23/05/2019 09:50, Lars Ingebrigtsen wrote:
>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>>
>>>> I think there's a probably a gazillion out-of-tree packages out there
>>>> with (require 'cl),
>>> OK, "722,834 code results" is a bit smaller than "gazillion", but:
>>>
>>> https://github.com/search?utf8=%E2%9C%93&q=%22%28require+%27cl%29%22+extension%3Ael&type=Code&ref=advsearch&l=&l=
>>>
>>> (You apparently have to be logged in to do the search.)
>>>
>> This is slightly misleading, it seems like github also takes into account (require 'cl-lib), e.g. it matched
>>
>> https://github.com/chetnashah/dotemacs/blob/f6b1d41d52000e70ec970499c98e424af3cd2e40/.emacs.d/elpa/slime-20160907.602/contrib/slime-listener-hooks.el
>>
>> from page 100:
>>
>> https://github.com/search?l=&p=100&q=%22%28require+%27cl%29%22+extension%3Ael&ref=advsearch&type=Code&utf8=%E2%9C%93
> I also see GitHub matching (require ‘cl-lib) from page 3:
>
> Matched https://github.com/martialboniou/Dots/blob/e116fb08e406243f847af63760877d7c6d14a91c/emacs/emacs.d.symlink/lisp/run-tests.el
> At
> https://github.com/search?p=3&q=%22%28require+%27cl%29%22+extension%3Ael

Yes, according to the github search documentation, ' and ) are not 
considered when searching:

You can't use the following wildcard characters as part of your search 
query: |. , : ; / \ ` ' " = * ! ? # $ & + ^ | ~ < > ( ) { } [ ]|. The 
search will simply ignore these symbols

https://help.github.com/en/articles/searching-code

I assume the search sees `(require 'cl)` simply as `require cl` and that 
can match either cl or cl-lib or other libraries that begin with cl.

- Romanos


>
>> And it also takes into account comments and ifs for older Emacsen, which presumably are ok.
>>
>> - Romanos
>>
>>

[-- Attachment #2: Type: text/html, Size: 4247 bytes --]

Re: Declaring cl.el obsolete

[Stefan Monnier]

> cl-lib was released 6 years ago and its uptake has been much more successful
> than in my wildest dreams.
> AFAIK it has been technically obsolete already for the last 6 years, in
> that everything it offers is provided by cl-lib or lexical-binding.

In the ensuing discussions, there have been the following objections:
1- Eli doesn't like using "obsolete" and would prefer "deprecated".
2- Lars pointed out that `cl` is still in fairly wide use outside of Emacs.
3- Ken explained that he prefers the non-prefixed names.

Regarding (3), I know several people feel that way, and that's a valid
preference, but I see no reason why the `cl` package satisfying this
preference needs to be distributed with Emacs.

Regarding (2), I pointed out that I don't foresee `cl` disappearing
completely any time soon.  Instead, it will likely move to GNU ELPA when
we finally remove it from Emacs.

As for (1), I used the word "deprecated".

So any remaining objection to the patch below?


        Stefan


diff --git a/etc/NEWS b/etc/NEWS
index 5378e56bca..00c076a18e 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -485,6 +485,8 @@ current and the previous or the next line, as before.
 \f
 * Changes in Specialized Modes and Packages in Emacs 27.1
 
+** The 'cl' package is now officially deprecated in favor of `cl-lib`.
+
 +++
 ** winner
 *** A new variable, `winner-boring-buffers-regexp', has been added.
diff --git a/lisp/emacs-lisp/cl.el b/lisp/obsolete/cl.el
similarity index 99%
rename from lisp/emacs-lisp/cl.el
rename to lisp/obsolete/cl.el
index 71be1d1b49..417c757ed5 100644
--- a/lisp/emacs-lisp/cl.el
+++ b/lisp/obsolete/cl.el
@@ -3,6 +3,7 @@
 ;; Copyright (C) 2012-2019 Free Software Foundation, Inc.
 
 ;; Author: Stefan Monnier <monnier@iro.umontreal.ca>
+;; Deprecated-since: 27.1
 ;; Keywords: extensions
 
 ;; This file is part of GNU Emacs.
diff --git a/lisp/subr.el b/lisp/subr.el
index f1a4e8bb29..e7f40e1cf5 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4445,7 +4445,7 @@ do-after-load-evaluation
            (package (intern (substring file 0
 			               (string-match "\\.elc?\\>" file))
                             obarray))
-	   (msg (format "Package %s is obsolete" package)))
+	   (msg (format "Package %s is deprecated" package)))
       ;; Cribbed from cl--compiling-file.
       (when (or (not (fboundp 'byte-compile-warning-enabled-p))
                 (byte-compile-warning-enabled-p 'obsolete package))

RE: Declaring cl.el obsolete

[Drew Adams]

> > cl-lib was released 6 years ago...
> > everything it offers is provided by cl-lib or lexical-binding.

Maybe.  When those are available, which they're
not for some older releases.  And not everything:
aliases to names without `cl-' are missing.

> In the ensuing discussions, there have been the following objections:
> 1- Eli doesn't like using "obsolete" and would prefer "deprecated".
> 2- Lars pointed out that `cl` is still in fairly wide use outside of
> Emacs.
> 3- Ken explained that he prefers the non-prefixed names.
> 
> Regarding (3), I know several people feel that way, and that's a valid
> preference, but I see no reason why the `cl` package satisfying this
> preference needs to be distributed with Emacs.
> 
> Regarding (2), I pointed out that I don't foresee `cl` disappearing
> completely any time soon.  Instead, it will likely move to GNU ELPA
> when we finally remove it from Emacs.
> 
> As for (1), I used the word "deprecated".
> 
> So any remaining objection to the patch below?

I don't really want to get into this can of worms,
but I guess I should say what I think.

1. Some code will continue to use `cl.el', at least
   for compatibility with both older and newer Emacs
   versions.  Even for compilation-time use of macros.
   Some older Emacs versions don't have `cl-lib.el'
   (or `cl-macs.el').  Even `lexical-let' and `flet',
   however imperfect, are important for older versions.

2. What's the reason why names with no prefix, that
   do not conflict with any Emacs names, can't be
   included in `cl-lib.el' as aliases?  I'm thinking
   of names like `case', `incf', `multiple-value-bind',
   `typecase', `gentemp', `pushnew', `delete-if',
   `loop', `decf', and `(delete|remove)-duplicates'.
   (In my code, `case' is the most commonly used.)

   They are aliased in `cl.el' (see #1).  Without
   supporting the aliases, code that's compatible
   with older releases can't use the aliases, and it
   also can't use the `cl-' versions, which don't
   exist.

3. Moving `cl.el' to GNU ELPA doesn't help its use
   by older Emacs versions that don't support
   package.el.

I see only bother for users in the proposal.  I'm
sure it would reduce some maintenance for Emacs
dev, but how much?  And is that worth the bother
for users and (at least some) 3rd-party libraries?

My vote: -1.

Re: Declaring cl.el obsolete

[Stefan Monnier]

>> > cl-lib was released 6 years ago...
>> > everything it offers is provided by cl-lib or lexical-binding.
> Maybe.  When those are available, which they're
> not for some older releases.  And not everything:
> aliases to names without `cl-' are missing.

Not sure how that's relevant: I'm not suggesting to drop 'cl' yet.

>> Regarding (2), I pointed out that I don't foresee `cl` disappearing
>> completely any time soon.  Instead, it will likely move to GNU ELPA
>> when we finally remove it from Emacs.
[...]
> 1. Some code will continue to use `cl.el', at least
>    for compatibility with both older and newer Emacs
>    versions.

That's addressed by my point (2) above.

>    They are aliased in `cl.el' (see #1).  Without
>    supporting the aliases, code that's compatible
>    with older releases can't use the aliases, and it
>    also can't use the `cl-' versions, which don't
>    exist.

Again, you can still use 'cl', nothing's changed in this respect.

> 3. Moving `cl.el' to GNU ELPA doesn't help its use
>    by older Emacs versions that don't support
>    package.el.

These come with 'cl' built-in, so they don't need any GNU ELPA package.


        Stefan

Re: Declaring cl.el obsolete

[Stefan Monnier]

> So any remaining objection to the patch below?

Pushed (after fixing the last two uses of cl-lib in `master`).


        Stefan