unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Katsumi Yamaoka <yamaoka@jpl.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: ding@gnus.org, emacs-devel@gnu.org
Subject: Re: functionp bug
Date: Wed, 09 Apr 2008 16:56:11 +0900	[thread overview]
Message-ID: <b4m7if7pilg.fsf@jpl.org> (raw)
In-Reply-To: jwvve2tpj2f.fsf-monnier+emacs@gnu.org

>>>>> 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  <monnier@iro.umontreal.ca>

	* mail-source.el (mail-source-value):
	Prefer fboundp to functionp so it works with macros as well.

2008-04-03  Stefan Monnier  <monnier@iro.umontreal.ca>

	* 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  <monnier@iro.umontreal.ca>

	* 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,




  reply	other threads:[~2008-04-09  7:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-07  1:20 functionp bug Katsumi Yamaoka
2008-04-07 16:04 ` Stefan Monnier
2008-04-07 18:34   ` Romain Francoise
2008-04-07 19:26     ` Stefan Monnier
2008-04-07 21:27       ` Manoj Srivastava
2008-04-07 21:50         ` Reiner Steib
2008-04-07 18:40   ` Reiner Steib
2008-04-07 19:23     ` Stefan Monnier
2008-04-09  7:56       ` Katsumi Yamaoka [this message]
2008-04-09  8:54         ` Andreas Schwab
2008-04-09 10:34         ` Richard Stallman
2008-04-09 14:22           ` Stefan Monnier
2008-04-09 14:26         ` Stefan Monnier
2008-04-09 22:53           ` Katsumi Yamaoka
2008-04-10  1:36             ` Stefan Monnier
2008-04-10  2:02               ` Katsumi Yamaoka
2008-04-10 10:44                 ` Reiner Steib
2008-04-10 11:19                   ` Katsumi Yamaoka
2008-04-10 11:38                     ` Reiner Steib
2008-04-10 11:57                       ` Katsumi Yamaoka
2008-04-10 18:24                   ` Stefan Monnier
2008-04-10 19:12                     ` Reiner Steib
2008-04-10 21:17                       ` Stefan Monnier
2008-04-10 22:13                         ` Reiner Steib
2008-04-09 22:34       ` Johan Bockgård

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4m7if7pilg.fsf@jpl.org \
    --to=yamaoka@jpl.org \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).