[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: moving more cl seq/mapping support into core
From: |
MON KEY |
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.
--
/s_P\
- Re: moving more cl seq/mapping support into core, (continued)
Re: moving more cl seq/mapping support into core, MON KEY, 2010/10/02
Re: moving more cl seq/mapping support into core, Daniel Colascione, 2010/10/04
Re: moving more cl seq/mapping support into core, Richard Stallman, 2010/10/05
Re: moving more cl seq/mapping support into core, Helmut Eller, 2010/10/05
Re: moving more cl seq/mapping support into core, Eli Zaretskii, 2010/10/05
Re: moving more cl seq/mapping support into core, Richard Stallman, 2010/10/06
Re: moving more cl seq/mapping support into core, Ted Zlatanov, 2010/10/07
Re: moving more cl seq/mapping support into core, Karl Fogel, 2010/10/07
Re: moving more cl seq/mapping support into core, Richard Stallman, 2010/10/08
Re: moving more cl seq/mapping support into core, Ted Zlatanov, 2010/10/05