From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/66736 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: functionp bug Date: Wed, 09 Apr 2008 16:56:11 +0900 Organization: Emacsen advocacy group Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1207727833 23333 80.91.229.12 (9 Apr 2008 07:57:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Apr 2008 07:57:13 +0000 (UTC) Cc: ding@gnus.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 09 09:57:45 2008 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.50) id 1JjVBf-0006iv-A0 for ged-emacs-devel@m.gmane.org; Wed, 09 Apr 2008 09:57:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JjVB1-00005r-Tt for ged-emacs-devel@m.gmane.org; Wed, 09 Apr 2008 03:57:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JjVAY-000834-DD for emacs-devel@gnu.org; Wed, 09 Apr 2008 03:56:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JjVAX-000828-Bi for emacs-devel@gnu.org; Wed, 09 Apr 2008 03:56:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JjVAW-00081o-Qe for emacs-devel@gnu.org; Wed, 09 Apr 2008 03:56:33 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JjVAW-0006i4-Ga for emacs-devel@gnu.org; Wed, 09 Apr 2008 03:56:32 -0400 Original-Received: from orlando.hostforweb.net ([216.246.45.90]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JjVAT-000392-8k for emacs-devel@gnu.org; Wed, 09 Apr 2008 03:56:30 -0400 Original-Received: from [66.225.201.151] (port=41273 helo=mail.jpl.org) by orlando.hostforweb.net with esmtpa (Exim 4.68) (envelope-from ) id 1JjVAH-0003Kp-B7; Wed, 09 Apr 2008 02:56:18 -0500 X-Hashcash: 1:20:080409:monnier@iro.umontreal.ca::pUIKTjBuGDnSAhC7:00000000000000000000000000000000000000I7j X-Hashcash: 1:20:080409:emacs-devel@gnu.org::UTLZx6PJ1tJjKiA7:00000000000000000000000000000000000000000005cC X-Hashcash: 1:20:080409:ding@gnus.org::qb1R2Wvqm9ZZ/Wa4:00000fm+ X-Face: #kKnN,xUnmKia.'[pp`; Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu; B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:EsU1RPquDc9rcChUcFtbg5zBDJI= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - orlando.hostforweb.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-detected-kernel: by mx20.gnu.org: Genre and OS details not recognized. X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:94760 gmane.emacs.gnus.general:66736 Archived-At: >>>>> Reiner Steib wrote: >> Maybe it is possible to fix them all, but is it really the right thing >> to make such an incompatible change? What is the reason for >> this change? >>>>> Stefan Monnier wrote: > That the strange definition of `functionp' was never what was really > needed: if special-forms should be accepted, than so should macros. I don't want `functionp' to accept macros because macros cannot be funcall'd. I had been using `functionp' in order to mainly examine whether the object is a function symbol or a lambda form. For such a usage, there's no problem with the present definition if only the function that actually does something, e.g. the one applicable to `gnus-article-x-face-command', is assumed. OTHO, Gnus used it even to examine whether the Lisp form in which the first item might be a special form is able to be eval'd. `if' and `or' are not functions? Yes, it's a sound argument and Gnus' way might have been a wrong approach even though `functionp' was easy to use. However, I'm not sure such an incompatible change sticking to semantics is really necessary. While programing ELisp, to consider that whatever is placed right after the open parenthesis is a function generally causes no problem, if the form is assumed to be able to be evaluated, doesn't it? The use of `functionp' was handy for such a case. Neither of examining whether the object is not a special form and examining whether the object is a special form will probably be done rarely. If making the change revert is not acceptable, what we have to do toward the Gnus 5.10.10 release and the No Gnus v 0.8 release will be: 1. Merge Stefan's changes: 2008-04-07 Stefan Monnier * mail-source.el (mail-source-value): Prefer fboundp to functionp so it works with macros as well. 2008-04-03 Stefan Monnier * gnus-win.el (gnus-configure-frame, gnus-all-windows-visible-p): Fix last change in case the element is not even a symbol. 2008-03-20 Stefan Monnier * gnus-win.el (gnus-configure-frame, gnus-all-windows-visible-p): Prefer fboundp to functionp so it works with macros as well. I'm not sure that's all, though. 2. Post a notice to let people who use the Emacs trunk use this workaround: (or (functionp 'if) (defadvice functionp (around workaround-bug (object) activate) "Workaround bug." (or ad-do-it (setq ad-return-value (and (symbolp object) (fboundp object)))))) It only conceals the problem, though. 3. Replace all `functionp' with `gmm-functionp' which is the same as the one in Emacs 22.2.50. It only conceals the problem, too. I vote to 1. Regards,