[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: |
Mon, 4 Oct 2010 01:51:33 -0400 |
On Sun, Oct 3, 2010 at 10:03 PM, Richard Stallman <address@hidden> wrote:
>
> I don't think that relates to this issue.
It can't not relate.
>
> This issue is about global names.
>
Here's the thing about the global names "issue" that I find
particularly irksome:
(let ((tf "./some-temp-file"))
(with-temp-file tf
(insert
"(defun reduce (arg1)\n arg1)"
"\n(reduce 'bubba)"))
(byte-compile-file tf)
(when (get-buffer "*Compile-Log*")
(display-buffer "*Compile-Log*"))
(delete-file tf))
Does your *Compile-Log* buffer have this warning:
,----
|
| In reduce:
| some-temp-file:1:8:Warning: function reduce used to take 2+ arguments, now
| takes 1
| some-temp-file:3:10:Warning: Function `reduce' from cl package called at
| runtime
|
`----
If so, how does one justify this second warning as a protection of the
global names?
Either `reduce' is a privileged global name, or it is available to me (the user)
to bind without qualification.
So which is it, do I get to bind `reduce' at my leisure and without spurious CL
related byte-compiler warnings, or is the runtime ban a self-perpetuating and
(oft broken) policy?
Note, the third way isn't much better:
"Our regime of "protecting" the global names and the user from herself can
appear at once authoritarian and sloppy. We apologize for any inconvenience this
might cause but it is for the best of all parties concerned that it be
this way."
--
/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