Re: un-deprecating CL

[Eli Zaretskii <eliz@gnu.org>]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Fri, 14 Sep 2007 12:21:22 -0700
> Cc: emacs-devel@gnu.org
> 
> >   http://dto.freeshell.org/blog/blog-2007-09-07-2323.html
> >
> > I agree completely with its reasoning.
> >
> > Therefore, I propose that the warnings in the manual against relying
> > on CL and the byte-compiler warnings when you use a CL function should
> > both be removed.
> 
> I completely agree.  The CL packaged is distributed with Emacs now.
> If a programmer defines a function in a way that conflicts with CL,
> the best result would be for them run into problems and have to rename
> their function so as not to to conflict with CL.
> 
> Frankly, we should just have CL loaded as a default all the time :-).
> But failing that, at the very least we should encourage its use, and
> encourage other packages to avoid conflicting with CL's namespace.

For the record, I'm not as opinionated as Richard about CL, perhaps
because my Lisp background doesn't go as far back and as deep as his.
But I must say that the above blog's arguments lost me as a potential
ally right on the first sentence:

    In my opinion, the best way to program Emacs Lisp is to use the many,
    many powerful macros and functions of the CL package.

This basically says that the author is already sold on using CL as
heavily as possible, and therefore all the rest of the essay is
suspect of trying to sell the same idea to the reader.

That is not a very effective way of convincing people to assign to
views that are in controversy, IMO.

Granted, a blog isn't required to present a convincing argument.  But
if this essay does need to convince me, it will have to do a lot
better.  For example, I would like to hear about disadvantages of
using CL, not just about how wonderful it is.  IOW, a convincing
argument will present a balanced view of the issue, and try to win by
showing that the balance is in its favor.

As to the warning in the manual and the byte compiler, I hope you
realize that the name conflict is not the real issue here.  The real
issue is the policy not to use CL in Emacs packages; the warning about
the potential name conflicts and the byte compiler warning are just
the corollary.  So building the argument on those warning being
harmful is not gonna win the day, either.