[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: moving more cl seq/mapping support into core

Subject: Re: moving more cl seq/mapping support into core
Date: Fri, 8 Oct 2010 20:29:54 -0400

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]