Re: moving more cl seq/mapping support into core

[MON KEY]

On Wed, Oct 6, 2010 at 1:21 AM, Richard Stallman <address@hidden> wrote:
>
> I guess you had already loaded cl.
>

Yes, apparently so. Indeed, the warning does not appear with an "emacs -Q"

> The purpose of this warning is to encourage people not to write their code
> to call cl at run time.
>
> I think it was intended to operate in files that load cl at compile
> time and don't require cl at run time.

OK. But, the CL wasn't called at runtime. I've not seen a similar such
warning when byte-compiling files that redefine other functions
formally globally defined from some other place. AFAIK this only
occurs with the CL's.

>
>  The occurrence of the message in this case seems like a bug.
>

I don't have the impression that this is a bug per se. Its fairly
clear looking at the sources of emacs-lisp/bytecomp.el that this is an
intended (albeit unfortunate) outcome of `byte-compile-cl-warn',
`byte-compile-cl-file-p', `byte-compile-eval'.

What I find troubling is that:

- the warning occurs opaquely and separate from the locus of its
  intended target (it affects the user regardless of whether she is
  the package author);

- the distinction w/re the "global names" is made specific to CL at
  the byte-compiler level.

With regards the latter my impression is that the distinction is made
manifest at such a low-level _because_ it is primarily a
philosophical/political design-decision rather than as a requirement
of the LispMachine.

What is irksome is that the distinction, being at once low-level and
by proxy cumulatively entrenched, both allows and promotes a
conflation of the design-decision aspects of the runtime ban with the
functional requirements of the LispMachine in such a way as to
disincentivise efforts to attempt decoupling the historically abstract
vs. any contemporary practical concerns and intentions around a CL
feature(s).  Whether this outcome has arisen from a conscious
intent/desire to prevent/deter incorporation of Common-Lisp like
features into Emacs Lisp or is the only an inadverdent effect the
result is the same.

--
/s_P\