Re: moving more cl seq/mapping support into core

[Daniel Colascione <dan.colascione@gmail.com>]

On 9/26/2010 11:27 PM, Richard Stallman wrote:
>     Thanks. I think we need not to worry the user address space too much.
> 
> That would be a change for the worse
> in our standard of documentation.

Every Emacs release adds all sorts of functions that might impinge on
the user namespace, but it's rarely a problem in practice. CL shouldn't
be held to a higher standard.

In practice, many people (require 'cl) almost immediately, and a large
number of packages, even those in GNU Emacs, (eval-when-compile
'(require 'cl)). If cl namespace were actually a problem, we'd have
heard about it long before now.

In short, I really don't buy the argument that CL would cause too much
namespace pollution. The benefits outweigh the tiny risk to the small
number of users who work without CL loaded.

CL really should be dumped along with Emacs proper.

> Those are all rather heavy things by nature, so if the calling
> sequence is heavy too, that's ok.
> If I added a `remove-if' function I would like it not to be so heavy
> to use.

You can use compiler-macros (or an equivalent) to create "fast" calls
when the keywords involved are known beforehand, as they almost always
are. But the current CL functions are fast enough *now*, considering
that they're widely used. If profiling reports that a particular call is
too slow, it can always be replaced with lower-level functionality. But
for the majority of code that isn't on the fast path, having CL
primitives available will greatly simplify implementation.