Re: un-deprecating CL

[David O'Toole]

Eli Zaretskii <address@hidden> writes:

>     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.

Selling CL to the reader is not the point of the essay at all. I
openly labeled my opinions as such and there is therefore is no reason
to "suspect" the essay of anything.

> 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.

Although I did make it clear that I find the CL package very useful,
my point in this was to motivate my subsequent discussion of the CL
policy, and explain to the reader my underlying motivations for
thinking the CL policy is harmful. These opening paragraphs also place
the issue in context for those readers who may not know about the CL
compatibility package, or who may know about it but have been
discouraged by the policy from looking into it further. (*) see below

I was writing about two separate issues: the rationale for the CL
policy (which I find less than compelling) and what I see as the
deleterious effects of the policy on Emacs. You missed both, and seem
to think my essay was designed to make people adopt Common Lisp
(i.e. wanting me to discuss disadvantages of CL, etc.) The essay's
title, and the fact that I spend most of the essay talking about the
CL policy and not CL itself, should make this clear enough.

A full discussion of the pros and cons of Common Lisp usage, or
exploring the "large language versus small language" debate, is
outside the scope of my essay, and probably best left to Wikipedia.

> 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.

It should be obvious that I know that these warnings are the result of
the policy. That is why I mentioned them in a post whose main subject
was the policy.

(If you are saying that the name conflict issue is only a "corollary"
of the policy and not the main reason for it, then what is the reason
for the policy?)

Perhaps I am to blame for not revising the post and increasing its
clarity but someone else posted it here before I got a chance to
improve it. 

 (*) Despite what people say about still being able to use the macros
while complying with the policy, in my opinion the policy is still a
discouragement. You have to memorize which of its features you must
abstain from using (and therefore lose the benefit of those features)
if you are to have any hope of someday contributing Lisp code to GNU
Emacs.

This last point is what I am really getting at in my criticism of the
policy. I was asked to contribute two of my programs, both of which
make heavy use of the CL package and total upwards of 7,000 lines. I
am more than willing to assign them, and I already have Emacs papers
on file with the FSF; but it's clear now that these programs cannot be
accepted, because they use many CL functions. Furthermore I am not
willing to make such changes as would make them acceptable---it would
not improve the programs (probably the opposite) and as I argued
before, I would likely have to reimplement my own (possibly incorrect)
versions of the functions I want, at some expense in time and effort.

This has relatively little impact on me, but Emacs will lack two
packages that a maintainer had considered worth including. Maybe this
outcome doesn't bother you because you don't personally find my work
exciting, but it is ironic because the undesirability of this scenario
(i.e. the FSF not being able to include packages with Emacs that it
considers useful and appropriate) was adduced as an argument against
ELPA, and is clearly an important concern for the maintainers. But
that harm, only conjectural in the ELPA discussion, has already
resulted from the CL policy. It tells me years ahead of time that I
cannot contribute code to Emacs unless I eschew tools that are
powerful and readily understood by anyone familiar with Common Lisp,
and that are included in the standard Emacs distribution (yet are
somehow non-standard). Instead I must deliberately write programs in a
style I consider less expressive and less convenient and less
enjoyable, which I am not going to do. And I think some other cl.el
users will feel the same, despite how much they would like to improve
Emacs. If the use of the CL package were to become more widespread
(for example if someone writes a widely-read and translated tutorial
like the one I wrote for org-mode) there would be a larger body of
code that Emacs could not include, and the harm the policy causes
would then become more obvious.

To sum up: hypothetical bad things (name conflicts that can only be
created by people who are not using a package-specific prefix, and
thus not following the guidelines anyway) are said to justify a policy
which creates *real* bad things (Emacs maintainers having to reject
perfectly good packages because they invoke other Emacs functions
whose names are effectively reserved) and I do not see the sense in
it.

By pointing this out I hope it will encourage us to overcome such
issues as which manual a function is supposed to be documented in if
it lacks a package-specific prefix and just find a solution.

If the real issue is the Emacs maintainers not wanting to maintain or
debug programs that use the CL functions, that would be quite
understandable. But then put that in the manual, and not the argument
about name conflicts.

-- 
David O'Toole 
address@hidden
http://dto.freeshell.org/notebook/