Re: CL package serious deficiencies

[Stefan Monnier]

>> I've never understood what's wrong with including cl.el, nor why the
>> byte-compiler should warn specially about it, any more than it warns
>> about any other package.
> Since the beginning of time, the Emacs maintainer (whoever they were at
> the time) just hasn't liked Common Lisp.

Actually, I like many parts of Common Lisp.  E.g. I intend to move the
compiler macros to the Elisp core (they're pretty much there already since
they require support in the bytecompiler).  I also like the `setf' macro
and related machinery.  Of course defstruct is also good (because "more
types" is good in my world).

> Meanwhile, most of the people who program Emacs Lisp daily (i.e., people
> like me) have always been in favour of including it.  Who doesn't want
> `incf'?

I've used incf occasionally, but don't find it terribly important.

> `plusp'?

Never used it.  (> n 0) is no shorter than (plusp n) and is just as
clear, so I really don't see the benefit.

> `delete-if-not'?

That's the big one: some kind of "filter elements based on a predicate"
is really handy and we definitely need to have this in core Elisp.
OTOH I don't like the -if-not/-if duplication nor all the keyword
arguments it takes, which just complicate significantly the
implementation with very little benefit to the user/reader.

> `position'?

I think having cl-position (after (require 'cl-lib)) is good enough for
this one (it's handy and more readable than the Elisp replacement, but
it's not used often).


        Stefan