From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: moving more cl seq/mapping support into core Date: Mon, 4 Oct 2010 01:51:33 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1286171544 26825 80.91.229.12 (4 Oct 2010 05:52:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 4 Oct 2010 05:52:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 04 07:52:21 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P2dyG-0003Ko-1u for ged-emacs-devel@m.gmane.org; Mon, 04 Oct 2010 07:52:20 +0200 Original-Received: from localhost ([127.0.0.1]:44952 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P2dyE-00047R-V0 for ged-emacs-devel@m.gmane.org; Mon, 04 Oct 2010 01:52:19 -0400 Original-Received: from [140.186.70.92] (port=55775 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P2dy2-00047J-P6 for emacs-devel@gnu.org; Mon, 04 Oct 2010 01:52:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P2dy1-0000cE-Mv for emacs-devel@gnu.org; Mon, 04 Oct 2010 01:52:06 -0400 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:41702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P2dy1-0000c8-FQ; Mon, 04 Oct 2010 01:52:05 -0400 Original-Received: by wwb24 with SMTP id 24so5453344wwb.30 for ; Sun, 03 Oct 2010 22:52:04 -0700 (PDT) Original-Received: by 10.216.188.211 with SMTP id a61mr4784433wen.15.1286171493852; Sun, 03 Oct 2010 22:51:33 -0700 (PDT) Original-Received: by 10.216.67.195 with HTTP; Sun, 3 Oct 2010 22:51:33 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: PRhWpltE0cg-Mw89a68RR1f-0TI X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:131313 Archived-At: On Sun, Oct 3, 2010 at 10:03 PM, Richard Stallman 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\