bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Drew Adams <drew.adams@oracle.com>]

> > There is no reason to misleadingly add stuff to our emulation
> > library that has no counterpart is Common Lisp - is not
> > emulating anything there.  It is even worse to use names that
> > make it look as if these do correspond to Common Lisp things.
> >
> > It is perfectly fine for Emacs to add things that Common Lisp
> > does not have/do.  But it should add them elsewhere from the
> > `cl*.el' files, and document them elsewhere than in manual CL.
> 
> Why? Some things (like letf) are just natural extensions of
> facilities we got from Common Lisp.

They may be natural extensions of Common Lisp for you, but that
does not make them Common Lisp, and it does not make them natural
extensions of Common Lisp for Common Lisp's designers.

We are not designing or extending Common Lisp.  That would be
pretentious.  We are designing Emacs Lisp.

It is perfectly fine to extend or redesign Emacs Lisp any way we
like.  And we can take whatever we want from Common Lisp and do
whatever we want with it.  We need not try to emulate any given
Common-Lisp function or macro.  But the things we put in the
Common-Lisp emulation package should be emulations of Common Lisp
things, IMO - things designed by the Common-Lisp designers for
Common Lisp.

It is not appropriate to add non Common-Lisp things to our
emulation of Common Lisp.  That's all.

> Keep in mind that they didn't start out under the cl namespace
> either. They were just there along with everything else
> when we created cl-lib.

Yes, they should have been moved out of `cl*.el' before the
creation of `cl-lib.el'.  It's not too late to clean things up
now and put them in non-`cl*.el' files where they belong (and
of course remove the `cl-' prefix).  They do not represent
Common Lisp features in any way. 

So call it `letf', not `cl-letf', and move it out of `cl*.el'.
Similarly for anything else that is unrelated to Common Lisp.

> I don't think you've explained the downside of extending CL
> in the cl-namespace. 

It's not about "extending CL in the cl-namespace".  It's about
a misguided, if indirect, attempt to extend Common Lisp, and
giving the mistaken impression that these things are part of
Common Lisp.

It's not about the namespace.  The same bug report applies to
the old `letf' etc. in the old `cl-macs.el' (now called `cl--letf'
in the new `cl-macs.el').  The name `letf' was fine for Emacs.
And it still is.  It just does not belong in `cl*.el'.

> You've articulated an aesthetic point, but I don't see any
> negative technical consequences.

Technical consequences?  It's about how this misleads users -
user consequences.

You've not articulated any criteria for adding a function or
macro to `cl*.el'.

Why not move `while' there as `cl-while'?  Any number of Emacs
functions and macros, could be argued to be "natural extensions
of facilities we got from Common Lisp."  That's too vague to
mean anything helpful.

Just because we got `let', `let*', and `setf' from Common Lisp,
that's no reason that we should add `letf' or `cl-letf' - which
have no counterpart in Common Lisp - to `cl*.el'.

That's what this bug report is about: Just what should be part
of our Common-Lisp emulation package.  The criterion I would
use is this: The only things that belong there are things that
emulate things in Common Lisp.

If Common Lisp has a function or macro `foo' then we can
consider emulating it (under whatever name) and adding it to
the `cl*.el' files.  If not, it belongs elsewhere in Emacs.

What, specifically, are your criteria for inclusion in `cl*.el'?
I was quite specific about mine.  How about you?